--- 1/draft-ietf-p2psip-service-discovery-02.txt	2011-07-05 12:16:38.000000000 +0200
+++ 2/draft-ietf-p2psip-service-discovery-03.txt	2011-07-05 12:16:38.000000000 +0200
@@ -1,18 +1,18 @@
 
 P2PSIP Working Group                                          J. Maenpaa
 Internet-Draft                                              G. Camarillo
 Intended status: Standards Track                                Ericsson
-Expires: July 11, 2011                                   January 7, 2011
+Expires: January 6, 2012                                    July 5, 2011
 
   Service Discovery Usage for REsource LOcation And Discovery (RELOAD)
-               draft-ietf-p2psip-service-discovery-02.txt
+               draft-ietf-p2psip-service-discovery-03.txt
 
 Abstract
 
    REsource LOcation and Discovery (RELOAD) does not define a generic
    service discovery mechanism as part of the base protocol.  This
    document defines how the Recursive Distributed Rendezvous (ReDiR)
    service discovery mechanism used in OpenDHT can be applied to RELOAD
    overlays to provide a generic service discovery mechanism.
 
 Status of this Memo
@@ -23,21 +23,21 @@
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current Internet-
    Drafts is at http://datatracker.ietf.org/drafts/current/.
 
    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on July 11, 2011.
