[dhcwg] Update to status of RFC3315 option code registry?

Ted Lemon <mellon@fugue.com> Thu, 30 October 2014 19:41 UTC

Return-Path: <mellon@fugue.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7A8801A2119 for <dhcwg@ietfa.amsl.com>; Thu, 30 Oct 2014 12:41:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Za81ix_zJuW6 for <dhcwg@ietfa.amsl.com>; Thu, 30 Oct 2014 12:41:07 -0700 (PDT)
Received: from toccata.fugue.com (toccata.fugue.com [204.152.186.142]) by ietfa.amsl.com (Postfix) with ESMTP id 833491A1B92 for <dhcwg@ietf.org>; Thu, 30 Oct 2014 12:41:07 -0700 (PDT)
Received: from [10.0.20.107] (c-71-233-43-215.hsd1.nh.comcast.net [71.233.43.215]) by toccata.fugue.com (Postfix) with ESMTPSA id E84412380340 for <dhcwg@ietf.org>; Thu, 30 Oct 2014 15:41:06 -0400 (EDT)
From: Ted Lemon <mellon@fugue.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_ADC8E321-3643-427B-B904-2C1A51FB4CC8"
Message-Id: <10DCB24C-3A07-4171-B49E-026BC1DB14D8@fugue.com>
Date: Thu, 30 Oct 2014 15:41:04 -0400
To: dhcwg <dhcwg@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/dhcwg/2tMDOizTmeSMQ4ArGfydyeVrRWk
Subject: [dhcwg] Update to status of RFC3315 option code registry?
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg/>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Oct 2014 19:41:10 -0000

Currently RFC 3315 says this about registering option codes:

  New DHCP option codes are tentatively assigned after the
  specification for the associated option, published as an Internet
  Draft, has received expert review by a designated expert [11].  The
  final assignment of DHCP option codes is through Standards Action, as
  defined in RFC 2434 [11].

This led to the registry being marked as requiring _both_ expert review and standards action.   The original context in which this text was written, as I recall, was that we had had a big problem with vendors camping on DHCPv4 option codes and not telling us, and we wanted this to not happen for DHCPv6.   So we carved out an exception to incentivize vendors to document their use of option codes, and to get legitimate option code allocations, rather than just picking a number and hoping for the best.

So I think what the above language intends is:

If there is a standards-track document published that allocates option codes, then they should get expert review, but the presence of the standards track document means that there is a presumption that once the document describes something that is acceptable, it definitely gets an option code.
If there is a non-standards-track use for an option, we can allocate an option code for that use, but this allocation requires expert approval, and is tentative.   What it means for it to be tentative is that if it turns out that whatever use the option code had doesn't see widespread deployment, then at some point the option code is returned to the free pool.   The mechanism whereby that happens is likely some sort of working group action and expert review.

This came up recently in the context of draft-ietf-softwire-4rd, which is an experimental document, yet defines new DHCP option codes.   I think in principle we want to be able to allocate options in this case, but the current registry language prevents us from doing so.   So Adrian raised a DISCUSS on this.   I explained the context for the registry language, and he asked me to do a document that updates the registry status, in exchange for which he cleared his DISCUSS.

By "me" here, of course, he means the DHC working group, or so I'm going to claim, for two reasons.   First, it's less work for me, which I always like.   Second, the working group is in the process of updating RFC 3315.   Maybe we can fold this change into the updated document.   Or maybe that will take too long and we should do a short document.

Thoughts?