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 > >