RE: [dhcwg] draft-ietf-dhc-packetcable-04.txt

"Woundy, Richard" <> Fri, 20 December 2002 23:44 UTC

Received: from ( [] (may be forged)) by (8.9.1a/8.9.1a) with ESMTP id SAA15523 for <>; Fri, 20 Dec 2002 18:44:05 -0500 (EST)
Received: (from mailnull@localhost) by (8.11.6/8.11.6) id gBKNl5n18040 for; Fri, 20 Dec 2002 18:47:05 -0500
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id gBKNl4v18037 for <>; Fri, 20 Dec 2002 18:47:05 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id SAA15518 for <>; Fri, 20 Dec 2002 18:43:34 -0500 (EST)
Received: from (localhost.localdomain []) by (8.11.6/8.11.6) with ESMTP id gBKNidv17979; Fri, 20 Dec 2002 18:44:39 -0500
Received: from ( []) by (8.11.6/8.11.6) with ESMTP id gBKNhVv17958 for <>; Fri, 20 Dec 2002 18:43:31 -0500
Received: from ( []) by (8.9.1a/8.9.1a) with ESMTP id SAA15367 for <>; Fri, 20 Dec 2002 18:40:01 -0500 (EST)
Received: from ( []) by (8.12.2/8.12.2) with ESMTP id gBKNgqvY028789; Fri, 20 Dec 2002 16:42:52 -0700 (MST)
Received: from by with ESMTP ( Tumbleweed MMS SMTP Relay (MMS v5.0)); Fri, 20 Dec 2002 16:42:44 -0700
X-Server-Uuid: 4520D425-5A30-451F-8662-E5DDF307F3B1
Received: by with Internet Mail Service ( 5.5.2653.19) id <ZDJ1Q2L5>; Fri, 20 Dec 2002 16:42:00 -0700
Message-ID: <>
From: "Woundy, Richard" <>
To: 'Thomas Narten' <>, Paul Duffy <>
Subject: RE: [dhcwg] draft-ietf-dhc-packetcable-04.txt
Date: Fri, 20 Dec 2002 16:42:39 -0700
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
X-WSS-ID: 121D757E121767-01-01
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <>, <>
List-Id: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit


>[Have] you had a chance to look at
>draft-narten-iana-experimental-allocations-02.txt?  Does this address
>any of your concerns? (Or do I still not really understand the
>concerns behind this?)

It seems that your draft's use of experimental numbers is pretty
restrictive. For example, it would allow Paul Duffy to conduct an experiment
in his all-Cisco lab, but it doesn't seem that CableLabs could conduct a
cross-vendor experiment even in their own lab (forget about any field
trials). Quite frankly, I think Paul could just as easily steal a DHCP
option code in the 128-254 space for such experimentation.

I draw this conclusion from the following paragraphs in your draft,
especially the second paragraph:

   An alternate approach, and the one recommended in this document, is
   to assign a range of numbers specifically earmarked for testing and
   experimentation purposes. Mutually consenting devices could use these
   numbers for whatever purposes they desire, but under the
   understanding that they are reserved for generic testing purposes,
   and other implementations may use the same numbers for different
   experimental uses...

   From the above, it follows that it would be inappropriate for a group
   of vendors, a consortia, or another Standards Development
   Organization to agree amongst themselves to use a particular value
   for a specific purpose. By definition, experimental numbers are not
   guaranteed to be unique in any environment other than one where the
   the local system administrator has chosen to use a particular number
   for a particular purpose and can ensure that a particular value is
   not already in use for some other purpose.

This comment from the draft could be especially tricky for a headless
PacketCable brick: "anyone making use of an experimental number should
require the user or customer to explicitly configure the value prior to
enabling its usage".

-- Rich

P.S. Side comment about the draft: is there a reason why there are two
different reference numbering schemes (RFC number versus descriptive name)
for the two references?

   [RFC2780] IANA Allocation Guidelines For Values In the Internet
           Protocol and Related Headers. S. Bradner, V. Paxson. March
           2000, RFC 2780.

   [IANA-CONSIDERATIONS] Guidelines for Writing an IANA Considerations
           Section in RFCs. T. Narten, H. Alvestrand. October 1998. RFC

dhcwg mailing list