Re: Piling on [Gen-art] Gen-ART review of draft-kaplan-insipid-session-id-03.txt

[Gonzalo Camarillo <[e-mail]>]

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