Subject: draft-ietf-dhc-option-review-and-namespace-00.txt

From: Kim Kinnear <[email-masked]>
Date: Thu, 1 Jul 1999 11:39:54 -0400 (EDT)

Mike,

I was reading over draft-ietf-dhc-option-review-and-namespace-00.txt. 

Nice job!   

I had several questions and comments:

1. What about a new message type?  What category would the INFORM message go 
into if we didn't already have one?  Does a new message type fit into this 
category scheme at all?  I wouldn't bring it up if it wasn't defined by
a new value defined for an existing option, but since it is...

2. I remember that the DHCP ?R5? options were supposed to overmap the new 16 
bit options.  Was that in there and I missed it, or was it only implicit?
If it is supposed to be there it might make sense to highlight it, 
and if it isn't -- what *are* we doing about the issue?

3. In section 2.1, you have a table of implicit/explict option relationships.

The first entry in this table is "Client class".  I think you mean option 
60, which used to be called Client Class in some older draft, but in 2132 is 
called (more correctly and less confusingly, I think) Vendor Class Identifier 
(page 29).

4. Section 3.3 says "two implementations", but I thought that was for 
Category 2 or 3 options only, that category 1 options didn't need 2 or more 
implementations. If what I think is true, then fix section 3.3, if what I 
think is false, then fix section 2.2 which agrees with what I remember.

5. Section 3.7, #2.  IPv6 Addresses.  I'm a bit confused here.  We don't 
just do the 16 octets, but rather turn these into text?

6. Section 3.7, #3.  Would you include Relay-agent-info in this class of 
encapsulated options? (We've taken to calling these type of options 
"compound" options, and the #4 style "structured" options around here, but 
those words might or might not be good ones to use.)

7. Section 3.7.  Do you imagine that we will allow options where they are 
mixed #4 and #3 options, with some constant fields at the front, and then 
some sub-options inside at the end?  Do we want to specifically allow or 
disallow such options in this draft?

Personally, I think an option should either but style #4 (which I call 
structured), possibly with a variable length last field, or style #3 (which 
I call compound) which contains only sub-options in any order, but not some 
hybrid of both, but that's just my opinion.  I *do* think we should explicitly
allow or disallow these hybrids in the draft.

Again, nice job.  Thanks for doing this.

Cheers -- Kim