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

From: "Yoshinori K. Okuji" <[email-masked]>
Date: Sat, 12 Mar 2005 14:25:09 +0100

Hello,

I would like to notify that GNU GRUB uses the DHCP option 150, according to 
RFC 3942.

GNU GRUB Configuration Path

This specifies the path-name that contains a configuration for GNU GRUB.

The code for this option is 150.  Its minimum length is 1.

    Code   Len    Configuration Pathname
   +-----+-----+-----+-----+-----+-----+--
   | 150 |  n  |  n1 |  n2 |  n3 |  n4 |  ...
   +-----+-----+-----+-----+-----+-----+--

Best regards,
Okuji

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

---

From: Ted Lemon <[email-masked]>
Date: Sat, 12 Mar 2005 11:38:08 -0600

> I would like to notify that GNU GRUB uses the DHCP option 150, 

Thanks for the notification.   Would you guys be interested in fixing 
this so that GRUB uses a vendor-encapsulated option, or do you think 
this usage is sufficiently entrenched that it is worth writing up an 
informational draft describing what GRUB is doing?   I can write up a 
description of how to use the ISC DHCP server to send a 
vendor-encapsulated option to GRUB if that would be helpful.   
Implementation on the GRUB side should be pretty easy.

---

From: "Bernie Volz" <[email-masked]>
Date: Sat, 12 Mar 2005 13:07:35 -0500

Looks like we now have 3 "users" of Option 150:

1. GNU GRUB
2. DRAFT-RAJ-DHC-TFTP-ADDR-OPTION-00.TXT
3. Etherboot

- Bernie

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Yoshinori K. Okuji
> Sent: Saturday, March 12, 2005 8:25 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [dhcwg] RFC 3942 notice: GNU GRUB, DHCP option 150
> 
> Hello,
>

---

From: "Yoshinori K. Okuji" <[email-masked]>
Date: Tue, 15 Mar 2005 04:05:01 +0100

> Implementation on the GRUB side should be pretty easy.

I agree that it would be easy to switch to a vendor encapsulated option, but I 
hesitate to do that, because GRUB has been using that option for 5 years, and 
compatibility is the most important thing for me.

However, I understand why the reclassification is necessary and I respect such 
an effort. So, if it is inevitable not to keep using that option, I will 
change GRUB.

Regards,
Okuji

---

From: Timothy Legge <[email-masked]>
Date: Wed, 16 Mar 2005 07:49:06 -0400

> 2. DRAFT-RAJ-DHC-TFTP-ADDR-OPTION-00.TXT

Noted.  It looks like we all get to apply for a new option code when the 
process becomes available.

Timothy Legge
Etherboot Developer

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Mar 2005 10:47:47 -0700

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.