Hi Hadriel, to summarize the status of this IETF LC, we are still expecting (at least) an additional IPR disclosure on this draft (as announced on the INSIPID list). When that happens, I will IETF LC it again.
In the mean time, we need to address the comments related to the IANA registration the draft requests. I have discussed with the expert reviewer (Adam) and adding something along these lines would help: "This registration is intended to be temporary. The authors expect that a standards-track definition of Session-ID will be published at a future date. Assuming such a document is published, it will replace this registration with a reference to itself, at which point this document will no longer be referenced by IANA." You have also received a review from the OPS directorate and I do not think that has been addressed so far. So, while we are waiting for the IPR disclosure, please go ahead and revise the draft. Thanks, Gonzalo On 13/09/2013 6:40 PM, Gonzalo Salgueiro (gsalguei) wrote: > >> Here's what I do feel strongly about: whatever the plan of record needs to >> be clearly recorded in a place that people will find it. If draft-kaplan >> registers Session-ID, we need two changes to the existing documents: First, >> draft-kaplan needs to be crystal clear about the plan of record its section >> 10 (e.g., "This registration is intended to be temporary, and should be >> removed when [draft-ietf-insipid-...] is published.") Secondly, >> draft-ietf-insipid must clearly state that its IANA registration *removes* >> the old reference and *completely* replaces it with a pointer to the >> standards-track document. > > Fully agree. >> >> The situation that I want to ensure cannot happen is an IANA-registered SIP >> header field that points to two documents simultaneously, especially if the >> ABNF is not absolutely identical between the two documents. > > The reality is that the backwards compatibility between the INSIPID Sess-ID > mechanism and the kaplan draft is still undetermined and we cannot yet make a > definitive statement on how it will look. Assuming the Session-ID header > field is (re-)used, the ABNF can't be identical because the session > identifier used for INSIPID MUST address requirements that the kaplan id does > not meet; so construction of the id will be different. At this point the > most that can be said is that one won't break the other (through > non-intersection like using different header field names, etc.) or through > direct backwards compatibility (same header field name but the INSIPID with > expanded ABNF that plays nice with the kaplan id). > > Cheers, > > Gonzalo > >> >> /a > >
