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