Subject: [P2PSIP] My notes on draft-matthews-p2psip-bootstrap-mechanisms-00

From: Spencer Dawkins <[email-masked]>
Date: Thu, 01 Mar 2007 08:53:37 -0600

Hi, Eric/Alan/Philip,

Nice work, especially for a first draft. I have some questions, of course. 
Most involve justifications for SHOULD requirements.

Please see below.

Thanks,

Spencer Dawkins

1.  Introduction

   A peer wishing to join an existing P2PSIP overlay needs to somehow
   locate and contact one or more peers in the overlay and then exchange
   messages with these peers to add itself to the overlay.  In addition,
   the joining peer may be asked to prove that it is authorized to join
   the overlay, and may wish to confirm for itself that the other nodes
   really are the overlay they say they are.

Spencer (nit): this reads oddly on paper. Perhaps "may wish to confirm that 
its peer nodes really make up the overlay they claim to make up"?

   The protocol used by peers to construct and maintain an overlay is
   known as the Peer Protocol.  Work on this protocol is just beginning,
   and many details are not yet known, but one thing that is established
   is that the protocol must work through NATs to the greatest extent
   possible.  In order to do this, the peer protocol needs the concept
   of a "control connection" between two peers over which the peer
   protocol can run.  This is the transport connection (e.g.  TCP, UDP,
   or some other transport) over which the peer protocol runs.  The
   peers at each end of the control connection need to establish this
   connection and then take steps to maintain it in the presence of NATs
   (e.g., by sending keep-alives).

Spencer: OK, I need some help here. This document refers to a "control 
connection", a transport connection (just once, but every time I have to 
think counts), and a Peer Protocol connection. It would help a lot to pick 
one term and stay with it. I think control connection is OK, but "overlay 
connection" might work, too (if you're not happy with any of the current 
choices).

Spencer: Just noodling... are you thinking that Peer Protocol connections 
that make up the overlay (in Chord, the ring) are indistinguishable from 
Peer Protocol connections that are established to carry INVITEs, etc? You 
and I might not be Chord-adjacent, but you might set up a Peer Protocol 
connection to me just because I'm handling half of your requests - does this 
make sense to you? Maybe "overlay connections" make up the overlay, and Peer 
Protocol connections would include overlay connections, plus others that are 
established for performance reasons?

   However, this document does assume that SIP is the protocol used to
   establish the connections over which the Peer Protocol runs.  There

Spencer: this statement is correct but was difficult for me to grok on first 
reading. Perhaps "this document does assume that the bootstrapping procedure 
uses SIP as its transport"? (FWIW, this was where I tripped over "Peer 
Protocol connection", as discussed previously).

   are a number of reasons for making this assumption:

   o  As argued in [I-D.matthews-p2psip-nats-and-overlays], the joining
      peer and the admitting peer may both be behind (different) NATs.
      In this case, TCP or UDP by itself is not sufficient, and an out-
      of-band signaling protocol is required.  SIP is one such out-of-
      band signaling protocol;

   o  SIP is well-suited for setting up, modifying, and tearing down
      connections;

   o  SIP has a number of security mechanisms, which can be used to
      provide appropriate security for each bootstrap mechanism;

   o  There has been a lot of work recently to define SIP mechanisms for
      setting up and maintaining connections through NATs; and

Spencer: It might be more compelling to say "SIP mechanisms for setting up 
and maintaining connections through NATs have already been created, and 
would need to be duplicated if another protocol is used for the 
bootstrapping procedure." (the point is that SIP is reasonably close to 
"finished", and nothing else is also close to "finished").

   o  It is likely that many peers in a P2PSIP network will need to
      support SIP for other reasons (e.g., establishing multimedia
      sessions).

2.  Overview of the Mechanisms

   The current version of this document describes two bootstrap
   mechanisms: the Multicast mechanism and the Bootstrap Peer mechanism.

   These two mechanisms are not rivals.  On the contrary, an eminently

Spencer: "not mutually exclusive"? "Rivals" seems odd.

   sensible approach is for a joining peer to first try the multicast
   mechanism, and try the bootstrap server mechanism if the multicast
   mechanism fails.

   Two other bootstrap mechanisms are mentioned briefly in
   [I-D.willis-p2psip-concepts].  These will be discussed in future
   versions of this document.  This section is non-normative.

