Hi Hadriel, the additional IPR disclosure is already out. Could you please revise the draft per my email below so that I can IETF LC it again?
Thanks, Gonzalo On 20/09/2013 10:52 AM, Gonzalo Camarillo wrote: > 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 >> >> >
