[dhcwg] draft-narten-iana-experimental-allocations-03.txt (was Re: [dhcwg ] draft-ietf-dhc-packetcable-04.txt)

["Woundy, Richard" <[e-mail]>]

Thomas,

These comments are really about your draft
<http://www.ietf.org/internet-drafts/draft-narten-iana-experimental-allocati
ons-03.txt>.

I thought you were advocating the allocation of a few CCC sub-options for
experimentation, not the use of the standard DHCP experimental option space
-- which explains this exchange of comments between us:

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

So the advice from your draft is to use DHCP experimental options 128-254,
and not set aside space for experimental CCC suboptions, right?

Now let me consider this exchange:

>> 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".
>
>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.

I don't think you're seeing my real point about headless devices and DHCP
option experimentation. Let's disregard cable for this discussion. How does
one "explicitly configure the value" on a device without a user interface
(i.e. a brick)? Perhaps some devices will obtain an IPv4 link-local address
for its testing-accessible interface, and then the device can be configured
using an internal web server or SNMP agent -- but that's the ideal (I
think). It is perhaps more likely that the only way that the device will
know about any DHCP experimental options is if the device has downloaded
firmware that understands the option(s). Shouldn't the draft consider this
possibility?

There's something else that I don't understand: why do you use the term
"customers" in your draft? Apparently according to your comments, this term
does not apply to broadband Internet customers (cable or otherwise). Then
what kinds of customers are "safe"? Why would any "customer" be willing to
stop such an experiment, if the experiment helped them resolve some problem
or added a feature?

-- Rich

-----Original Message-----
From: Thomas Narten [mailto:[e-mail]]
Sent: Saturday, December 21, 2002 10:48 AM
To: Woundy, Richard
Cc: Paul Duffy; [e-mail]
Subject: Re: [dhcwg] draft-ietf-dhc-packetcable-04.txt


> 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).

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.

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

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)

> 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".

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.

> 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?

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

Thomas

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