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

[Gonzalo Camarillo <[e-mail]>]

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