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 >
- Re: [Insipid] [Gen-art] Gen-ART review of draft-k… Robert Sparks
- Re: [Insipid] [Gen-art] Gen-ART review of draft-k… Gonzalo Salgueiro
- Re: [Insipid] [Gen-art] Gen-ART review of draft-k… Hadriel Kaplan
- Re: [Insipid] [Gen-art] Gen-ART review of draft-k… Paul Kyzivat
- Re: [Insipid] [Gen-art] Gen-ART review of draft-k… Gonzalo Salgueiro
- Re: [Insipid] [Gen-art] Gen-ART review of draft-k… Paul Kyzivat
- Re: [Insipid] [Gen-art] Gen-ART review of draft-k… Robert Sparks
- Re: [Insipid] [Gen-art] Gen-ART review of draft-k… Paul Kyzivat
- Re: [Insipid] [Gen-art] Gen-ART review of draft-k… Gonzalo Salgueiro
- Re: [Insipid] [Gen-art] Gen-ART review of draft-k… Gonzalo Salgueiro
- Re: [Insipid] [Gen-art] Gen-ART review of draft-k… Hadriel Kaplan
- [Insipid] Are we getting anywhere? Paul Kyzivat
- Re: [Insipid] [Gen-art] Gen-ART review of draft-k… DRAGE, Keith (Keith)