Subject: Comments on draft-ietf-dhc-userclass-05.txt

From: Thomas Narten <[email-masked]>
Date: Tue, 06 Jun 2000 15:56:05 -0400

Ralph has asked that this document be advanced as a PS. In reviewing
this document, I have the following comments. I think it would be best
to get the document revised once more before issuing the IETF last
call. Can this be done quickly?

> The code for this option is TBD.

The document lists the user class option as TBD. Isn't this option 77
as already assigned by IANA? From
http://www.isi.edu/in-notes/iana/assignments/bootp-dhcp-parameters: 

> 77      User-Class        N          User Class Information

I would suggest making this clear in the document, and then adding an
IANA Considerations section that simply states that option 77, which
IANA has already assigned for this purpose, should be used.

> Each User Class value is indicated in an opaque field and is
> preceded by a one-byte field giving its length.
> Let n be the number of User Classes carried in the
> option. The length of the option as specified in Len must be
> the sum of the lengths of each of the class names plus n:
> Len= Len1 + Len2 + ...+ Lenn + n.
> 
>    Code   Len   Len1            Len2
>   +-----+-----+-----+----------+-----+--------------+----
>   | TBD |  N  |  L1 |  class 1 | L2  |    class 2   |...
>   +-----+-----+-----+----------+-----+--------------+----

I think it would be good to more clearly define the length values. I
got confused at first because I had assumed that the length byte also
included the length field itself (it does in some protocols). This is
apparently not the case here.  I.e., add the phrase "the value in the
User Class length field not include the length field itself" after the
first sentence in the paragraph above.

> 5. Security Considerations

I think you should also add a paragraph specifically pointing out that
because of existing DHCP vulnerabilities, some of the specific example
uses for the user class option given this document need to be
considered carefully. I.e, if the user class option will be used to
give out special IP addresses that have better QOS associated with it,
but there is no way to authtenticate a client, there is a
vulnerability here. 

> 7. Acknowledgments

> This document combines ideas from draft-ietf-dhc-userclass-03.txt
> (by Glenn Stump and Ralph Droms) and
> draft-ietf-dhc-useraddr-00.txt (by Ye Gu, Ramesh Vyaghrapuri and
> Burcak Beser). It has been published as a revision to
> draft-ietf-dhc-userclass-05.txt.

A nit, but the document (when published as an RFC) can't have
references to drafts.  Best not to mention the drafts by name and just
say something like "based on earlier drafts by ..."

I think it would be good to reissue this document before having the
IETF Last Call. The IANA-related material in particular is reviewed by
IANA during the last call, so it would be good to get it in
order. Jerome, can you get this ID reissued quickly?

Thomas

---

From: "Barr Hibbs" <[email-masked]>
Date: Tue, 6 Jun 2000 16:59:17 -0700

Jerome--

Based on Thomas' comments, I reassert my suggestion for improving the
wording about the length octets [see earlier comments to WG Last Call].

--Barr

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Thomas Narten
> Sent: Tuesday, June 06, 2000 12:56 PM