Re: [Insipid] Timing for publishing draft-kaplan-insipid-session-id

[Robert Sparks <[e-mail]>]

FWIW:

The WG was copied on the genart-thread, so you should have seen the 
whole thing here.

That said, the archives for genart are open. You can find the whole 
thread starting here:
<http://www.ietf.org/mail-archive/web/gen-art/current/msg08909.html>

You can see Dan's original genart review by hitting [Thread Prev] on 
that page.

RjS

On 9/11/13 3:26 PM, James Polk wrote:
> At 09:14 PM 9/10/2013, Hadriel Kaplan wrote:
>
>> I don't know if you read the rest of the Gen-ART review thread - it 
>> moved off of the ietf list
>
> I have looked and cannot find this Gen-ART review ever on the IETF 
> list. I have been told it never was on the IETF list, rather it was 
> only on the Gen-ART list, which most of us are *not* on, so limiting 
> the posting of a review to that list is next to useless (IMO - but I 
> could be wrong).
>
>>  to this INSIPID WG mailing list.
>
> yep, I've read all 13 messages on that thread.
>
>
>> See this one:
>> http://www.ietf.org/mail-archive/web/insipid/current/msg00680.html
>>
>> Other comments inline...
>>
>>
>> On Sep 10, 2013, at 7:09 PM, James Polk <[e-mail]> wrote:
>>
>> > I, however, do not agree with draft-kaplan-insipid-session-id being 
>> published as an informational RFC before the INSIPID solution is 
>> published as a standards-track. Nor do I want this document IANA 
>> registering the SIP header Session-ID, such as it currently attempts 
>> to do. At best, they should be consecutive RFC numbers with the 
>> INSIPID solution number having the lower number. If that means the 
>> kaplan draft has to wait in the RFC-Editor queue for the solution 
>> draft - so be it. That's what Dan R. from his Gen-Art review stated 
>> as his first major issue with the kaplan draft. Robert Sparks backed 
>> that opinion up by agreeing with that (and the rest of Dan's review). 
>> Gonzalo Salgueiro, one of INSIPID's WG chairs, says he stated that 
>> same view in a previously sent email to this list.
>> >
>> > INSIPID, from its inception, has had the charter item to IANA 
>> register this SIP header
>>
>> It's a nit, but the INSIPID charter does not mention a particular 
>> header labeled 'Session-ID'.
>
> you're right. However, from before the WG was chartered what 
> eventually became the WG solutions draft was in play, creating the 
> Session-ID header, so it's not like the WG, once formed, debated on 
> what the header should be called.
>
>
>
>> > , and the draft-kaplan-insipid-session-id is not even a WG item, so 
>> why is everyone now in such a rush to have this draft do what a WG is 
>> supposed to do? Could it be the kaplan draft couldn't create a WG to 
>> form consensus on its own
>>
>> Actually, as far as I know, the older kaplan drafts are in fact what 
>> triggered creation of the INSIPID WG.  No?
>
> they wondered for better than 5 years before the WG was created. By 
> that time, a requirements doc and another solution doc were published 
> (i.e., before and during discussions in DISPATCH).
>
>
>> I never re-submitted it for consideration as an INSIPID WG draft, 
>> because the requirements document has a requirement the older kaplan 
>> drafts didn't fulfill while the Cisco draft did.  I don't care who 
>> authors drafts; in fact I usually prefer it's someone else, because 
>> getting IETF drafts published is a major pain.  :)
>
> you don't have to tell me about that hassle... ;-)
>
>
>
>> > , so now folks are wanting to rush ahead of themselves to claim WG 
>> consensus where there wasn't any such consensus within any WG, let 
>> alone INSIPID?
>>
>>
>> I believe that technically it's not a WG document, and no WG 
>> consensus is being asked for.
>
> No, it's absolutely _not_ a WG product. That doesn't mean it's not 
> trying - intentionally or not - to get around the process started by 
> an existing WG in the IETF.
>
>
>> The reason it makes sense to publish the kaplan draft *before* the 
>> INSIPID WG one is because of the decision to make the INSIPID one 
>> backwards-compatible.
>
> You state that as if you have no faith in the WG to make sure the new 
> solution will be as backwards compatible with the old version as it 
> can be... and I find that troubling, considering just how easy it is 
> for someone to throw a monkey wrench in the process within the rules 
> of the process.
>
>> Because of that, arguably the kaplan draft *should* be the first one 
>> to register the header name and define the ABNF, and then the INSIPID 
>> WG one can expand the ABNF and update the IANA registration to point 
>> to the INSIPID WG's RFC.
>
> That means that there will be one definition for Session-ID for the 
> couple of months before the INSIPID solution changes the definition 
> and IANA registry ... why do we want to do that? Will it make sense to 
> the IESG to do that?
>
>
>> If the WG draft-ietf-insipid-session-id fundamentally changes the 
>> 'Session-ID' header from what it is in 
>> draft-kaplan-insipid-session-id, in a non-backwards-compatible 
>> fashion, then it won't have met the agreement reached in IETF 85 for 
>> adopting draft-jones-insipid-session-id-0 as the new WG document 
>> solution.
>
> I've always stated we editors of the jones draft will make the 
> solution as backwards compatible with the kaplan draft as possible, 
> but that a 2 value ID will run into problems with a single value 
> implementation, and that should be obvious to everyone who thinks 
> about it for a second.
>
> That said, we have received ZERO comments to our latest proposal that 
> we think actually accomplishes this no matter the version of the 
> endpoint that initiates or receives the SIP message... zero... and 
> that's really disheartening.
>
>> If we decide that's ok, that's fine; but I think we actually need to 
>> register a new header name in that case... something other than 
>> 'Session-ID'.  We know 'Session-ID' is already in-use in the wild, 
>> and there are plenty of more strings available for header names.
>>
>> Don't get me wrong though - this whole thing is weird, and I don't 
>> like the precedent this may set.
>
> If the kaplan draft reaches RFC status before the INSIPID solutions 
> draft does, that's a precedent we'll soon regret all over the IETF. 
> That's why I'm backing Dan's proposal (which Robert and Gonzalo S. 
> agree with) that has your kaplan draft sitting on a shelf until the 
> INSIPID solution draft reaches standards-track RFC status. If that's 
> allowed to happen, this whole thing gets far less weird.
>
> James
>
>
>> -hadriel
>
> _______________________________________________
> insipid mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/insipid