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

Adam Roach <adam@nostrum.com> Fri, 13 September 2013 16:22 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA9EF21F9DC7; Fri, 13 Sep 2013 09:22:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.6
X-Spam-Level:
X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
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 sXCDsfCVsiFs; Fri, 13 Sep 2013 09:22:37 -0700 (PDT)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC7F21E80A7; Fri, 13 Sep 2013 09:22:36 -0700 (PDT)
Received: from orochi-2.roach.at (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r8DGMRVh044563 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Fri, 13 Sep 2013 11:22:27 -0500 (CDT) (envelope-from adam@nostrum.com)
Message-ID: <52333BBE.6020706@nostrum.com>
Date: Fri, 13 Sep 2013 11:22:22 -0500
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
Subject: Re: Piling on [Gen-art] Gen-ART review of draft-kaplan-insipid-session-id-03.txt
References: <201309041941.r84Jfm7H004331@rcdn-core-1.cisco.com> <52319BD8.2080106@ericsson.com>
In-Reply-To: <52319BD8.2080106@ericsson.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass (shaman.nostrum.com: 99.152.145.110 is authenticated by a trusted mechanism)
Cc: IETF list <ietf@ietf.org>, The IESG <iesg@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Sep 2013 16:22:37 -0000

On 9/12/13 05:47, Gonzalo Camarillo wrote:
> Therefore, this draft registers the Session-ID header field with the
> IANA. The designated expert is reviewing this registration, per the
> rules in RFC 5727.

Yes, I am, and the only reason I didn't rubberstamp this for 
registration as soon as it hit my inbox is exactly the confusion that 
having two documents that register the same header field is likely to cause.

I've only been peripherally following the events in INSIPID, but I was 
aware of the existence of a draft intended to document historical usage 
as well as a separate standards-track document to publish a consensus 
mechanism (possibly including some degree of backwards compatibility 
with historical usage). Like Robert, I didn't expect the "historical 
usage" document to perform any registration, and was quite confused when 
the IANA approached me about doing so.

I don't have a really strong opinion about whether draft-kaplan creates 
a new entry in IANA that is replaced by a reference to 
draft-ietf-insipid when it is published (versus not registering 
anything, and then having the WG consensus document perform the 
registration). That's not to say that I don't have an opinion on the 
topic; I just don't feel strongly enough about it to wrestle about it.

Here's what I do feel strongly about: whatever the plan of record needs 
to be clearly recorded in a place that people will find it. If 
draft-kaplan registers Session-ID, we need two changes to the existing 
documents: First, draft-kaplan needs to be crystal clear about the plan 
of record its section 10 (e.g., "This registration is intended to be 
temporary, and should be removed when [draft-ietf-insipid-...] is 
published.")  Secondly, draft-ietf-insipid must clearly state that its 
IANA registration *removes* the old reference and *completely* replaces 
it with a pointer to the standards-track document.

The situation that I want to ensure cannot happen is an IANA-registered 
SIP header field that points to two documents simultaneously, especially 
if the ABNF is not absolutely identical between the two documents.

/a