A SIP Usage for REsource LOcation And Discovery (RELOAD)
RFC 7904
Yes
No Objection
Note: This ballot was opened for revision 17 and is now closed.
Alvaro Retana No Objection
(Alissa Cooper; former steering group member) Yes
(Ben Campbell; former steering group member) Yes
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?
(Spencer Dawkins; former steering group member) Yes
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?
(Alexey Melnikov; former steering group member) (was Discuss) No Objection
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?
(Deborah Brungard; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
(Kathleen Moriarty; former steering group member) No Objection
(Mirja Kühlewind; former steering group member) No Objection
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?
(Stephen Farrell; former steering group member) No Objection
- 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?
(Suresh Krishnan; former steering group member) No Objection
(Terry Manderson; former steering group member) No Objection