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

From: Thomas Narten <[email-masked]>
Date: Thu, 27 Sep 2001 12:08:05 -0400

Ralph Droms <[email-masked]> 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:

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

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

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

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.

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

Thomas

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

---

From: Rich Woundy <[email-masked]>
Date: Thu, 27 Sep 2001 18:50:19 -0400

Thomas, thanks for your comments, which really helped.

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

-- Rich

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

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

>what their values are. I.e., is "n" variable length or always the

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.

>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

>option always be less than 255 bytes? :-)

Yes -- thankfully.

-- Rich

---

From: Thomas Narten <[email-masked]>
Date: Fri, 28 Sep 2001 11:47:14 -0400

Hi Rich.

All your proposed changes look good to me. Thanks.

Thomas