Re: [dhcwg] DHCPv6 message type

[Bud Millwood <budm at weird-solutions.com>]

On Tuesday 29 April 2008, you wrote:
> Bud accidentally dropped the dhcwg ... Adding it back (after checking
> with him) ...
>
> >Well, what's your definition of painful? I guess this is where it could
>
> get
>
> >unpalatable for anyone not interested in this message type. It just
>
> feels
>
> >kinda bad to grab a bag full of option codes and reserve them for
> >vendor-specific messages.
>
> The point is that in a vendor specific message, you would have to use
> some kind of special encoding to encode IANA-assigned options.

Like a VSO with enterprise number 0? Unless there's some reason I'm not aware 
of to use EID 0 for IANA, this seems really easy.

> >And what's considered enough reserved option codes?
>
> Yes, that is a concern. But, if you'll use a lot of options, you'd have
> to use an alternative techique (such as encoding them in other options
> as sub-options or perhaps even as vendor-options).

Same as above.

> And, there's one other benefit - packet decoders could still decode some
> of the packet for you even for these vendor messages as a portion of the
> option space was known! Of course, it would also be possible to have
> vendor specific definitions based on the enterprise-id in the message
> but then for those cases where the existing are used too, it gets kind
> of messy to redefine all of the IANA options?

I think the benefit is dubious. We already have VSO, and packet decoders have 
to deal with that.

As for the second part of your paragraph, my first response applies. A VSO 
with EID 0.

> I asked at the DHC WG meeting when I presented the draft if it would
> help if I removed the reserved options section, but people still didn't
> like the draft even if it had just the vendor-specific message. I don't
> think we *need* the reserved options, it just made life a bit easier.

OK. I don't think we need the reserved options at all, because it doesn't make 
anything easier for us - in fact it seems to needlessly complicate the 
matter.

As for just having the vendor-specific message at all... well, it would help 
us to standardize a behavior that we already "sort of" use.

And as for Shane's comment, my understanding was that he was concerned that 
vendors would end up implementing functionality that could be of benefit to 
the DHCP standard itself. My response to that is that vendors will always 
implement anything they find beneficial regardless of where the standard 
stops. If not in a vendor-specific message, then through some other means. If 
the WG decides to standardize something that's been implemented in a 
vendor-specific message, that's great for everyone.

Bud Millwood
Weird Solutions, Inc.
http://www.weird-solutions.com
tel: +46 8 758 3700
fax: +46 8 758 3687
_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg