Re: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt (SECOND REQUEST)

On Oct 30, 2003, at 3:45 PM, Bernie Volz wrote:
> Are you afraid we might break some implementations if a zero length 
> option
> is sent to them?

No, it just adds needless complexity to the option data parser.   Any 
DHCP implementation should already know how to skip over unknown 
options, so I don't expect a zero-length option to break it, although 
it's by no means out of the question.   AFAIK the ISC server would not 
have a problem with a client-supplied zero-length option.

> RFC 2132 specially allows zero-length options (see section 2):
>
>    Any options defined subsequent to this document MUST contain a 
> length
>    octet even if the length is fixed or zero.

Sure.   But that's not the point.   The point is that having two ways 
to represent a boolean isn't as good as having one way.

> If you really think the prohibition is needed, shouldn't it be 
> included in
> the draft-ietf-dhc-implementation-xx.txt work?

Yes, we should probably have some language in this draft that talks 
about defining new option data types.   I thought we'd done something 
similar to this in the past, but don't find it in the rfc index.   The 
idea is that we have already defined various data formats, and that 
options that use these formats should be consistent - there shouldn't 
be two data formats that represent the same kind of data.   Right now 
this is not agreed upon nor is it enforced other than by pedants like 
me complaining when people come out with new options that define new 
data types that do the same thing as old data types.   In the case of 
the nwip suboptions, I think that was during the 6-month period when I 
accidentally got unsubscribed from the mailing list, so I didn't have 
the opportunity to object.   :'/

> Note that the document that started all this (the mipadvert-opt one) is
> really about suboptions and not options

Although it is not required, I would expect any DHCP server 
implementation of suboptions and options to share the option parsing 
code, so it makes sense to me that if something is valid for a 
suboption, it's valid for an option, and vice versa.

_______________________________________________
dhcwg mailing list
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg