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

Gonzalo Salgueiro <gsalguei@cisco.com> Thu, 22 August 2013 20:38 UTC

Return-Path: <gsalguei@cisco.com>
X-Original-To: insipid@ietfa.amsl.com
Delivered-To: insipid@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42C3311E8123 for <insipid@ietfa.amsl.com>; Thu, 22 Aug 2013 13:38:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.127
X-Spam-Level:
X-Spam-Status: No, score=-9.127 tagged_above=-999 required=5 tests=[AWL=-0.828, BAYES_00=-2.599, MANGLED_SAVELE=2.3, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IdDV8NWsmzay for <insipid@ietfa.amsl.com>; Thu, 22 Aug 2013 13:38:45 -0700 (PDT)
Received: from av-tac-bru.cisco.com (weird-brew.cisco.com [144.254.15.118]) by ietfa.amsl.com (Postfix) with ESMTP id C330B21F9F9B for <insipid@ietf.org>; Thu, 22 Aug 2013 13:38:44 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-bru.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7MKcgeZ018145 for <insipid@ietf.org>; Thu, 22 Aug 2013 22:38:43 +0200 (CEST)
Received: from rtp-gsalguei-8917.cisco.com (rtp-gsalguei-8917.cisco.com [10.116.132.56]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r7MKcgn4025586; Thu, 22 Aug 2013 16:38:42 -0400 (EDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Gonzalo Salgueiro <gsalguei@cisco.com>
In-Reply-To: <52167416.2000900@alum.mit.edu>
Date: Thu, 22 Aug 2013 16:38:42 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <67427D45-7AA2-4DFE-87CC-A8FBC4A28451@cisco.com>
References: <9904FB1B0159DA42B0B887B7FA8119CA128B4D41@AZ-FFEXMB04.global.avaya.com> <5216458A.5040608@nostrum.com> <AEEDE5E6-54CE-4557-B03B-4341B00F3EC3@oracle.com> <52167066.7040605@nostrum.com> <52167416.2000900@alum.mit.edu>
To: Paul Kyzivat <pkyzivat@alum.mit.edu>
X-Mailer: Apple Mail (2.1508)
Cc: insipid@ietf.org
Subject: Re: [Insipid] [Gen-art] Gen-ART review of draft-kaplan-insipid-session-id-03.txt
X-BeenThere: insipid@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Session-ID discussion list <insipid.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/insipid>, <mailto:insipid-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/insipid>
List-Post: <mailto:insipid@ietf.org>
List-Help: <mailto:insipid-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/insipid>, <mailto:insipid-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 22 Aug 2013 20:38:49 -0000

My thoughts are we don't need to continue beating this lifeless horse, but alas I'll comment...

On Aug 22, 2013, at 4:27 PM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> At this point I am half tempted to suggest that we just agree to publish the Kaplan draft as historic, and then close this WG.
> 
> I say this because I don't think:
> - we can reach agreement to make the Kaplan draft an RFC.

Agreed.

> - the current work is going to yield something
>  that will achieve its goals and be backward compatible

Speculative at best.

> - pursuing the current work with a new header name would
>  achieve wide deployment, given that a fairly large
>  community is committed to Session-ID.

Discussions in Berlin with Laura and other strong supporters of the 3GPP solution (i.e., the Kaplan draft) have assured me that they plan to adopt the new Session-ID mechanism, so long during the transition it can be backwards compatible with the old Sess-ID that is widely deployed on their networks.

Cheers,

Gonzalo

> 
> 	Thanks,
> 	Paul
> 
> 
> On 8/22/13 4:11 PM, Robert Sparks wrote:
>> On 8/22/13 2:16 PM, Hadriel Kaplan wrote:
>>> Actually I consciously left the IANA section as registering the
>>> header, and it was not an oversight.
>>> 
>>> For background: I did not submit the draft as Informational originally
>>> in version-00 - I submitted it as Historic, and was asked by the
>>> shepherding AD to change it to Informational later, based on IESG
>>> feedback (I think; I could be wrong about it being from IESG feedback).
>>> 
>>> Once it became Informational, we (myself, the AD, and the WG chairs)
>>> did actually discuss whether it would register the header in IANA or
>>> not.  My understanding was that this Informational draft *would* in
>>> fact register the new header in IANA.  Technically there's nothing
>>> wrong with that, afaik, other than I do need to get Designated Expert
>>> review as Dan correctly pointed out.
>>> 
>>> We discussed that once the WG draft-ietf-insipid-session-id is
>>> published, it would then update IANA's entry for the header to point
>>> to the new WG RFC.  Whether the WG draft-ietf-insipid-session-id text
>>> needs to change to make that clear or not, or change to extend the
>>> already-registered header or not, etc., is of course also still
>>> change-able.
>>> 
>>> 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.  If we decide that's ok, then I think it actually needs to
>>> register a new header name regardless.  We know 'Session-ID' is
>>> already in-use in the wild, and there are plenty of more strings
>>> available for header names.
>> As you note, and as RFC5727 allows, we _can_ register a header with an
>> Informational RFC, as long as it meets the two restrictions in that
>> document.
>> (And I believe this one does). I also think the IESG could be convinced
>> that a Historic RFC would meet those requirements, and I don't think it
>> was the intent to exclude them when RFC5727 was put together.
>> 
>> I, obviously, expected that since there _was_ a standards effort around
>> this concept, and an expectation that it would use the same name in a
>> backwards compatible way, that the standards track document would do the
>> registration, and there would be some relationship like the one Dan
>> points to in order to tie in this document.
>> 
>> I don't really care if we thread the registration differently, as long
>> as we leave a _very_ clear record of what's happening since there is
>> standards activity here. I don't think we have that in the current
>> document.
>> 
>> But my _main_ concern is that this still reads like a PS, and I would
>> rather we take the time to change the language to be clear it's
>> documenting a current situation rather than providing instructions to
>> new implementers.
>> 
>> RjS
>>> 
>>> -hadriel
>>> 
>>> On Aug 22, 2013, at 1:08 PM, Robert Sparks <rjsparks@nostrum.com> wrote:
>>> 
>>>> Adding the working group.
>>>> 
>>>> Dan - thanks for this review. I've been working towards trying to
>>>> express a concern, and this really helped clarify what was bothering me.
>>>> 
>>>> This document, AFAIK, _is not_ actually trying to register the
>>>> Session-ID header with IANA, even though there is a section that
>>>> looks like it does.
>>>> 
>>>> Rather, that registration is in
>>>> http://datatracker.ietf.org/doc/draft-ietf-insipid-session-id/
>>>> 
>>>> That is a very good example of how just adding the explanatory
>>>> paragraph at the beginning of the document isn't enough to turn this
>>>> into something that documents an earlier path considered and
>>>> implementation that exists current deployments - the text needs to be
>>>> touched in several places to make it clear that's what the document
>>>> is doing.  In the IANA considerations case, one possible adjustment
>>>> is to change the text to "here's what known implementations have used
>>>> for syntax. See [draft-ietf-insipid-session-id] for the intended
>>>> registered syntax", and not issue instructions to IANA.
>>>> 
>>>> It's more work for Hadriel, but I think it's necessary.
>>>> 
>>>> RjS
>>>> 
>>>> 
>>>> On 8/21/13 12:26 PM, Romascanu, Dan (Dan) wrote:
>>>>> I am the assigned Gen-ART reviewer for this draft. For background on
>>>>> Gen-ART, please see the FAQ at
>>>>> 
>>>>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>>>> 
>>>>> Please resolve these comments along with any other Last Call
>>>>> comments you may receive.
>>>>> 
>>>>> Document: draft-kaplan-insipid-session-id-03.txt
>>>>> Reviewer: Dan Romascanu
>>>>> Review Date: 8/21
>>>>> IETF LC End Date: 8/30
>>>>> IESG Telechat date:
>>>>> 
>>>>> Summary:
>>>>> Ready with Issues
>>>>> 
>>>>> Major issues:
>>>>> 
>>>>> 1. In similar situations when IETF WGs decided to document
>>>>> proprietary solutions that were used as a basis for standards-track
>>>>> RFCs Historic RFCs were issued rather than Informational RFCs. See
>>>>> for example RFC 5412, 5413, 5414 which documented the prior art that
>>>>> was used to create RFC 5415. Publication of these documents was also
>>>>> withhold until the standards-track RFC was published. None of these
>>>>> precedents is followed here. One of the reasons for the WG to prefer
>>>>> Informational rather than Historic is the fact that the registration
>>>>> of a new SIP header field is required from IANA, and in conformance
>>>>> with RFC 5727 this can be done in an Informational RFC, but not in a
>>>>> Historic one. What is missing however is clear text that the
>>>>> solution described in this document is a legacy solution and that
>>>>> the solution going forward is the one that is being defined by the
>>>>> INSIPID WG. The IESG should also consider whether this document
>>>>> should be approved for publication before the standar
>> ds-t
>>>>>  rack solution defined by the INSIPID WG is also published.
>>>>> 
>>>>> 2. The Abstract makes the claim that the Standards-Track RFC that
>>>>> will be eventually produced by the INSIPID WG will be developped in
>>>>> a backwards-compatible manner with this document. This does not seem
>>>>> appropriate here - if at all such a requirement should be included
>>>>> in draft-ietf-insipid-session-id-reqts-08.txt. However it does not
>>>>> appear there, and that document was recently submitted for
>>>>> publication to the IESG, so the WG did not include it in its consensus.
>>>>> 
>>>>> Minor issues:
>>>>> 
>>>>> 1. The IANA considerations sections need to be more explicit in
>>>>> demonstrating that the conditions for registration of extension SIP
>>>>> header fields in Informational RFCs have been met as per RFC 5727.
>>>>> That RFC defines that Designated Expert review needs to happen for
>>>>> such new registrations - I could not find a proof that such a review
>>>>> took place in the shepherd write-up. Actually the question about the
>>>>> expert reviews is not answered directly, instead of an answer wide
>>>>> deployment is mentioned, but that deployment could not use this SIP
>>>>> header field which was not yet approved. According to RFC 5727 there
>>>>> are two basic conditions that need to be verified by the Designated
>>>>> Expert - that the proposed header field must be of a purely
>>>>> informational nature and must not significantly change the behavior
>>>>> of SIP entities that support it, and that the proposed header field
>>>>> must not undermine SIP security in any sense, and that the
>>>>> Informational RFC defining the header field must addres
>> s se
>>>>>  curity issues in detail, as if it were a standards-track document.
>>>>> I believe that both conditions are met by the I-D, but there is no
>>>>> adequate text in the IANA considerations section to explain this.
>>>>> 
>>>>> Nits/editorial comments:
>>>>> 
>>>>> 
>>>>> Regards,
>>>>> 
>>>>> Dan
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> Gen-art mailing list
>>>>> Gen-art@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/gen-art
>>>> 
>> 
>> 
>> _______________________________________________
>> insipid mailing list
>> insipid@ietf.org
>> https://www.ietf.org/mailman/listinfo/insipid
>> 
> 
> _______________________________________________
> insipid mailing list
> insipid@ietf.org
> https://www.ietf.org/mailman/listinfo/insipid
>