Spencer: I'd call out the mechanisms explicitly ("caching peer addresses and 
manual configuration"), but you mention manual configuration of bootstrap 
servers in 2.2 :-) so you may already be almost finished.

2.1.  Multicast Mechanism

   The Multicast mechanism is intended to allow the joining peer locate
   a bootstrap peer on the same subnet.  It will also work between
   subnets if the two subnets are joined in the same multicast domain -
   typically, these will be adjacent subnets operated by the same
   organization.

Spencer: I think what you're actually saying is "The Multicast mechanism is 
intended to allow the joining peer to locate a bootstrap peer in the same 
multicast domain - one or more adjacent subnets typically operated by the 
same organization." But the current text needs a "to" between "peer" and 
"locate", at any rate.

   In the Multicast mechanism, the joining peer begins by multicasting
   an SIP OPTIONS message addressed to the pseudo-user "bootstrap" and

Spencer (nit): "a SIP OPTIONS message".

   specifying the name of the overlay the peer wishes to join (see the
   section on URIs below).  Peers willing to be a bootstrap peer reply
   and list their unicast address in the reply.  The joining peer then
   selects one of these bootstrap peers, and unicasts an INVITE message
   to it.  The bootstrap peer, in turn, selects a peer to act as the
   admitting peer and proxies the INVITE to that peer.

2.2.  Bootstrap Server Mechanism

   A P2PSIP Bootstrap Server is a SIP registrar and proxy, typically
   located in the public Internet, that acts as an intermediary to
   introduce the joining peer to a bootstrap peer.  The Bootstrap Server
   is not a part of the overlay, but is simply a well-known node that

Spencer: I would have expected "The Bootstrap Server need not be part of the 
overlay," - early in the Introduction, you allow for a combined Bootstrap 
Peer/Admitting Peer, and allowing the Bootstrap Server to be part of the 
overlay seems like a similar packaging consideration. Or did I 
misunderstand?

   acts as an "introduction service".  Peers must know the URL of one or
   more bootstrap servers: this might happen through configuration, for
   example.

   Later on, a peer that wishes to join the overlay sends an INVITE
   message to a bootstrap server address to "bootstrap" and specifying
   the name of the overlay it wishes to join.  If the bootstrap server
   knows of one or more bootstrap peers in that overlay, it selects one
   and proxies the INVITE onward to a bootstrap peer.  The selected
   bootstrap peer, in turn, selects a peer to act as the admitting peer
   and proxies the INVITE to that peer.

Spencer: so, the bootstrap peer is selecting an admitting peer, based on ??? 
Later text mentions "based on node-ID" - perhaps this could be mentioned 
here. Is there any indiction that a peer is willing to serve as an admitting 
peer, or are all peers required to perform this function? Will there be a 
need for multiple bootstrap peers to communicate about their admitting peer 
selections? I would be concerned about the possibility for avalanche restart 
problems in large P2P overlays with this scheme, if there is no mechanism 
for coordination.

2.3.  Common Procedures

   Both bootstrap mechanisms use ICE for help with setting up a control
   connection through any NATs that may lie between the joining peer and
   the admitting peer.  Following the procedures of ICE, the joining
   peer and the admitting peer include ICE candidates in their SDP offer
   and answer, and then try all the various candidate pair combinations

Spencer: "all the various candidate pair combinations"? I thought Jonathan 
said in Montreal that he expected people to try fewer than "all the various 
candidate pair combinations", just because there can be so many 
possibilities.

   to see which combinations work.  The best working combination is then
   selected as the path for the control connection.

2.4.  Multicast Example

   The following figure illustrates the call flow for this example.  In
   this figure, we use two diagramming conventions from : the labeling

Spencer: "from :"? perhaps this is a missing xref.

   of dialogs on the left-hand-side, and the collapsing of a multi-
   message transaction into a single line.

2.6.  Pros and Cons of the Two Mechanisms

   By contrast, the Bootstrap Server mechanism will work regardless of
   the distance between the joining peer and the bootstrap peer.  This
   means that it is very appropriate when the joining peer is somewhat
   isolated from other peers.  However, this mechanism requires the use
   of a well-known, publicly reachable third party (the bootstrap
   server).  To make the Bootstrap Server mechanism practical, it is
   highly desirable to minimize the load on the bootstrap server to the
   greatest extent possible, so that a single bootstrap server can serve

