IETF Logo Mail Archive

Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option

Ralph Droms <rdroms@cisco.com> Tue, 28 June 2005 13:25 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnG6B-00083W-Ge; Tue, 28 Jun 2005 09:25:59 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnG67-000823-FD; Tue, 28 Jun 2005 09:25:57 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07333; Tue, 28 Jun 2005 09:25:53 -0400 (EDT)
Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnGVS-0002UO-Qz; Tue, 28 Jun 2005 09:52:08 -0400
Received: from sj-core-4.cisco.com (171.68.223.138) by sj-iport-5.cisco.com with ESMTP; 28 Jun 2005 06:25:45 -0700
X-IronPort-AV: i="3.93,239,1115017200"; d="scan'208"; a="194854146:sNHT29459412"
Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.12.10/8.12.6) with ESMTP id j5SDP7c7024365; Tue, 28 Jun 2005 06:25:42 -0700 (PDT)
Received: from xmb-rtp-211.amer.cisco.com ([64.102.31.118]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 28 Jun 2005 09:25:29 -0400
Received: from 10.86.240.68 ([10.86.240.68]) by xmb-rtp-211.amer.cisco.com ([64.102.31.118]) via Exchange Front-End Server email.cisco.com ([64.102.31.21]) with Microsoft Exchange Server HTTP-DAV ; Tue, 28 Jun 2005 13:25:29 +0000
Received: from localhost.localdomain by email.cisco.com; 28 Jun 2005 09:26:06 -0400
From: Ralph Droms <rdroms@cisco.com>
To: John C Klensin <john-ietf@jck.com>
In-Reply-To: <8EBD1D6B77E409DC019454C9@scan.jck.com>
References: <8EBD1D6B77E409DC019454C9@scan.jck.com>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Date: Tue, 28 Jun 2005 09:26:06 -0400
Message-Id: <1119965166.5654.91.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.0.4 (2.0.4-2)
X-OriginalArrivalTime: 28 Jun 2005 13:25:29.0653 (UTC) FILETIME=[DA61CE50:01C57BE4]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
Content-Transfer-Encoding: 7bit
Cc: Thomas Narten <narten@us.ibm.com>, jkrey@isi.edu, IETF list <ietf@ietf.org>, Allison Mankin <mankin@psg.com>, Sam Hartman <hartmans-ietf@mit.edu>, IESG <iesg@ietf.org>
Subject: Re: IANA Action: Assignment of an IPV6 Hop-by-hop Option
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

John - as a concrete example of the problem you describe, the dhc WG
perceived that there was a looming problem with exhaustion of the DHCP
option code space.  So, we wrote up a procedure (RFC 2939) requiring
documentation of new options in an RFC, implying technical review by the
dhc WG.  Now, we find a significant number of option codes in the
private code space (128-254), which have been unofficially appropriated
for use in shipping products. 

To clean up the mess, the dhc WG has enlarged the available option code
space and is working through a process of identifying and registering
the unofficially appropriated option codes (RFC 3942).  I'll ask the dhc
WG to review RFC 2939 in light of the expanded option code space and our
experience with unofficial appropriation.

- Ralph

On Mon, 2005-06-27 at 06:32 -0400, John C Klensin wrote:
> [...]
> But, for the first, I'm getting more and more anxious about
> rejecting a registration request.  That is largely because, if
> the applicant still feels that the idea is a good one, we've got
> lots of unfortunate experience that he or she will just ignore
> the registration requirement, squat on a code, and proceed as if
> the allocation had been made. Worse, that applicant may not come
> back and ask the next time, depriving the community of a
> heads-up and the applicant of potentially-valuable IETF review.
> [...]


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf

v2.23.0 | Report a Bug | By Email