[dhcwg] rfc3679bis, or: about allocation of DHCPv4 options (was [IANA #1172829] Request for Early Allocation of DHCPv4 option (draft-ietf-dhc-v6only)

Michael Richardson <mcr+ietf@sandelman.ca> Tue, 23 June 2020 17:38 UTC

Return-Path: <mcr+ietf@sandelman.ca>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B93C3A087B for <dhcwg@ietfa.amsl.com>; Tue, 23 Jun 2020 10:38:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 1JAlqcMKeuND for <dhcwg@ietfa.amsl.com>; Tue, 23 Jun 2020 10:38:17 -0700 (PDT)
Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C74A3A0878 for <dhcwg@ietf.org>; Tue, 23 Jun 2020 10:38:17 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id C985D389A0; Tue, 23 Jun 2020 13:35:35 -0400 (EDT)
Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21sUa7Eq89UT; Tue, 23 Jun 2020 13:35:35 -0400 (EDT)
Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 28A973899D; Tue, 23 Jun 2020 13:35:35 -0400 (EDT)
Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 756B6486; Tue, 23 Jun 2020 13:38:15 -0400 (EDT)
From: Michael Richardson <mcr+ietf@sandelman.ca>
To: dhcwg@ietf.org, Bernie Volz <volz@cisco.com>
In-Reply-To: <20200623153506.CDFE5389AE@tuna.sandelman.ca>
References: <20200623153506.CDFE5389AE@tuna.sandelman.ca>
X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1
X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m<nPbLgmtKK-5dC@#:k
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature"
Date: Tue, 23 Jun 2020 13:38:15 -0400
Message-ID: <2346.1592933895@localhost>
Archived-At: <https://mailarchive.ietf.org/arch/msg/dhcwg/aIIah2t_2Q_SWgQUl_-9VeO62sE>
Subject: [dhcwg] rfc3679bis, or: about allocation of DHCPv4 options (was [IANA #1172829] Request for Early Allocation of DHCPv4 option (draft-ietf-dhc-v6only)
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Tue, 23 Jun 2020 17:38:19 -0000

I hate that ML are not consistently named for the WG. resending with correct
WG ML list name.

...

Bernie, is some of the desire to pick <127 a result of the experience with
CAPPORT's use of 160?

Unfortunately, while I participated in the thread that Jen linked to justify
why ietf-dhc-v6only should have 108, I can't seem to find much discussion
about 108 itself.
(Much of it is not about why 108, and rather about the protocol as a whole)

So, aside from Tomek's original message there isn't much discussion about why
we are going against IANA's normal process here.

Given this recommendation and the experience with CAPPORT, should we be
changing advice to IANA in general?

Is there an need to repeat the delouse effort that resulted in RFC3679?
RFC3679 already says:

   IANA is requested to reassign these option codes after the list of
   option codes that have never been assigned or have previously been
   returned has been exhausted.

Maybe this is not well understood.

--
Michael Richardson <mcr+IETF@sandelman.ca>ca>, Sandelman Software Works
 -= IPv6 IoT consulting =-