Spencer: I wasn't sure whether "minimize the load" was talking about the 
Peer Protocol or about packaging other functions with the bootstrap server. 
Or both.

   many different overlays.

3.1.  Peer Protocol and Signaling Protocol

   Furthermore, we assume that ICE is used as the SIP/SDP extension for
   setting up connections in the presence of NATs.  As presently

Spencer: I'm wondering if "in the presence of NATs" is helpful. This seems 
to say "if you and everyone you might ever join together in an overlay with, 
are not separated by NATs, then you don't have to use ICE". If we're talking 
about the Internet, we're probably talking about "in the presence of NATs" 
for any reasonable deployment, aren't we?

   defined, ICE supports setting up connections where the transport
   protocol is either UDP or TCP - if a different transport protocol is
   chosen for the Peer Protocol, then an appropriate ICE extension will
   need to be defined.  Since ICE, in turn, specifies that the STUN
   protocol is used for keep-alives on connections established by ICE,
   this implies that STUN messages will be multiplexed with the other
   traffic on control connections.

3.2.  URI Format

   Future versions of this document may specify a particular URI scheme.

Spencer: "may specify a particular URI scheme used to identify bootstrap 
services and bootstrap peers"?

4.1.  The Mechanism

   If these conditions are satisfied, then the peer SHOULD reply using a
   200 OK, but MAY reply using a 302 Moved Temporarily if it wishes to
   indicate other peers.  In either case, the peer MUST include, in the

Spencer: I don't believe this is a correct use of SHOULD/MAY. If I 
understand correctly, what you're saying is more like "then the peer SHOULD 
reply using a 200 OK, unless it replies using a 302 Moved Temporarily to 
indicate other peers". The current text doesn't require the peer to respond 
with either message (MAY doesn't clearly say "this is the ELSE for a 
SHOULD").

   Contact header, a URI in format 3 specifying itself as the peer.
   This URI MUST include a unicast address at which the peer can be
   reached; the address included MUST be reachable from any node located
   in the multicast domain.  The peer SHOULD NOT include contacts for
   other peers unless the peer knows, through some unspecified
   mechanism, that those peers are currently members of the overlay and
   are willing to act as bootstrap peers.

   The joining peer will receive zero or more of these replies.  As
   specified in SIP [RFC3261], the second and subsequent replies to the
   multicast request must be taken as retransmissions of the first reply
   and will be discarded.  Thus the joining peer selects a Contact URI
   from the first reply and uses this as the bootstrap peer.

Spencer: at some point it will be necessary to describe behavior during 
request timeouts, when zero replies have been received.

   The joining peer then forms an INVITE message and unicasts it to the
   selected bootstrap peer.

   Further processing after this point follows the procedures in section
   7.

Spencer: is this pointing to the right place? Section 7 is "security 
considerations", which does talk about credentials for bootstrapping in 
section 7.1 but doesn't seem to actually describe a "procedure".

5.1.  The Bootstrap Server

   The SIP registrar and proxy MUST understand the URI format used by
   P2PSIP (see the section on URI formats).  The SIP registrar SHOULD
   support multiple registrations (i.e., contacts) for a "bootstrap"

Spencer: Why is this SHOULD not a MUST? As it stands, the requirement is 
that SIP registrars ought to do this almost all the time, but peers can't 
count on them doing it so must accommodate registrars that do not.

   service for a given overlay.  The SIP proxy MUST obey the "redirect",
   "proxy" and "no-fork" directives in the Request-Disposition header
   [RFC3841].

5.2.  Registering with the Bootstrap Server

   Using some mechanism, not specified here, the peers of a P2PSIP
   Overlay select one or more peers to register with a given Bootstrap
   Server.  The set of peers selected to register with one Bootstrap
   Server may be different than the set selected to register with a
   different Bootstrap Server.

Spencer: I'm reading this as saying "different set of peers for the same 
overlay regstered with different Bootstrap Servers", but I'm guessing - the 
text doesn't actually say whether this paragraph is talking about one 
overlay or multiple overlays.

   We also assume there is some mechanism, not specified here, by which
   each bootstrap peer learns a URI for each P2PSIP Bootstrap Server it
   needs to contact.

   The peer SHOULD use a q value of 1 for the registration.

Spencer: Why not MUST here? What happens if the peer uses another q value?

5.3.  Forming the Initial INVITE

   To indicate that the bootstrap server should proxy the INVITE onward
   to a bootstrap peer (rather than redirecting with a 302 Moved
   Temporarily), the joining peer SHOULD include a Request-Disposition
   header with a "proxy" directive.  To indicate that the bootstrap
   server should not fork the INVITE but rather select just one of the
   bootstrap peers, the joining peer SHOULD include a "no-fork"
   directive in the Request-Disposition header.

Spencer: Both of these SHOULDs should be MUSTs, shouldn't they? I'm reading 
them as "SHOULD, unless you don't want to indicate..." - your text has clear 
conditional text, so I'd expect the requirements to be MUST (given that the 
peer wants to indicate "proxy" or "no-fork"). And I'm not sure whether 
you're expecting this directive to always be "proxy, no-fork" or not - the 
following text seems to assume that it is.

   See section 7.4 for how the SDP body is constructed.

