Subject: Re: Last call for <draft-ietf-dhc-concat-01.txt>

From: Stuart Cheshire <[email-masked]>
Date: Fri, 24 Aug 2001 18:16:15 -0700

Some minor suggestions:

1. Encoding agent behaviour

I think it would be very helpful to make it explicit that *no* semantic 
information is encoded by whether (or where) an option is split.

After the "Options MAY be split on any octet boundary" paragraph, add:

     No semantic information is encoded by whether (or where) an
     option is split. In particular, this means that adding two
     small options with the same option code to a packet is no
     different to adding a single option containing the data
     from the two separate options concatenated together. For
     example, suppose a DHCP packet contains two instances of
     DHCP option 61 (Client-Identifier). RFC 2132 does not
     specify whether the receiver should disregard the second
     one in the packet, or let the second Client-Identifier
     supersede the first, or interpret this as meaning that the
     client has two Client-Identifiers. If DHCP option 61 had
     been defined to use the concatenation behaviour specified
     by this document (which it was not) then the meaning would
     be clear and unambiguous: The client has one and only one
     Client-Identifier, and its value is the data from the two
     Client-Identifier options concatenated together.

I mention this because I think that this will be an easy implementation 
mistake to make with the domsearch option. Consider the three domsearch 
options below:

+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| TBD |  8  |  3  | 'i' | 's' | 'c' |  3  | 'o' | 'r' | 'g' |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+

+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| TBD | 10  |  5  | 'a' | 'p' | 'p' | 'l' | 'e' |  3  | 'c' | 'o' | 'm' |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+

+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| TBD |  9  |  3  | 'm' | 'i' | 't' |  3  | 'e' | 'd' | 'u' |  0  |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+

An incorrect client could easily treat this as an indication to add three 
domains, "isc.org", "apple.com", and "mit.edu" to the search list.

This would be incorrect. The domsearch options above encode a
single domain to be added to the search list, and that domain is 
"isc.org.apple.com.mit.edu."

This may be pretty counterintuitive to most people, which is why I think 
it needs to be explained clearly.

2. Example

I think the example would better if it showed a real option being split, 
rather than a hypothetical example where the intended semantics are less 
obvious. Perhaps the domsearch example above would work.

3. References

I don't think reference 4 is what you meant.

Stuart Cheshire <[email-masked]>
 * Wizard Without Portfolio, Apple Computer
 * Chairman, IETF ZEROCONF
 * www.stuartcheshire.org