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
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg