Hi, >> I am the assigned Gen-ART reviewer for this draft. For background on >> Gen-ART, please see the FAQ at >> >> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. >> >> 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. > > I saw that you have raised this issue on the DISPATCH list, so I'll get back > to it later.
Based on the few comments on the DISPATCH list regarding this, I'd suggest we keep the scope as it is. We did ask whether people outside 3GPP have any interest in this, and nobody indicated so. Also, one reason we chose AD sponsored was because of the limited scope. If someone in future wants to use this for some other environment, we can always deal with it at that point. And, as the parameter itself is extendable, there will never be any parser issues when/if new values are defined. Regards, Christer _______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
