Re: [dhcwg] RFC 3942 notice: GNU GRUB, DHCP option 150

[Ted Lemon]

On Mar 16, 2005, at 4:49 AM, Timothy Legge wrote:
> Noted.  It looks like we all get to apply for a new option code when 
> the process becomes available.

A couple of points.   First, it's fine for all three users of code 150 
to submit informational drafts describing what they are doing.   
Second, since there are three conflicting uses, I would suggest that 
the people responsible for them switch to the standard vendor-specific 
encapsulated options mechanism, or if the option they are using is 
something that ought to be more widely implemented, I would suggest 
writing a standards-track draft describing what you want to do.

In the case of GRUB, specifically, what I would suggest is that new 
versions of GRUB should send a vendor-class-identifier option, and 
should be prepared to receive a vendor-specific encapsulated option.   
However, it should also request option 150.   This allows for backwards 
compatibility, but allows for a migration away from option 150.   
Since, if I understand it correctly, GRUB is a second-stage boot 
loader, it should be the case that over time versions of GRUB that 
*require* option 150 will go out of use, meaning that server 
administrators will be in a position to safely discontinue use of 
option 150.

However, please note that there is no requirement on you to follow my 
suggestion here.   It's just a suggestion.   It's perfectly permissible 
for you to just write up an i-d documenting what you're doing now and 
leave it at that - the only reason I suggest the other option is that 
as use of GRUB possibly becomes more widespread, the conflict between 
the three uses of option 150 will become more of a problem.   Using 
vendor-specific options resolves the conflict, so in the long run I 
think it's better for the end user.