Subject: Update to RFC 2489 (REMINDER!)

From: Ralph Droms <[email-masked]>
Date: Thu, 08 Jun 2000 15:50:57 -0400

REMINDER - Respond by this Friday, 6/9, if you have any
comments about draft-ietf-dhc-new-opt-msg-00.txt

===============================================================

I've published "Procedure for Defining New DHCP
Options and Message Types" <draft-ietf-dhc-new-opt-msg-00.txt>,
which is intended to replace RFC 2489.  The new I-D
gives a procedure for issuing new DHCP message types as well as
new option codes.  We need to have this procedure in place
to assign a new message type code for the RECONFIGURE option
as described in <draft-ietf-dhc-pv4-reconfigure-00.txt>.

The draft mentions the new options review procedure,
which is currently documented in
draft-ietf-dhc-option-review-and-namespace-02.txt,
and requires that new options and message types be reviewed
through any new procedure accepted by the DHC WG.

This new document is a simple update to the current
procedure for accepting new options.  If the document
is not controversial, I will fast-track it through the
WG and go to last call some time next week.  If the WG
would like to engage in a longer discussion, the
document will go through the normal WG review procedure.

Please review the document and reply to the mailing
list with comments...

- Ralph

---

From: Thomas Narten <[email-masked]>
Date: Thu, 08 Jun 2000 16:21:51 -0400

> comments about draft-ietf-dhc-new-opt-msg-00.txt

Comments of the form "I've read it, and it's fine" are appreciated too
to avoid confusion with "nobody has read it, so who knows if it's
baked".

Thomas

---

From: "Barr Hibbs" <[email-masked]>
Date: Fri, 9 Jun 2000 14:33:39 -0700

typos and nits:
===============

1.	"publicly" is misspelled as "publically" in the second paragraph of
section 2.1

2.	"...will be document..." in the second sentence of the first paragraph of
section 2.2 probably should read "...will be documented...."

3.	"...new option or message typemay reference..." in the third sentence of
the second paragraph of section 5 needs a space:  "...new option or message
type may reference...."

changes:
========

Is it appropriate to institute a "sunset" rule for option codes?  I propose
all [new] options have an associated lifetime, somewhere between two and
five years, when they are first accepted:  before the end of that lifetime
the DHC WG chair would issue a "call for renewal" on the option.  If the DHC
WG vote shows little or no interest in keeping the option, it would be
deprecated in the next version of the DHCP RFC, and eventually dropped
entirely, so the option code could be reused.  This process could take
multiple years, protecting any existing implementations which use the
option, but would provide a well-defined way to recover unused or
under-utilized option codes.

Otherwise, I concur with the text of the I-D (and the proposed change
regarding public and private option codes.)

--Barr

---

From: Ralph Droms <[email-masked]>
Date: Fri, 09 Jun 2000 17:47:36 -0400

At 02:33 PM 6/9/00 -0700, Barr Hibbs wrote:

>changes:
>========
>
>Is it appropriate to institute a "sunset" rule for option codes?

Interesting idea - what are you trying to accomplish?

I don't think it's likely that we can reuse the option codes (well,
maybe the 'Impress server option') once they've leaked out into
installed clients.  There will likely *always* be some client out
there that continues to use an option past its sunset date.

- Ralph

---

From: Ralph Droms <[email-masked]>
Date: Fri, 09 Jun 2000 17:45:10 -0400

>typos and nits:

Good catches and thanks...

- Ralph

---

From: "Barr Hibbs" <[email-masked]>
Date: Fri, 9 Jun 2000 15:03:44 -0700

> there that continues to use an option past its sunset date.
...at one time, we were concerned enough about the possible exhaustion of
DHCPv4 option codes that we convened the futures panel, one of whose
recommendations was a means for declaring 16-bit option codes.  Since then,
there doesn't seem to be as much urgency for preserving the remaining free
option codes, but I suspect it will become a concern sooner or later.
Rather than wait until we are faced with imminent exhaustion, I'm suggesting
how we might plan for the eventual deprecation of unused or under-used
option codes.  For example, are there *really* any clients and servers that
make use of Default IRC Server or Default WWW Server?

