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

From: [email-masked]
Date: Tue, 28 Oct 2003 14:01:00 -0800

TL> On Wednesday, October 22, 2003, at 09:17 AM, Kim Kinnear wrote:
    >> I don't see the value in having zero length suboptions.  I don't
    >> think we generally allow them (though someone will doubtless
    >> correct me if I'm wrong).  If there is some valid, semantically
    >> interesting reason for allowing zero length suboptions, then I
    >> think the meaning should be spelled out, otherwise I think they
    >> should be disallowed.

    TL> I agree with this.  There is a precedent, but it's a big hassle
    TL> to support this - it's better for the suboption to just have a
    TL> boolean value.

I have been following this and was feeling uncomfortable about zero
length options. Yes, we have to support it for the nwip sub-options but
I really do not like how it continues to break what was a nice 
paradigm on dhcp options: code, length, data.

I know dhcp packets are small and there are times when we want to be as
space efficient as possible. However I am not sure this tradeoff is
worth the cost of saving two bytes.  I agree with Ted. I think it is 
better for this suboption to just have a boolean value.

-- Scanner       ([email-masked])
   Nominum, Inc. | www.nominum.com | +1.650.779.6035

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 29 Oct 2003 22:48:08 -0600

> paradigm on dhcp options: code, length, data.

Actually, the four nwip suboptions that are zero-length are very odd - 
they're options that require the server to do special handling in order 
to generate them correctly.   I am curious if anybody here has actually 
implemented these options as specified, and if they are aware of any 
clients that take advantage of these options if sent.   I am tempted to 
write a draft that deprecates these options, since I am skeptical that 
there is anybody who uses them.   Comments?

---

From: Henrik Levkowetz <[email-masked]>
Date: Thu, 30 Oct 2003 07:40:46 +0100

> better for this suboption to just have a boolean value.

Ok, I've taken this to heart and will do the draft update accordingly.

Thanks,

	Henrik

---

From: "Bernie Volz" <[email-masked]>
Date: Thu, 30 Oct 2003 09:08:55 -0500

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.

And, a zero length option does NOT invalidate the standard paradigm of DHCP
options - code, length, data. The null set is always a member of every set.
A zero length data field is fine.

I previously wrote that having a flag byte in some instances is important
and those options should be defined with a flag byte. For example, a flag
byte is important when the following three possibilities are important:
1. Option present with flag set to true - turn on the feature.
2. Option present with flag set to false - turn off the feature.
3. Option not present - use locally configured default.
Whereas an option with no data (no flag) only has two settings:
1. Option present - do it.
2. Option not present - do not do it.

So, for the Rapid Reply draft, it would make little sense in having a flag
byte since implementations that want to do it only need to include the
option without data. Those that do not want to make use of Rapid Reply
should simply not include the option.

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Henrik
Levkowetz
Sent: Thursday, October 30, 2003 1:41 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [dhcwg] WG last call on draft-ietf-dhc-mipadvert-opt-01.txt
(SECOND REQUEST)

Thanks,

	Henrik

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Oct 2003 14:36:38 -0600

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

---

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

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)

---

From: Ted Lemon <[email-masked]>
Date: Thu, 30 Oct 2003 15:51:34 -0600

> False? It really is no different than sending no option.

That's true.   I don't expect you to send the Rapid Reply option if the 
value is false.   And I agree that in the other cases, a flag byte 
value of zero might be meaningful, and in this case it is not.   But 
using a flag byte in all cases is consistent, and in a case like this I 
think consistency is worth a small sacrifice in space, because it makes 
implementations easier.