RE: [dhcwg] I-D ACTION:draft-ietf-dhc-unused-optioncodes-00.txt

["Bernie Volz (EUD)" <[e-mail]>]

>Well, I thought that was a good idea, too, when I proposed it
>some years ago.  At the time, the WG rejected the plan as
>a bad idea...

As we didn't have the concat draft, perhaps that was why the WG thought
it was a bad idea? Or was there some other reason(s)?

Is this perhaps a work item that the WG should take on (in many ways I
think there may never be a need so perhaps this is nothing to worry
about) ... or is there some other action we can request of IANA to prevent
assignment of the last [few] option[s] just in case?

Should this be an agenda item for the SF IETF DHC WG? (Note that I'm not
yet certain I'll be there, so if you want you can add the topic under my name
but someone else may have to handle it.)

- Bernie

-----Original Message-----
From: Ralph Droms [mailto:[e-mail]]
Sent: Thursday, February 20, 2003 1:49 PM
To: [e-mail]
Subject: RE: [dhcwg] I-D ACTION:draft-ietf-dhc-unused-optioncodes-00.txt


Bernie - thanks for the feedback.  Comments in line...

- Ralph

At 12:37 PM 2/20/2003 -0600, Bernie Volz (EUD) wrote:

>Ralph:
>
>This draft looks great.
>
>One minor issue. In Abstract you write:
>
>    Prior to the publication of RFC2939 (which was updated by RFC2489),
>
>Shouldn't it have been:
>    Prior to the publication of RFC2489 (which was updated by RFC2939),

Of course - good catch.

>
>
>Also, shouldn't the abstract or the Introduction clearly state why this
>I-D is being published ... such as:
>
>    This I-D documents those options that the DHC WG believes are not
>    in use at present and will ask IANA to return to the available option
>    pool for eventual reassignment per RFC2939 (or its predecessors).
>    Comments are solicited if DHCP client or server implementations exist
>    that use and require these options.

What I had in mind is:

* make an IETF-wide announcement about the draft (following
   up on the automatic publication announcement), specifically
   asking for input such as you suggest
* accept input and updating the draft as appropriate
* turn the draft into an Informational RFC directing IANA
   to mark the unused options as "available"

I suppose it wouldn't hurt to also add the text you suggest
at the front of the current I-D.


>Also, does it make sense to consider asking IANA to reserve say option
>127 for possible use as an extension option should there ever be a need
>rather than releasing it for general reassignment? I'm not clear why two
>option numbers were originally selected, so perhaps two should be
>reserved?
>
>My reasoning is that even with the RFC 2939 procedures, it does require
>someone (the DHC WG?) to monitor the options usage and make sure that
>a timely I-D (and RFC) are produced to assure the last option is never
>assigned (or at least properly assigned to permit extensions). As we
>have no idea how long the DHC WG will be around, it may be prudent to
>reserve an option now?

Well, I thought that was a good idea, too, when I proposed it
some years ago.  At the time, the WG rejected the plan as
a bad idea...

>
>
>- Bernie
>
>-----Original Message-----
>From: [e-mail] 
>[<mailto:[e-mail]>mailto:[e-mail]]
>Sent: Thursday, February 20, 2003 7:36 AM
>Cc: [e-mail]
>Subject: [dhcwg] I-D ACTION:draft-ietf-dhc-unused-optioncodes-00.txt
>
>A New Internet-Draft is available from the on-line Internet-Drafts 
>directories.
>This draft is a work item of the Dynamic Host Configuration Working Group 
>of the IETF.
>
>         Title           : Unused DHCP Option Codes
>         Author(s)       : R. Droms
>         Filename        : draft-ietf-dhc-unused-optioncodes-00.txt
>         Pages           : 8
>         Date            : 2003-2-19
>
>Prior to the publication of RFC2939 (which was updated by RFC2489),
>several option codes were assigned to proposed DHCP options that were
>subsequently never used.  This document lists those unused option
>codes and will be used to confirm that these option codes can be
>reused for other DHCP options in the future.
>
>A URL for this Internet-Draft is:
><http://www.ietf.org/internet-drafts/draft-ietf-dhc-unused-optioncodes-00.txt>http://www.ietf.org/internet-drafts/draft-ietf-dhc-unused-optioncodes-00.txt 
>
>
>To remove yourself from the IETF Announcement list, send a message to
>ietf-announce-request with the word unsubscribe in the body of the message.
>
>Internet-Drafts are also available by anonymous FTP. Login with the username
>"anonymous" and a password of your e-mail address. After logging in,
>type "cd internet-drafts" and then
>         "get draft-ietf-dhc-unused-optioncodes-00.txt".
>
>A list of Internet-Drafts directories can be found in
><http://www.ietf.org/shadow.html>http://www.ietf.org/shadow.html
>or 
><ftp://ftp.ietf.org/ietf/1shadow-sites.txt>ftp://ftp.ietf.org/ietf/1shadow-sites.txt 
>
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>         [e-mail].
>In the body type:
>         "FILE /internet-drafts/draft-ietf-dhc-unused-optioncodes-00.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>         MIME-encoded form by using the "mpack" utility.  To use this
>         feature, insert the command "ENCODING mime" before the "FILE"
>         command.  To decode the response(s), you will need "munpack" or
>         a MIME-compliant mail reader.  Different MIME-compliant mail readers
>         exhibit different behavior, especially when dealing with
>         "multipart" MIME messages (i.e. documents which have been split
>         up into multiple messages), so check your local documentation on
>         how to manipulate these messages.
>
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.

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