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

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 20 Dec 2002 16:42:39 -0700

Thomas,

>[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
           2434.

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Fri, 20 Dec 2002 18:47:19 -0600

I was under the impression that allocation for DHCP relay agent 
suboptions was not predicated on getting a draft through last call.   
The rules you're quoting are for mainline DHCP options, which are in 
short supply.   No such problem exists for relay agent suboptions.

I can't claim to speak for the WG, but if there is no conflict in the 
options that were allocated in the CableLabs draft, I don't see any 
reason why we'd want to change the numbers.

---

From: Thomas Narten <[email-masked]>
Date: Sat, 21 Dec 2002 10:48:13 -0500

> trials).

That is not the intent. The document is all about permitting
experiments. It is not, however, about encouraging general deployment,
under the guise of "experiment".

> Quite frankly, I think Paul could just as easily steal a DHCP option
> code in the 128-254 space for such experimentation.

And would that not be an acceptable solution? I *really* would like to
understand what the underlying requirement is here. I still feel like
perhaps I don't.

>    not already in use for some other purpose.

I can see now the wording above could be better, if your conclusion is
that cablelabs can't even test.

Experimental use is for testing and experimentation.  But, it is not
for general deployment. In the latter, one runs the risk of having a
chosen number conflict with other usages, so one really needs a
dedicated number. So, part of what defines an experiment is what
environment it goes into, and whether the scope of the experiment can
ensure that use of a number won't conflict with a legitimate use of
that number for other authorized purposes (e.g, an official
assignment)

> require the user or customer to explicitly configure the value prior to

Experimental use numbers are not at all intended for mass deployments
or home users to configure their cable modems. If you are shipping
modems to home users, you are really not experimenting anymore; you
are deploying.

> different reference numbering schemes (RFC number versus descriptive name)

None other than the author is not being  consistent and this hadn't
been pointed out until now... :-(

Thomas