Spencer (nit): this is actually section 6.4.

5.4.  Sending the INVITE

   We assume there is some mechanism, not specified here, by which a
   peer that wishes to join an overlay learns the URIs of one or more
   P2PSIP Bootstrap Servers.  It is RECOMMENDED that the peer try these
   bootstrap servers in some unspecified order until the peer succeeds
   in locating a server that knows about the overlay.

Spencer: I don't think RECOMMENDED is needed here (in 2119 language). 
Perhaps if more procedures are added in later versions of the draft, this 
would be needed, but this basically says that if you want to use the 
bootstrap server method to join an overlay, you should probably do just 
that...

Spencer: it would be good to say what happens if none of the Bootstrap 
Servers know about the overlay... assume this is a problem with the 
bootstrapping servers, or a problem with the overlay?

5.5.  Handling the INVITE at the Bootstrap Server

   Further processing after this point follows the procedures in section
   7.

Spencer (Nit): again, I think this is section 6.

6.2.  Handing the INVITE at the Admitting Peer

   It is expected that the Peer Protocol will define rules for how
   responses are sent and routed through the overlay.  Once the response
   gets back to the bootstrap peer, the rules of [RFC3261] take over for

Spencer: "the rules of [RFC3261] apply" is probably more ESL-friendly.

   routing the response back to the joining peer - in the case of the
   bootstrap server mechanism, this means that the response is routed
   back through the bootstrap server.

6.4.  Forming the Initial Offer and Answer

   The offer-answer exchange is used by the joining and admitting peers
   to negotiate the parameters for the resulting Peer Protocol
   connection.  To do this, both the offer and answer SHOULD specify

Spencer: I'm not sure I understand why this restriction exists - is it 
simply that any of the media streams would be interchangeable, so there's no 
reason to include more than one? - and assuming that the restriction is 
required, I'm not sure why this is a SHOULD and not a MUST. Peers can simply 
reject violated MUSTs, but probably have to do something sensible for 
violated SHOULDs in a P2P world.

   exactly one media stream, and the media type for that stream MUST
   specify the P2PSIP Peer Protocol.  The details of how this is done
   are outside the scope of this document.

   The offer or answer MUST NOT include any of the following attributes:
   "a=recvonly", "a=sendonly", or "a=inactive".

Spencer: If the offer or answer DOES include one of these attributes, is 
there a specific response that's required?

   Peers SHOULD use ICE ([I-D.ietf-mmusic-ice] and
   [I-D.ietf-mmusic-ice-tcp]) to determine a pair of transport addresses
   to use for the Peer Protocol connection.  This implies that both the
   offer and answer should contain a set of ICE candidates - whether
   these candidates are UDP candidates, TCP candidates, or other
   candidate types depends on the transport selected for the Peer
   Protocol.

Spencer: I'm really wondering why ICE is a SHOULD. Is this the "unless you 
know you're on the same subnet" reason? I note that Jonathan is saying that 
ICE is a "core extension" that everyone needs to implement.

6.5.  Sending a new INVITE with Replaces

   During the offer/answer exchange, both the joining peer and the
   admitting peer use the rules described in ICE for deciding whether

Spencer (Nit): "ICE to decide whether"?

   ICE connectivity checks can be run or not.

6.7.  Keepalives

   Keep-alives must be run on the control connection to maintain it in

