A SIP Usage for REsource LOcation And Discovery (RELOAD)
RFC 7904

Note: This ballot was opened for revision 17 and is now closed.

(Ben Campbell) Yes

Comment (2016-04-19 for -20)
No email
send info
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?

Alissa Cooper Yes

(Spencer Dawkins) Yes

Comment (2016-04-19 for -19)
No email
send info
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?

(Jari Arkko) No Objection

Deborah Brungard No Objection

(Stephen Farrell) No Objection

Comment (2016-04-19 for -20)
No email
send info
- 5.1: I guess it's too late to ask, but I'll ask
anyway, just in case this hasn't yet been implemented
and it's not too late... I can see why you want to
support SIP URIs and can't e.g. only support SIPS URIs
here.  But in supporting SIP URIs couldn't you have
taken an opportunistic security approach to using TLS
and e.g. maybe treated a SIP URI as if it's a SIPS URI
except for the certificate validation step? I do get
that that might restrict re-use of unmodified SIPS
stacks but maybe that'd be ok in this context. Any
chance of considering that or is it too late or a case
where there's not enough energy/interest?  (EIther form
of "no" is a very reasonable answer.)

- Just out of curiosity, are folks deploying this
anywhere?

(Joel Jaeggli) No Objection

Suresh Krishnan No Objection

Mirja Kühlewind No Objection

Comment (2016-04-15 for -18)
No email
send info
The privacy issues text in the security consideration section sounds not very convincing:

8.2.4.  Privacy Issues

   All RELOAD SIP registration data is visible to all nodes in the
   overlay.  Methods of providing location and identity privacy are
   still being studied.  Location privacy can be gained from using
   anonymous GRUUs.

Can you give more details or a reference regarding the methods that are still under study?

(Terry Manderson) No Objection

Alexey Melnikov (was Discuss) No Objection

Comment (2016-04-20 for -20)
No email
send info
In 3.3:

   Before a Store is permitted, the storing peer MUST check that:

   o  The AOR of the request is a valid Resource Name with respect to
      the namespaces defined in the overlay configuration document.

   o  The certificate contains a username that is a SIP AOR which hashes
      to the Resource-ID it is being stored at.

   o  The certificate contains a Node-ID that is the same as the
      dictionary key it is being stored at.

Is there a document that defines how exactly a username and a Node-ID can be represented in an X.509 certificate? If yes, adding a normative reference here would be useful. If not, adding specific details here would be useful.

On page 10:

   Inclusion of a <domain-restrictions> element in an overlay
   configuration document is OPTIONAL.  If the element is not included,
   the default behavior is to accept any AOR.  If the element is
   included and the "enable" attribute is not set or set to false, the
   overlay MUST only accept AORs that match the domain name of the
   overlay.

What happens if "enable" is false/unspecified and patter subelements are included? Are they ignored?

(Kathleen Moriarty) No Objection

Alvaro Retana No Objection