+   This Internet-Draft will expire on January 6, 2012.
 
 Copyright Notice
 
    Copyright (c) 2011 IETF Trust and the persons identified as the
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents
    (http://trustee.ietf.org/license-info) in effect on the date of
    publication of this document.  Please review these documents
@@ -177,34 +177,34 @@
    join a namespace and peers wishing to use a service perform lookups
    within the namespace of the service.  A ReDiR lookup for identifier k
    in namespace ns returns a node that has joined ns whose identifier is
    the closest successor of k.
 
    Each tree node in the ReDiR tree contains a list of Node-IDs of peers
    providing a particular service.  Each node in the tree has a level.
    The root is at level 0, the immediate children of the root are at
    level 1, and so forth.  The ReDiR tree has a branching factor, whose
    value is determined by a new element in the RELOAD overlay
-   configuration document, called redirBranchingFactor.  At every level
-   i in the tree, there are at most redirBranchingFactor^i nodes.  The
-   nodes at any level are labeled from left to right, such that a pair
-   (i,j) uniquely identifies the jth node from the left at level i.
-   This tree is embedded into the RELOAD Overlay Instance node by node,
-   by storing the values of node (i,j) at key H(namespace,i,j).  As an
-   example, the root of the tree for a voice mail service is stored at
-   H("voice-mail",0,0).  Each node (i,j) in the tree is associated with
-   redirBranchingFactor intervals of the DHT keyspace as follows:
+   configuration document, called branching-factor.  At every level i in
+   the tree, there are at most branching-factor^i nodes.  The nodes at
+   any level are labeled from left to right, such that a pair (i,j)
+   uniquely identifies the jth node from the left at level i.  This tree
+   is embedded into the RELOAD Overlay Instance node by node, by storing
+   the values of node (i,j) at key H(namespace,i,j).  As an example, the
+   root of the tree for a voice mail service is stored at H("voice-
+   mail",0,0).  Each node (i,j) in the tree is associated with
+   branching-factor intervals of the DHT keyspace as follows:
 
              [2^numBitsInNodeID*b^(-i)*(j+(b'/b)),
               2^numBitsInNodeID*b^(-i)*(j+((b'+1)/b))], for 0<=b'<b,
 
-   where b is the redirBranchingFactor.
+   where b is the branching-factor.
 
    Figure 1 shows an example of a ReDiR tree with a branching factor of
    2.  Each node is shown as two horizontal lines separated by a
    vertical bar.  The lines represent the two intervals each node is
    responsible for.  At level 0, there is only one node, (0,0)
    responsible for two intervals that together cover the entire
    identifier space of the RELOAD Overlay Instance.  At level 1, there
    are two nodes, (1,0) and (1,1), each of which is responsible for half
    of the identifier space.  At level 2, there are four nodes.  Each of
    them owns one fourth of the identifier space.  At level 3, there are
@@ -316,26 +316,25 @@
        the interval.
 
    Note that above, when we refer to 'the tree node associated with
    I(l,k)', we mean the entire tree node (that is, all the intervals
    within the tree node) responsible for interval I(l,k).  In contrast,
    I(l,k) refers to a specific interval within a tree node.
 
 4.4.  Refreshing Registrations
 
    All state in the ReDiR tree is soft.  If an entry (Node-ID) is not
-   refreshed for redirRefreshPeriod seconds, it MUST be dropped from the
-   dictionary by the peer storing the tree node. redirRefreshPeriod is a
-   new element in the RELOAD overlay configuration document (see
-   Section 8).  Every service provider MUST repeat the entire
-   registration process periodically until it leaves the RELOAD Overlay
-   Instance.
+   refreshed for refresh-period seconds, it MUST be dropped from the
+   dictionary by the peer storing the tree node. refresh-period is a new
+   element in the RELOAD overlay configuration document (see Section 8).
+   Every service provider MUST repeat the entire registration process
+   periodically until it leaves the RELOAD Overlay Instance.
 
    Note that no new mechanisms are needed to keep track of the remaining
    lifetime of RedirServiceProvider records.  The 'storage_time' and
    'lifetime' fields of RELOAD's StoredData structure can be used for
    this purpose in the usual way.
 
 4.5.  Service Lookups
 
    The purpose of a service lookup on identifier k in namespace ns is to
    find the node that has joined ns whose identifier most immediately
@@ -384,26 +383,27 @@
 
    ReDiR requires an access control policy that allows multiple nodes in
    the overlay read and write access to the ReDiR tree nodes stored in
    the overlay.  Therefore, none of the access control policies
    specified in RELOAD base [I-D.ietf-p2psip-base] is sufficient.
 
    This document defines a new access control policy, called NODE-ID-
    MATCH.  In this policy, a given value MUST be written and overwritten
    only if the the request is signed with a key associated with a
    certificate whose Node-ID is equal to the dictionary key.  In
-   addition, the Node-ID MUST belong to one of the two intervals
-   associated with the tree node.  Finally, H(namespace,level,node),
-   where namespace, level, and node are taken from the
-   RedirServiceProvider structure being stored, MUST be equal to the
-   Resource-ID for the resource.  The NODE-ID-MATCH policy may only be
-   used with dictionary types.
+   addition, the Node-ID MUST belong to one of the intervals associated
+   with the tree node (the number of intervals each tree node has is
+   determined by the branching-factor parameter).  Finally,
+   H(namespace,level,node), where namespace, level, and node are taken
+   from the RedirServiceProvider structure being stored, MUST be equal
+   to the Resource-ID for the resource.  The NODE-ID-MATCH policy may
+   only be used with dictionary types.
 
 6.  REDIR Kind Definition
 
    This section defines the REDIR kind.
 
    Name
       REDIR
 
    Kind IDs
       The Resource Name for the REDIR Kind-ID is created by
@@ -491,26 +491,26 @@
    with interval I(1,4) because it has the numerically lowest Node-ID in
    that interval.  Next, peer 4 continues to the root level, at which it
    stores its RedirServiceProvider record and finishes the upward walk
    since the root level was reached.  Peer 4 also does a downward walk
    starting from level 2.  The downward walk stops at level 2 because
    peer 4 is the only peer in the interval I(2,4).
 
 8.  Overlay Configuration Document Extension
 
    This document extends the RELOAD overlay configuration document by
-   adding two new elements inside each "configuration" element.
+   adding two new elements inside the new "REDIR" kind element.
 
-   redirBranchingFactor:  The branching factor of the ReDir tree.  The
+   redir:branching-factor:  The branching factor of the ReDir tree.  The
       default value is 10.
 
-   redirRefreshPeriod:  The interval at which a service provider needs
+   redir:refresh-period:  The interval at which a service provider needs
       to repeat the ReDiR registration process.
 
 9.  Security Considerations
 
    There are no new security considerations introduced in this document.
    The security considerations of RELOAD [I-D.ietf-p2psip-base] apply.
 
 10.  IANA Considerations
 
 10.1.  Access Control Policies
@@ -535,22 +535,22 @@
 
    This kind-ID was defined in Section 6.
 
 11.  References
 
 11.1.  Normative References
 
    [I-D.ietf-p2psip-base]
               Jennings, C., Lowekamp, B., Rescorla, E., Baset, S., and
               H. Schulzrinne, "REsource LOcation And Discovery (RELOAD)
-              Base Protocol", draft-ietf-p2psip-base-12 (work in
-              progress), November 2010.
+              Base Protocol", draft-ietf-p2psip-base-15 (work in
+              progress), May 2011.
 
    [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
               Requirement Levels", BCP 14, RFC 2119, March 1997.
 
 11.2.  Informative References
 
    [I-D.ietf-p2psip-concepts]
               Bryan, D., Matthews, P., Shim, E., Willis, D., and S.
               Dawkins, "Concepts and Terminology for Peer to Peer SIP",
               draft-ietf-p2psip-concepts-03 (work in progress),