Subject: RE: [dhcwg] Agenda for dhc WG meeting in San Diego

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sat, 4 Nov 2006 10:48:09 -0500

Personally, I think it should be INFORMATIONAL. This is documenting
existing behavior, is it not? It is not developing a new standard (i.e.,
the DHC WG can't change how these options are used -- we can only help
to improve the documentation of their existing usage). 

At least, that's my interpretation of Informational in
http://www.ietf.org/rfc/rfc2026.txt:

4.2.2  Informational

   An "Informational" specification is published for the general
   information of the Internet community, and does not represent an
   Internet community consensus or recommendation.  The Informational
   designation is intended to provide for the timely publication of a
   very broad range of responsible informational documents from many
   sources, subject only to editorial considerations and to verification
   that there has been adequate coordination with the standards process
   (see section 4.2.3).

   Specifications that have been prepared outside of the Internet
   community and are not incorporated into the Internet Standards
   Process by any of the provisions of section 10 may be published as
   Informational RFCs, with the permission of the owner and the
   concurrence of the RFC Editor.

RFC 3942 is silent on the type of RFC needed to keep an existing use of
an option in the old site-specific range. So, there is no impact there.

I guess the DHC WG could ask "if these options had been defined through
the normal DHC WG process for new options, would we have done anything
sufficiently different"? If the consensus answer was NO, there would be
no harm in a standards track document. But my answer to that question
would actually be YES, as I'd see no need for option 208 "MAGIC" if
these options had been developed through the normal process.

For *FUTURE* new options that the PXELINUX folks want to use, if they do
go through the DHC WG process to develop the options, those would then
be standards track documents.

- Bernie

-----Original Message-----
From: Ralph Droms (rdroms) 
Sent: Friday, November 03, 2006 7:08 PM
To: David W. Hankins; [email-masked]
Subject: Re: [dhcwg] Agenda for dhc WG meeting in San Diego

OK...

- Ralph

On 11/3/06 5:12 PM, "David W. Hankins" <[email-masked]> wrote:

> On Mon, Oct 30, 2006 at 01:32:02PM -0500, Ralph Droms wrote:
>> draft-ietf-dhc-pxelinux-00, "PXELINUX Use of 'Site Local' Option
Space"
>> (Informational)
> 
> I'm not sure if this should be Informational or Proposed Standard.
> The draft does contain normative language.
> 
> Perhaps that's one of the things we should talk about at the end of
> my (very short) presentation.

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

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

---

From: "David W. Hankins" <[email-masked]>
Date: Sun, 5 Nov 2006 18:59:30 +0000

> to improve the documentation of their existing usage). 

I guess I was thinking that an informational document suggests there
is no consensus for use.  That is, if another bootloader wanted the
same features, WG conensus 'might' be to do it another way, and that
they 'should' propose a new standard.  Whereas a proposed standard
indicates community acceptance of the method, encouraging use.

In review, that's not at all correct, as it would be the initial
responses to such a request that would build consensus as to wether
or not to reuse or rebuild, and the presence of the informational
document alone is enough to encourage reuse.

> these options had been developed through the normal process.

...If we were 'keeping' option 208.  Its presence is entirely due
to operating outside of the IETF.

At any rate the documentatin of option 208 is clearly informational
only, if we were to judge the entire document upon that one element.

So I agree that this document should be informational.

> be standards track documents.

I think the developer (H. Peter Anvin) has already indicated a strong
desire to move into the VIVSO space for any future options.  It's
far easier, in this case, to simply publish dhcp server configuration
samples.

-- 
David W. Hankins	"If you don't do it right the first time,
Software Engineer		you'll just have to do it again."
Internet Systems Consortium, Inc.	-- Jack T. Hankins

---

From: "H. Peter Anvin" <[email-masked]>
Date: Sun, 05 Nov 2006 12:02:53 -0800

> only, if we were to judge the entire document upon that one element.

What I was *hoping* would happen would be that options 209, 210, and 211 
would become standardized, and 208 would become deprecated.

208 is obviously a hack.

It sounds to me that what really should happen is that this should be 
split in two documents, an informational describing PXELINUX-specific 
behaviour, and a standards-track document, describing options 209, 210, 
and 211.

> far easier, in this case, to simply publish dhcp server configuration

It depends on the options, obviously.  In general, I try to avoid DHCP 
options, and only use them for information that is required before the 
configuration file can be fetched.

	-hpa