Spencer: this is not a MUST? or MUST/unless? Perhaps "Peers must transmit 
keep-alives on the control channel" - and sometimes this is hyphenated, and 
other times not, so consistency would be good.

   the presence of NATs.  To do this, control connections SHOULD use the

Spencer: is this "MUST, if you run keepalives"? I'm OK with a "conditional 
MUST" here.

   STUN Binding Indication method described in ICE
   [I-D.ietf-mmusic-ice].

7.1.  Credentials

   The authors envision the use of credentials to authorize four
   different operations which form the bootstrap mechanisms described
   here.  Listing these in order of increasing privilege, these are:

Spencer: is the ordering important here? I'm not sure it seems important to 
the text.

   1.  The credentials required to send an INVITE through a bootstrap
       server to a bootstrap peer.

   2.  The credentials required to register a new overlay with a
       bootstrap peer and/or register a new contact for an existing
       overlay.

   3.  The credentials required to have a bootstrap peer proxy an INVITE
       through the overlay to the admitting peer.

   4.  The credentials required to set up a Peer Protocol connection for
       bootstrap purposes.

8.  IANA Considerations

   This document raises no IANA considerations.

Spencer: Is there any intention to request a well-known multicast address 
for P2PSIP? It might be nice to say so explicitly, either way, so no one 
else will ever wonder if you really thought about IANA, or just started with 
a draft template that said "no IANA considerations" :-) 

_______________________________________________
P2PSIP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/p2psip

---

From: Philip Matthews <[email-masked]>
Date: Wed, 7 Mar 2007 16:50:50 -0500

Hi Spencer:

Thanks for your comments!
As usual, they are very insightful.

Replies inline.

- Philip

On 1-Mar-07, at 09:53 , Spencer Dawkins wrote:

> Hi, Eric/Alan/Philip,
>
> Nice work, especially for a first draft. I have some questions, of  
> course. Most involve justifications for SHOULD requirements.
>
> Please see below.
>
> Thanks,
>
> Spencer Dawkins
>
> 1.  Introduction
>
> Spencer (nit): this reads oddly on paper. Perhaps "may wish to  
> confirm that its peer nodes really make up the overlay they claim  
> to make up"?

OK

> Spencer: OK, I need some help here. This document refers to a  
> "control connection", a transport connection (just once, but every  
> time I have to think counts), and a Peer Protocol connection. It  
> would help a lot to pick one term and stay with it. I think control  
> connection is OK, but "overlay connection" might work, too (if  
> you're not happy with any of the current choices).

I think the term should be  "Peer Protocol Connection". After we wrote
this document, I added the terms "Peer Protocol Connection" and
"Client Protocol Connection"  to the terminology section of the  
Concepts draft.

How does this sound?

>
> Spencer: Just noodling... are you thinking that Peer Protocol  
> connections that make up the overlay (in Chord, the ring) are  
> indistinguishable from Peer Protocol connections that are  
> established to carry INVITEs, etc? You and I might not be Chord- 
> adjacent, but you might set up a Peer Protocol connection to me  
> just because I'm handling half of your requests - does this make  
> sense to you? Maybe "overlay connections" make up the overlay, and  
> Peer Protocol connections would include overlay connections, plus  
> others that are established for performance reasons?

The  answer to your first two questions is: Yes.

I don't see any reason to distinguish between connections set up  
because the DHT algorithm dictates them, and other Peer Protocol  
Connections that get set up for other reasons.
In fact, that is what we say in the "NAT Traversal for dSIP" draft.
If you have a Peer Protocol Connection, you should use it, and not  
say for example "I cannot use this connection for lookup because it  
was set up for another reason".
However, I am NOT proposing to send, for example, Peer Protocol  
messages over RTP connections.
(If you want to discuss this point farther, we should do it under the  
"NAT Traversal for dSIP" thread).

> Spencer: this statement is correct but was difficult for me to grok  
> on first reading. Perhaps "this document does assume that the  
> bootstrapping procedure uses SIP as its transport"? (FWIW, this was  
> where I tripped over "Peer Protocol connection", as discussed  
> previously).

Hmm ... Another solution is to introduce the idea of a distinction
between the signaling protocol and the Peer protocol in the Concepts  
draft.
Then we can just make a reference here.

> Spencer: It might be more compelling to say "SIP mechanisms for  
> setting up and maintaining connections through NATs have already  
> been created, and would need to be duplicated if another protocol  
> is used for the bootstrapping procedure." (the point is that SIP is  
> reasonably close to "finished", and nothing else is also close to  
> "finished").

Well ... one COULD envision inventing a new signaling protocol
that also uses SDP to specify the media type. Then all the ICE work
would come for free. (E.g.,  the way the XMPP/GoogleTalk uses ICE).
But I think there would need to be some good justification for
this approach.

> Spencer: "not mutually exclusive"? "Rivals" seems odd.

OK.

> Spencer: I'd call out the mechanisms explicitly ("caching peer  
> addresses and manual configuration"), but you mention manual  
> configuration of bootstrap servers in 2.2 :-) so you may already be  
> almost finished.

Adding these additional mechanisms will not be hard.
We just chose to focus the initial draft on the interesting ones.

> Spencer: I think what you're actually saying is "The Multicast  
> mechanism is intended to allow the joining peer to locate a  
> bootstrap peer in the same multicast domain - one or more adjacent  
> subnets typically operated by the same organization." But the  
> current text needs a "to" between "peer" and "locate", at any rate.

OK.

> Spencer (nit): "a SIP OPTIONS message".

Yes.

> Spencer: I would have expected "The Bootstrap Server need not be  
> part of the overlay," - early in the Introduction, you allow for a  
> combined Bootstrap Peer/Admitting Peer, and allowing the Bootstrap  
> Server to be part of the overlay seems like a similar packaging  
> consideration. Or did I misunderstand?

The text is wrong and you are right.
Concepts-04 also makes this clear.

> Spencer: so, the bootstrap peer is selecting an admitting peer,  
> based on ??? Later text mentions "based on node-ID" - perhaps this  
> could be mentioned here. Is there any indiction that a peer is  
> willing to serve as an admitting peer, or are all peers required to  
> perform this function? Will there be a need for multiple bootstrap  
> peers to communicate about their admitting peer selections? I would  
> be concerned about the possibility for avalanche restart problems  
> in large P2P overlays with this scheme, if there is no mechanism  
> for coordination.

The mechanism for selecting the admitting peer is defined by
the Peer Protocol and the DHT.

For example, if the DHT is Chord, then the admitting peer MUST
(SHOULD?) be the future successor of the joining peer.

> Spencer: "all the various candidate pair combinations"? I thought  
> Jonathan said in Montreal that he expected people to try fewer than  
> "all the various candidate pair combinations", just because there  
> can be so many possibilities.

We meant "the combinations that ICE specifies" or words to that effect.
But, on an ICE note, the new ICE-13 draft allows the controlling end  
to say
"let's try all the combinations" if it wishes.

> Spencer: "from :"? perhaps this is a missing xref.

Something is broken here.
Anyway, we took the conventions from  draft-ietf-sipping-cc-transfer .

> Spencer: I wasn't sure whether "minimize the load" was talking  
> about the Peer Protocol or about packaging other functions with the  
> bootstrap server. Or both.

I don't understand your comment.

> Spencer: I'm wondering if "in the presence of NATs" is helpful.  
> This seems to say "if you and everyone you might ever join together  
> in an overlay with, are not separated by NATs, then you don't have  
> to use ICE". If we're talking about the Internet, we're probably  
> talking about "in the presence of NATs" for any reasonable  
> deployment, aren't we?

The question is: Do we want to mandate that peers use ICE?
I don't have a problem with this if we do.

> Spencer: "may specify a particular URI scheme used to identify  
> bootstrap services and bootstrap peers"?

Err ... We may add more detail here later. This is TBD and depends a lot
on how the WG feels about this document.

> understand correctly, what you're saying is more like "then the  
> peer SHOULD reply using a 200 OK, unless it replies using a 302  
> Moved Temporarily to indicate other peers". The current text  
> doesn't require the peer to respond with either message (MAY  
> doesn't clearly say "this is the ELSE for a SHOULD").

Your understanding is correct.
We will try to fix the text.

> Spencer: at some point it will be necessary to describe behavior  
> during request timeouts, when zero replies have been received.

Yes.

> Spencer: is this pointing to the right place? Section 7 is  
> "security considerations", which does talk about credentials for  
> bootstrapping in section 7.1 but doesn't seem to actually describe  
> a "procedure".

