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

Bernie--

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

--Barr

> -----Original Message-----
> From: dhcwg-admin@ietf.org [mailto:dhcwg-admin@ietf.org]On Behalf Of
> Bernie Volz
> Sent: Thursday, October 30, 2003 13:45
> To: 'Ted Lemon'; dhcwg@ietf.org
> Subject: 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
>

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