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

[Thomas Narten <[e-mail]>]

Hi Rich.

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

Yes. If Cablelabs wants to test with some sub options, it would seem
to me that a few sub-option values could be  assigned for this.

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

Either way would seem to work. Since cablelabs want specifically to
test the suboptions, it seems like allocating some for this make
sense. But I don't have strong feelings about this.

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

OK, I think I see your issue now. The intent of the document is to
discourage real deployments, but to allow for experimentation and
testing (including what I understand cablelabs testing to
involve). The current wording would seem to be too restrictive.

Would the following wording address your concern (for the last
paragraph?)
 
    In many, if not most cases, reserving a single value for
    experimental use will suffice. While it may be tempting to reserve
    more in order to make it easy to test many things at once,
    reserving many may also increase the temptation for someone using
    a particular value to assume that a specific experimental value
    can be used for a given purpose exclusively. Values reserved for
    experimental use are never to be made permanent; permanent
    assignments should be obtained through standard processes. As
    described above, experimental numbers are intended for
    experimentation and testing and are not intended for wide or
    general deployments. When protocols that use experimental numbers
    are included in products, the end user of the product should be
    required to explicitly configure the value prior to enabling its
    usage.

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

Customer may not be the best choice of words.  Would "end user" be
better? The intention is to capture the notion that the owner/user of
the device must be able to control the experimentation, as opposed to
the manufacturer of the device/product.

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