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

[Rich Woundy <[e-mail]>]

Thomas, thanks for your comments, which really helped.

My proposed resolutions are below. Any objections? If not, I will submit 
-03 by Monday.

-- Rich

At 12:08 PM 9/27/2001 -0400, Thomas Narten wrote:
>Ralph Droms <[e-mail]> writes:
>
> > Addition of Device Class to Agent Options
> >    <draft-ietf-dhc-agentoptions-device-class-01.txt>
> >    No comments during WG last call
> >    Ready for submission for IETF last call
> >    (draft expired and will be resubmitted)
>
>I managed to find a copy of -01; here are my comments on this one:

I submitted -02 yesterday -- just to refresh the expired draft.

Your comments will be reflected in version -03.

>needs IANA considerations section (see previous note on subnet ID)

I am adding the following section:

4.  IANA Considerations

    IANA has assigned a value of TBD from the DHCP Relay Agent Sub-
    options space [RFC 3046] for the device class sub-option defined in
    section 2.

>uses MAY language without definition. Maybe just downcase the words
>and use the english meaning instead?

I am removing one MAY statement from section 1 (in the spirit of other 
recent comments about obviousness):
"This sub-option MAY be added by DHCP relay agents which terminate cable 
modems"
to "This sub-option is added by DHCP relay agents which terminate cable 
modems".

I am keeping one MAY from section 2 (since even DHCP servers that support 
this suboption may use other policy indicators):
"DHCP servers MAY use the device class for IP and other parameter 
assignment policies for cable modems".

I am adding one MUST to section 2 (since this is the whole point of the draft):
"The relay agent passes the Device Class value unchanged to the DHCP server"
to "The relay agent MUST pass the Device Class value unchanged to the DHCP 
server".

I am adding the following paragraph to the Introduction:
    The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT" and "MAY" in
    this document are to be interpreted as described in RFC 2119 [4].

I am adding the reference to RFC 2119:
    [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, RFC 2119, March 1997.

> >             SubOpt   Len     Device Class
> >            +------+------+------+------+------+------+------+------+--
> >            | TBD  |   n  |  d1  |  d2  |  d3  |  d4  |  d5  |  d6  | ...
> >            +------+------+------+------+------+------+------+------+--
>
>It would be good in the text under this picture to list the fields and
>what their values are. I.e., is "n" variable length or always the
>same?

The DOCSIS specs say that their Device Class is a 32 bit value.

Therefore I am changing 'n' to '4', and deleting the 'd5' and 'd6' bytes.

Also see the comment below.

>Also, is the specific meaning/definition/interpretation of the Device
>Class field defined in:
>
> >    [3] "Data-Over-Cable Service Interface Specifications: Cable Modem
> >       Radio Frequency Interface Specification SP-RFIv1.1-I06-001215",
> >       DOCSIS, December 2000, http://www.cablemodem.com.
>
>(I assume so from the previous text). It would be good to state this
>explicitly, since the text does say that the server must be able to
>parse this field in order to figure out what parameters to return.

I am adding the following paragraph to section 2:

    DOCSIS defines the Device Class to be a 32-bit field where individual
    bits represent individual attributes of the CM. Bit #0 is the least
    significant bit of the field. Bits are set to 1 to select the attri-
    butes defined below.

       bit #0 - CPE Controlled Cable Modem (CCCM)

       bits #1-31 - Reserved and set to zero

>And since we've been talking about this issue elsewhere, will this
>option always be less than 255 bytes? :-)

Yes -- thankfully.

-- Rich

>Thomas



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