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

Hadriel Kaplan <hadriel.kaplan@oracle.com> Thu, 22 August 2013 19:17 UTC

Return-Path: <hadriel.kaplan@oracle.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 BC04F11E820A; Thu, 22 Aug 2013 12:17:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.369
X-Spam-Level:
X-Spam-Status: No, score=-5.369 tagged_above=-999 required=5 tests=[AWL=-1.070, BAYES_00=-2.599, MANGLED_SAVELE=2.3, RCVD_IN_DNSWL_MED=-4]
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 sfaHwktrZbrn; Thu, 22 Aug 2013 12:16:44 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id EB31911E8203; Thu, 22 Aug 2013 12:16:43 -0700 (PDT)
Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7MJGcjW021701 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Aug 2013 19:16:39 GMT
Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7MJGbqF001140 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Aug 2013 19:16:37 GMT
Received: from abhmt111.oracle.com (abhmt111.oracle.com [141.146.116.63]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7MJGaov019607; Thu, 22 Aug 2013 19:16:36 GMT
Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Aug 2013 12:16:36 -0700
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Hadriel Kaplan <hadriel.kaplan@oracle.com>
In-Reply-To: <5216458A.5040608@nostrum.com>
Date: Thu, 22 Aug 2013 15:16:34 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <AEEDE5E6-54CE-4557-B03B-4341B00F3EC3@oracle.com>
References: <9904FB1B0159DA42B0B887B7FA8119CA128B4D41@AZ-FFEXMB04.global.avaya.com> <5216458A.5040608@nostrum.com>
To: Robert Sparks <rjsparks@nostrum.com>
X-Mailer: Apple Mail (2.1508)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
Cc: "Romascanu, Dan (Dan)" <dromasca@avaya.com>, "gen-art@ietf.org" <gen-art@ietf.org>, "draft-kaplan-insipid-session-id.all@tools.ietf.org" <draft-kaplan-insipid-session-id.all@tools.ietf.org>, "insipid@ietf.org" <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 19:17:08 -0000

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.

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