Subject: RE: [dhcwg] Assigning DHCPv6 option codes

From: "Bernie Volz (EUD)" <[email-masked]>
Date: Wed, 23 Jan 2002 09:47:41 -0600

I am happy with calling this option space "experimental".

With DHCPv6, getting an option number is much less of an issue. However, it takes work to write an I-D and get it to RFC. Some vendors may not chose to do through this process.

If we allow vendors to request option numbers from IANA without formally publishing an I-D or RFC, that should be OK (from an available number space issue). However, it does likely mean we'll have an explosion of options and might often have lots of very similar options. That I think would be bad.

Having a space for vendors and others to experiment with new options (or use site options if they so chose) is a good idea. This can be a smaller range.

- Bernie

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]]
Sent: Wednesday, January 23, 2002 7:38 AM
To: Ralph Droms
Cc: Bernie Volz (EUD); [email-masked]
Subject: Re: [dhcwg] Assigning DHCPv6 option codes

I am unaware of a single example where site-specific options have ever been 
used.   This is why I think it's better not to put language about reserved 
portions of the option space in the base draft - I think we need to figure 
out what we want to do carefully.   Is it really site-specific that we want?
    What about vendor-specific?   What about user-defined?   If you want to 
reserve any space in the draft, I would just call the reserved space 
"experimental" rather than being specific about who can use it.   Reserving 
4096 codes is probably plenty, though, as you say - I don't think we need 
32k.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 23 Jan 2002 18:10:07 +0100

We shouldn't allow people to request option codes from the IANA if they 
haven't published a draft, but I think it's safe to relax the restrictions 
to the extent that if a draft exists, an option code can be assigned 
without the draft going to last call.   This utterly draconian 
requirementis only justified by the extremely small number of option codes 
available in DHCPv4.

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

---

From: Ralph Droms <[email-masked]>
Date: Wed, 23 Jan 2002 12:42:38 -0500

There's a little more to it than just the scarcity of option codes in 
DHCPv4.  Just before we instituted the new policy of assigning an option 
code after acceptance to PS, there were several (10-15 or so) that were 
proposed, had option codes assigned, and then were never followed up 
on.  Those option codes are now in limbo.

Even though we have plenty of options code in DHCPv6, I don't think it's a 
good idea to have option codes in an uncertain state - assigned to options 
that never went to PS.  Perhaps we need some sort of sunsetting to 
establish a process for marking option codes as "unused - do not reassign"...

- Ralph

---

From: Ted Lemon <[email-masked]>
Date: Wed, 23 Jan 2002 19:00:26 +0100

> proposed, had option codes assigned, and then were never followed up on.  
> Those option codes are now in limbo.
>
> Even though we have plenty of options code in DHCPv6, I don't think it's 
> a good idea to have option codes in an uncertain state - assigned to 
> options that never went to PS.  Perhaps we need some sort of sunsetting to 

Sounds fine.   However, I don't think it's a particularly serious problem.
    Perhaps we should issue leases on options - if you don't have a current 
draft or RFC, your option code gets reclaimed.   I'd say that the draft 
should have wg sponsorship before a code gets issued, but OTOH it might be 
nice if, someday, the DHCwg were obsolete... :')

---

From: Richard Barr Hibbs <[email-masked]>
Date: Wed, 23 Jan 2002 14:50:49 -0800

> From: Ralph Droms
> Sent: Wednesday, January 23, 2002 09:43
>
> Even though we have plenty of options code in DHCPv6, I don't
> think it's a good idea to have option codes in an uncertain state -
> assigned to options that never went to PS.  Perhaps we need some sort
> of sunsetting to establish a process for marking option codes as
> "unused - do not reassign"...
>

...you may recall that I proposed exactly that -- the sunsetting of option
codes -- at least twice in working group meetings, but Thomas Narten argued
convincingly that the IETF has never been very good at enforcing adherence
to updated RFCs, and may never be able to do anything but move an RFC to
Historic status, which doesn't provide any practical, timely relief for the
option exhaustion problem.

I'd love for most options to be subject either to a sunset clause, but I
don't know how effective it would be -- certainly one side effect would be
to keep the DHC working group in existence for a long, long time.

--Barr

---

From: Ralph Droms <[email-masked]>
Date: Fri, 25 Jan 2002 11:32:35 -0500

Barr - my memory is that you proposed sunsetting of option codes *after* 
they've gone to PS and have been published in an RFC.  My suggestion was to 
sunset the option codes - and to capture the sunsetting process in an RFC - 
after adoption as a WG work item and before publication as an RFC.

- Ralph