Bah - failed to copy genart. RjS -------- Forwarded Message -------- Subject: Gen-art LC review: draft-holmerg-dispatch-iotl-03.txt Date: Thu, 18 Dec 2014 15:09:23 -0600 From: Robert Sparks To: draft-holmberg-dispatch-iotl@tools.ietf.org, dispatch@ietf.org, ietf@ietf.org I am the assigned Gen-ART reviewer for this draft. For background on Gen-ART, please see the FAQ at . Please resolve these comments along with any other Last Call comments you may receive. Document: draft-holmberg-dispatch-iotl-03 Reviewer: Robert Sparks Review Date: 18-Dec-2014 IETF LC End Date: 8-Jan-2015 IESG Telechat date: Not on an upcoming telechat agenda Summary: Almost ready for publication as a Proposed Standard but has issues that need to be addressed There are only a few issues to address: Major Issue 1: It makes no sense to publish a standards track RFC that says behavior on general networks is undefined. I've reviewed all of the list traffic about this document, and I understand how the text that's currently in the document got there, but it's not the best way to deal with the concern that caused it to be introduced. The original concern was that the document didn't provide enough detail to tell what the presence or absence of the values meant, and whether there was an associate d change to the semantics of the protocol. While the description is thin, I think there has been enough shown to know that the semantics of the protocol are not being changed. So, instead, the document should just recognize that devices that don't implement this specification will do what RFC 3261 requires them to do with unknown URI parameters: ignore them. This document sufficiently describes what the values it defines means to elements that _do_ implement this specification. They provide additional information to upper layers (ultimately, transaction users as 3261 defines them), and those upper layers might make forwarding decisions using it, just like they can use _anything_ at their disposal. The basic semantics of the SIP protocol are unaffected. To resolve this issue, I suggest removing the text that occurs in several places saying that this is applicable only to 3gpp networks, and add a short sentence reminding the reader that RFC3261 expects new URI parameters to be standardized and defines how unknown URI parameters are handled. Major Issue 2: The document suggests that implementations violate what RFC3261 requires them to do. Specifically, it says "An entity that understands the 'iotl' parameter MUST NOT, from a SIP request, remove 'iotl' parameters from SIP URIs associated with other entities, unless the entity has means to determine that the 'iotl' parameter does not represent a valid traffic leg." RFC3261 requires that MUST NOT, and it does not allow the "unless" clause. It is not ok for an entity to change some other entities URIs in, say, Route, Service-Route, Path, and similar places under any circumstances. My suggested resolution is to remove the unless clause, and change the first part of the sentence to note that this is what 3261 requires. Major issue 3: The Security considerations section is incomplete. Please discuss the ramifications of something maliciously providing an incorrect value in the parameter. What are the ramifications if someone does violate protocol and changes or removes a value in transit? Minor issue 1: It is unclear where you expect these URIs to occur. I have a good feel only after reading the list traffic. I suggest you be explicit in 5.1 that you expect these to be placed in Service-Route and Path header field values, hence to occur in Route header field values, and Request-URIs. Minor issue 2: Why do you say "This document does not specify the usage of the 'iotl' parameter within a SIP URI of a Record-Route header field. Would it create an interoperability problem if someone put one there? Because if they do, it will end up in Route header fields later. If that's ok, please strike the sentence. If it's not, then you need to say MUST NOT place the parameter in URIs in Record-Route header field values. Nits/editorial comments: Since you are providing an extension point for other values, someone will ask if you need a registry for those values. I suggest explicitly saying we are not creating a registry at this time but expect to do so if the extension point is ever used to head that conversation off. "dialogue" appears in a couple of places. Since we're talking about the 3261 term, I suggest using "dialog" consistently. The sentence (which occurs in the abstract and introduction) "The directionality in traffic legs relates to a SIP request creating a dialogue and stand-alone SIP request." does not parse. What is it trying to say, and why is it important?