[dhcwg] Re: draft-ietf-dhc-agentoptions-device-class-02.txt

[Rich Woundy <[e-mail]>]

Thomas,

If the changes to draft-ietf-dhc-agentoptions-device-class-03.txt (as 
incorporated in the attachment, version -04) are acceptable, I will submit 
a new draft for IESG approval ASAP.

First, I changed the title to "The DOCSIS Device Class DHCP Relay Agent 
Information Sub-option", in the spirit of your second recommendation below 
(to narrow the language). I added some slight emphasis in the rest of the 
text as well, e.g. the title of section 2 has changed from "Device Class 
Sub-option" to "DOCSIS Device Class Sub-option", and the term "device class 
sub-option" has been augmented several times to "DOCSIS Device Class 
sub-option".

I believe this is the correct approach given (a) the DOCSIS cable 
orientation of the current draft, (b) the apparent lack of interest in 
expanding the sub-option to other access technologies (note that this 
sub-option required some new DOCSIS signaling to be effective), and (c) the 
likely abundance of sub-option values for the relay agent information 
option, e.g. only two other sub-option drafts have been submitted, which 
brings the number of publicly discussed sub-option values to 6 out of a 
possible 255 values.

Second, I made reference to the security considerations of RFC 3046 as 
suggested: "The discussion of security considerations for the DHCP relay 
agent information option [1] apply to this sub-option as well.".

Third, I made a few independent draft fixes: correcting "signalling" to 
"signaling", updating my contact information, and changing dates/version of 
the draft.

-- Rich

At 06:47 AM 11/2/2001 -0500, Thomas Narten wrote:
>The IESG discussed this document yesterday, and has two comments on
>it.
>
>First, the title of this document "Addition of Device Class to Agent
>Options" suggests that it is a general option, i.e., one that could
>support multiple device classes. In practice, it is a "DOCSIS device
>type" option. It might be better to do one of the following:
>
>1) turn it into a more general option, by, for example, adding a
>    "Device Class" type to the option value, so that other types of
>    device classes could later be defined. Right now, this isn't
>    possible. To define a new device class, one would need to assign a
>    new Relay Agent Option and define the new option. Doing this would
>    also potentially conserve Relay Agent Option numbers (a one-byte
>    field). Do we expect there to me more in the future?
>
>2) narrow the language to make it clear that is an option that only
>    applies to DOCSIS. I think changing the title to something like
>    "The DOCSIS Device Class DHCP Relay Agent Option" would do the
>    trick.
>
>The second issue concerns the security considerations section:
>
> > The security considerations section doesn't specify how the implied
> > trust relationship can be done in practice. Thus it doesn't provide
> > sufficient info for an implementor.
> >
> > This can be handled by addition a reference to the relay options spec
> > e.g. at the end of the first paragraph in section 3.
>
>These are the only two issues that were raised. Once they are
>resolved, I expect approval of the document.
>
>Thomas