A SIP Usage for REsource LOcation And Discovery (RELOAD)
draft-ietf-p2psip-sip-21

I'm balloting "yes" because I want to see this move forward, but I have a number of comments and questions:

Substantive:

- Figure 1: It might be helpful to show the R-URI in the INVITE.

- 1, 2nd to last paragraph: Please add a citation for GRUU.

- 3.3, 7th paragraph from end: "any peer SHOULD verify
   that the AOR of the request is a valid Resource Name with respect to
   its domain name "
How does that differ from the MUST in the first bullet, below? Also, does SIP over reload support phone numbers? If so, it would be good to include some discussion about how phone numbers fit into the domain scheme. If no, then please say so explicitly.

-3.3, 3rd and 4th paragraph from end:
What certificate? (Probably covered in RELOAD, but a comment here would be helpful.)

- 3.4, first paragraph:
The "MAY" looks like a statement of fact. I suggest "might"

- 3.4, fourth paragraph:
That seems to say that "enable=false" means the restrictions are enabled. Is that the intent?

- 4.1, 2nd and 3rd paragraphs from end:
Does that mean normal SIP procedures should be used if no overlay is found for the domain, or that normal SIP procedures can be used instead of checking for other overlays?

What about the case where the domain is supported by the overlay, but the AOR is not found? Should the caller check for other overlays, or switch to standard SIP?

- 5.1, 2nd paragraph:
Are SIPS over reload connections assumed to be e2e encrypted? The last sentence says that ordinary SIPS requires e2e encryption, which is simply not true.
What are "client links"?

- 5.1, 3rd paragraph, last sentence:
does "redirect its communication path" mean redirect to classic SIP?

- 6, first paragraph: "Globally Routable User Agent URIs (GRUUs) [RFC5627] have been
   designed to allow direct routing without the indirection of a SIP
   proxy function. "
That’s not really true. 5627  section 3.4 talks about using the proxy to dereference a gruu.

- 8.1, first paragraph: "Hence no
   extra burden is introduced for RELOAD peers beyond loads already
   present in the base protocol."
What about from when a caller chooses to switch to conventional SIP to reach a callee with a domain not supported by the overlay?

- 8.2.4: Can you cite something for these methods that exist?

Editorial:

- IDNits has some comments marking code blocks. The data structure in 3.2 seems to qualify.

-2 : It would have been useful to mention that you are intentionally dropping the AoR schemes back at the first AoR example.
Otherwise SIP people are going to be confused until they find the comment 5 pages in.

- 3.1, first paragraph: "a UA registers its AOR and location"
technically, the user’s AOR and the UAs network location.

- 3.2, 3rd bullet in first bullet list:
It's a bit premature to use the term Callee. Perhaps Registrant?

- 4.2, step 3:
What is an "external AoR"?

- Appendix A: Why is this not in the main body?

This was a bit confusing to me.

   AOR domain not supported by overlay?  If the domain part of the AOR
      is not supported in the current overlay, the user SHOULD query the
      DNS (or other discovery services at hand) to search for an
      alternative overlay that services the AOR under request.
      Alternatively, standard SIP procedures for contacting the callee
      SHOULD be used.
      
If you don't query the DNS (or other discovery services), and you don't use standard SIP procedures, are there any other choices? With both of these being SHOULDs, a conformant implementation might not do either of them. Is that expected?

If you need this to be RFC 2119 language, I'm guessing this would be "MUST either do X or Y", but I'm not sure it needs to be RFC 2119.

If you really do need two alternative SHOULDs, it's not required to explain why a SHOULD is not a MUST, but since the goal is that an implementer is making an informed choice, helping the implementer understand why one might not want to do what one SHOULD do is usually helpful.

I think that 

   A callee MAY choose to listen on both
   SIP and SIPS ports and accept calls from either SIP schemes, or
   select a single one. 
   
is using "SIP schemes" generically, but this might be clearer if you just said "either scheme".

I'm not on top of SIPS these days, but I didn't think

   SIPS requires end-to-end protection that may include client links and
   endpoint certificates.
   
was "end-to-end protection". Is it? I thought that it was protected-hop-by-protected-hop. Or maybe you only mean SIPS in P2PSIP? 

Sorry if I'm confused (and the SIP Forum will be thrilled to hear this, if I'm just confused).

I can figure out what "fork explosion" and "fork bomb" are, but are these terms in common usage in the SIP community? Is there a definition or reference for them?