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

From: "Bernie Volz" <[email-masked]>
Date: Thu, 30 Oct 2003 16:45:29 -0500

Are you afraid we might break some implementations if a zero length option
is sent to them? Does the ISC DHCP Server process zero-length options
correctly or does it consider these to be malformed (even if it otherwise
would ignore that 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.

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

Note that the document that started all this (the mipadvert-opt one) is
really about suboptions and not options, so RFC 2132 and the compatibility
issue likely do not apply (since any implementation supporting the mipadvert
option could be explicitly designed to support zero length suboptions). But,
working this out for options is important since I'd like to use a zero
length option for the Rapid Reply option.

- Bernie

-----Original Message-----
From: Bernie Volz [mailto:[email-masked]] 
Sent: Thursday, October 30, 2003 4:32 PM
To: 'Ted Lemon'; [email-masked]'
Subject: RE: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt
(SECOND REQUEST)

But, what's the point of sending a Rapid Reply option with a flag byte of
False? It really is no different than sending no option.

For Boolean options, there is a difference in saying don't do this vs.
saying nothing at all and hence the flag is important (lack of the option
does not necessarily mean don't do it).

I guess this is just one of those areas were we disagree.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted
Lemon
Sent: Thursday, October 30, 2003 3:37 PM
To: [email-masked]
Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt
(SECOND REQUEST)

On Thursday, October 30, 2003, at 08:08  AM, Bernie Volz wrote:
> Personally, I think this is a mistake. You should leave the ability in.
> We're using it in the Rapid Reply option for DHCPv4 (based on the Rapid
> Commit option for DHCPv6) and that has a zero length. There is no 
> reason why
> this would need a flag byte.

The thing is, every boolean option in rfc2131 includes a flag byte, 
even though it's unnecessary (and I agree that it is, technically, not 
necessary).

So I think that you should use a flag byte in the Rapid Reply option.   
And Henrik should use a flag byte in the mipadvert option.   Because 
otherwise, the protocol defines two ways of representing the same kind 
of information in virtually identical contexts, which means that 
implementations have to be needlessly complicated.

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

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Oct 2003 16:08:47 -0600

On Oct 30, 2003, at 3:45 PM, Bernie Volz wrote:
> 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.

>    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.

> 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.   :'/

> 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.

---

From: "Barr Hibbs" <[email-masked]>
Date: Thu, 30 Oct 2003 20:40:00 -0800

Bernie--

I'll make a note of this point for inclusion in the next revision of the
2131 implementation issues draft.

--Barr

> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Bernie Volz
> Sent: Thursday, October 30, 2003 13:45
> To: 'Ted Lemon'; [email-masked]