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

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:volz@metrocast.net] 
Sent: Thursday, October 30, 2003 4:32 PM
To: 'Ted Lemon'; 'dhcwg@ietf.org'
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: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org] On Behalf Of Ted
Lemon
Sent: Thursday, October 30, 2003 3:37 PM
To: dhcwg@ietf.org
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
dhcwg@ietf.org
https://www1.ietf.org/mailman/listinfo/dhcwg

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