Hmm.. For some reason, all the references to section 6 ("Common  
Procedures") came out instead as section 7.

> Spencer: Why is this SHOULD not a MUST? As it stands, the  
> requirement is that SIP registrars ought to do this almost all the  
> time, but peers can't count on them doing it so must accommodate  
> registrars that do not.

I guess we need guidance on SHOULD and MUSTs.
Is everything a MUST unless there is a good reason to be a SHOULD,
or is everything a SHOULD unless there is a good reason to be a MUST?

We were trying for the latter approach.

> Spencer: I'm reading this as saying "different set of peers for the  
> same overlay regstered with different Bootstrap Servers", but I'm  
> guessing - the text doesn't actually say whether this paragraph is  
> talking about one overlay or multiple overlays.

Your reading is correct.
Will try to clarify this in the next revision.

> Spencer: Why not MUST here? What happens if the peer uses another q  

I think things work out OK..
If a peer registers with a q value of .5, then it will never be  
selected as a bootstrap peer
until there are no other bootstrap peers (for the same overlay) with  
higher q values.

> Spencer: Both of these SHOULDs should be MUSTs, shouldn't they? I'm  
> reading them as "SHOULD, unless you don't want to indicate..." -  
> your text has clear conditional text, so I'd expect the  
> requirements to be MUST (given that the peer wants to indicate  
> "proxy" or "no-fork"). And I'm not sure whether you're expecting  
> this directive to always be "proxy, no-fork" or not - the following  
> text seems to assume that it is.

See comments on MUST vs SHOULD above.

> Spencer (nit): this is actually section 6.4.

Yup. Another broken reference.

> Spencer: I don't think RECOMMENDED is needed here (in 2119  
> language). Perhaps if more procedures are added in later versions  
> of the draft, this would be needed, but this basically says that if  
> you want to use the bootstrap server method to join an overlay, you  
> should probably do just that...

Maybe I don't understand what you mean  (<---- and this is likely)
but we recommend that peers try multiple bootstrap servers.
If a peer does not, well, I am sure you can see what would happen.

>
> Spencer: it would be good to say what happens if none of the  
> Bootstrap Servers know about the overlay... assume this is a  
> problem with the bootstrapping servers, or a problem with the overlay?

If the joining peer is not successful at contacting a bootstrap peer,
then it should assume the overlay does not exist and create the
overlay itself.

We should add words to this effect.

> Spencer (Nit): again, I think this is section 6.
Yup.

> Spencer: "the rules of [RFC3261] apply" is probably more ESL-friendly.

OK.

> Spencer: I'm not sure I understand why this restriction exists - is  
> it simply that any of the media streams would be interchangeable,  
> so there's no reason to include more than one? - and assuming that  
> the restriction is required, I'm not sure why this is a SHOULD and  
> not a MUST. Peers can simply reject violated MUSTs, but probably  
> have to do something sensible for violated SHOULDs in a P2P world.

Perhaps the SHOULD should be a MUST.

> Spencer: If the offer or answer DOES include one of these  
> attributes, is there a specific response that's required?

Good question.
It should probably be rejected with some  error code.
We will investigate for a future revision.

> Spencer: I'm really wondering why ICE is a SHOULD. Is this the  
> "unless you know you're on the same subnet" reason? I note that  
> Jonathan is saying that ICE is a "core extension" that everyone  
> needs to implement.

See comment on ICE earlier.

> Spencer (Nit): "ICE to decide whether"?

OK.

> Spencer: this is not a MUST? or MUST/unless? Perhaps "Peers must  
> transmit keep-alives on the control channel" - and sometimes this  
> is hyphenated, and other times not, so consistency would be good.

Consistency would be good.
This is an informational observation which justifies the next sentence.
Perhaps it should be moved elsewhere or just removed.

> Spencer: is this "MUST, if you run keepalives"? I'm OK with a  
> "conditional MUST" here.

Right now, we mean MUST use some keep-alive mechanism and SHOULD use
STUN Binding Indications.

> Spencer: is the ordering important here? I'm not sure it seems  
> important to the text.

Perhaps not.
We have only spent a little bit of time thinking about this.

> Spencer: Is there any intention to request a well-known multicast  
> address for P2PSIP? It might be nice to say so explicitly, either  
> way, so no one else will ever wonder if you really thought about  
> IANA, or just started with a draft template that said "no IANA  
> considerations" :-)

Why can't P2PSIP use the one for SIP (which is what we say in the  
draft)?