--Barr

---

From: Richard Jones <[email-masked]>
Date: Fri, 09 Jun 2000 16:10:28 -0700

I think the idea has some attraction, but I don't believe it can be
done without breaking something somewhere. How could the working
group get a realistic idea of who is using what? That's a question
I've wondered for some time. There's a certain amount of information
that could be gleaned from vendors, lists etc., but in general it
seems like a standards group can put them out, but can't take them
back without a wholesale replacement - for the very reason that
it's impossible to know what gets broken otherwise.

My vote is that we leave the sunset definition out at this point.

A couple more typos:

Section 2.2, third paragraph - change accepatance to acceptance.
Section 3, point 4 - change "typeis" to "type is".

Thanks, Ralph!

Regards,
Richard

---

From: "Eric A. Hall" <[email-masked]>
Date: Fri, 9 Jun 2000 16:29:35 -0700

> For example, are there *really* any clients and servers that

By default no, but by configuration yes. Folks use non-stock options with
scriptable clients all the time, and more folks are doing it as more clients
become scriptable.

---

From: "Barr Hibbs" <[email-masked]>
Date: Mon, 12 Jun 2000 08:36:08 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On
> Behalf Of Eric A. Hall
> Sent: Friday, June 09, 2000 4:30 PM
>
> scriptable clients all the time, and more folks are doing it as
> more clients become scriptable.
>
>

...I think you missed my point:  "are any clients and servers using the DHCP
options for configuring default IRC or WWW servers?"

For example, the popular mIRC client uses a local configuration file to
determine which server(s) it will attempt to connect to, and neither
Internet Explorer nor Netscape seem to request a WWW server [using
DHCPINFORM].

--Barr

---

From: "Eric A. Hall" <[email-masked]>
Date: Mon, 12 Jun 2000 09:28:19 -0700

> For example, the popular mIRC client uses a local configuration file
> to determine which server(s) it will attempt to connect to, and
> neither Internet Explorer nor Netscape seem to request a WWW server
> [using DHCPINFORM].

I understood, it's the same question and answer.

Nobody is doing it "by default" as you describe it. However, there are
people who are doing this by script-pushing lease data into external
configuration files and the like. More people are doing it as more DHCP
clients offer interfaces that can be scripted.

OS/2 Warp led the way on this with a REXX interface to their client; it
was fully scriptable. All of the UNIX systems that I have here provide
some sort of interface that lets the client be configured with this kind
of data (default NTP servers is a common example, default mail server is
also easy to do). With NT & Win2k it is possible but not easy: you can
extend the client and read the resulting option data from the registry,
stuffing it into other registry entries or into external configuration
files, but it isn't pretty. Windows 9x and the MacOS don't provide any
end-user access to this data to my knowledge, so this can't be done with
end-user tools on those platforms (although NTS' ShadowIP client solves
the problem for Win9x), but the rest of them essentially allow a user or
administrator to read lease data which can then be stuffed into some
other configuration point.

The biggest problem nowadays is not that clients cannot be extended but
that it is a royal PITA to configure each of the applications. Some apps
store data into user-specific configuration files that are kept in
remote profiles that aren't available to the client, or which use LDAP,
SLP and/or ACAP for the same thing. If you have Eudora and Navigator and
are only using local configuration files for a single user, it's not
hard to extend those apps on an NT system, but if you are using IE/OE or
Communicator with user-specific configuration data stored on a remote
server it is very hard to do. I use Communicator with the LDAP-based
roaming profile here, there's no way I can do this easily.

It's a sad joke: people are now able to actually get to the option data
so they can use it, but they are now having a harder time of actually
being able to use it as application data gets dispersed.

-- 
Eric A. Hall                                      http://www.ehsco.com/
Internet Core Protocols        http://www.oreilly.com/catalog/coreprot/