Subject: [dhcwg] vendor-01 comments

From: Ralph Droms <[email-masked]>
Date: Tue, 24 Feb 2004 10:32:11 -0500

This specification looks OK to me.

I do have one small suggestion: for clarification, add a sentence that
explicitly describes how multiple enterprise numbers are encoded in a single
instance of each option.

The text does imply that multiple instances of the vendor-specific data can
appear in an instance of each option; adding the sentence I suggest would
make that implication explicit and ensure there is no question about the
format of such options.

- Ralph

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

---

From: "Bernie Volz" <[email-masked]>
Date: Tue, 24 Feb 2004 16:07:25 -0500

I also wonder whether for completeness the following issues should be
addressed:

- Are these options allowed in DHCPINFORMs (I see no reason why not). Might
it be good to state the messages these option may appear in: DHCPDISCOVER,
DHCPOFFER, DHCPREQUEST, DHCPACK, DHCPINFORM?

- In order for a server to send back vendor-specific information option,
MUST the client send a vendor-specific information option (with the
enterprise number and perhaps data-len of 0 if it has no options)? Or, is a
server allowed to send vendor-specific information option if, for example,
just a vendor-class option is sent or the server somehow determines the
vendor (or just sends the option anyway).

- I think I know what you are recommending, but might it be best to clarify
what is meant by: "so implementations SHOULD attempt to format instances of
these new vendor options such that they can be interpreted without
concatenation, if support for RFC 3396 is in doubt." 

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ralph
Droms
Sent: Tuesday, February 24, 2004 10:32 AM
To: [email-masked]
Cc: [email-masked]
Subject: [dhcwg] vendor-01 comments

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Tue, 24 Feb 2004 19:02:26 -0500

> concatenation, if support for RFC 3396 is in doubt."

You should just specify that support for RFC3396 is required.   There's 
no reason why a server that supports this option shouldn't also support 
RFC3396.   RFC3396 says how to handle concatenation, and it's easy to 
specify it badly (who knows, maybe RFC3396 specifies it badly), so it's 
better not to respecify it in this draft.