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 22:29 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 D99F321F9CF5 for <insipid@ietfa.amsl.com>; Thu, 22 Aug 2013 15:29:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.5
X-Spam-Level:
X-Spam-Status: No, score=-6.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, 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 OnEAoakq0OTS for <insipid@ietfa.amsl.com>; Thu, 22 Aug 2013 15:29:36 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 433C821F9CC3 for <insipid@ietf.org>; Thu, 22 Aug 2013 15:29:36 -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 r7MMTX9g021577 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 22 Aug 2013 22:29:34 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 r7MMTXRk019722 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 22 Aug 2013 22:29:33 GMT
Received: from abhmt106.oracle.com (abhmt106.oracle.com [141.146.116.58]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7MMTXlj010392; Thu, 22 Aug 2013 22:29:33 GMT
Received: from [10.1.21.34] (/10.5.21.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 22 Aug 2013 15:29:32 -0700
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Hadriel Kaplan <hadriel.kaplan@oracle.com>
In-Reply-To: <52167416.2000900@alum.mit.edu>
Date: Thu, 22 Aug 2013 18:29:30 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <8CF6DFC8-FA1F-4F65-BE10-DBF53950665E@oracle.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)
X-Source-IP: ucsinet22.oracle.com [156.151.31.94]
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 22:29:43 -0000

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.

We don't need to "reach agreement" to publish an Informational RFC.  It's not standards-track, and not even a WG doc.  All it was ever going to be published as was Informational, as far back as 2010.


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

I think it's premature to give up on it.  I mean we haven't failed yet, afaik.  We only really started getting down to the nitty-gritty stuff this past month.


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

I think there might be conflicting goals/requirements within the WG.  Fulfilling one might conflict with fulfilling the other.  It's not just about backwards-compatibility, but also about the need for re-INVITEs/UPDATEs.  A new header name might avoid those conflicts.  For vendors that want/need to handle conference servers and updating all participants with the new correlation value, a new header would be usable.  For ones that just need to correlate the basic call scenarios without extra messages, the legacy one would be usable.

-hadriel