Subject: Re: Last Call: DHCP Domain Search Option to Proposed Standard

From: "Marty Borden" <[email-masked]>
Date: Thu, 27 Sep 2001 16:27:32 -0400

How can this be issued with as a Proposed Standard RFC with a
field labeled TBD?  Or, am I wrong in understanding the process
and it is really that IANA will issue the field if it is decided to
proceed with Proposed Standard?
marty

On 9/27/2001 at 2:16 PM The IESG <[email-masked]> wrote:

>
>The IESG has received a request to consider DHCP Domain Search Option
><draft-aboba-dhc-domsearch-06.txt> as a Proposed Standard.  This has
>been reviewed in the IETF but is not the product of an IETF Working
>Group.
>
>The IESG plans to make a decision in the next few weeks, and solicits
>final comments on this action.  Please send any comments to the
>[email-masked] or [email-masked] mailing lists by October 26, 2001.
>
>Files can be obtained via
>http://www.ietf.org/internet-drafts/draft-aboba-dhc-domsearch-06.txt

---

From: Thomas Narten <[email-masked]>
Date: Fri, 28 Sep 2001 06:54:28 -0400

> field labeled TBD?

If the ID is approved to be published as a PS, the RFC editor will
work with IANA during the final stages of publication to ensure that
the TBD value is replaced with an appropriate value.

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Fri, 28 Sep 2001 09:37:01 -0400

To clarify a bit futher and explain the bigger picture...

> the TBD value is replaced with an appropriate value.

In the case of draft-aboba-dhc-domsearch-06.txt, it contains an IANA
considerations section that calls attention to the need for IANA to
assign an option code. During Last Calls, IANA scans documents,
looking for an IANA Considerations section. As long as it contains the
information and context for IANA to figure out what it needs to do,
any TBDs in the document will get cleaned up as part of the RFC
editing process.  A part of the process that isn't immediately visible
to all is that when IANA reviews a document, it sends a note to the
IESG (cc'ing authors and WG chairs as appropriate) indicating whether
they have any questions, concerns, etc. In cases where there are open
issues, the IESG typically delays approval until those issues are
resolved.

One thing that has been happening over the last couple of years is
that the IESG has been asking for a clear IANA Considerations section
earlier in the process, i.e., before the IETF Last Call works takes
place. From a process perspective, everything works most smoothly if
the document that is Last Called has a good IANA Considerations
section, so that IANA easily understands what it needs to do. It is
also worth noting that while on the surface it may seem like the IANA
stuff is a process nit, in fact it is not. Only the authors/WG can
properly determine what should be in the IANA considerations section,
and the choices made can have significant implications (e.g., some
numbers will only be assigned for subsequent Standards Track
usages). This again argues for having the IANA Considerations section
be complete during IETF Last Call, so the community as as whole can
also review it.

For more background, see RFC 2434. There is also a recent ID on IANA
issues that I'd certainly be happy to get feedback on
(draft-narten-iana-experimental-allocations-00.txt).

Thomas

---

From: Dave Crocker <[email-masked]>
Date: Fri, 28 Sep 2001 07:32:57 -0700

>be complete during IETF Last Call, so the community as as whole can

(excellent summary, Thomas.  many thanks it.  in fact, it probably should 
be included in one of our process documents, perhaps working group guidelines.)

In general, IETF work has greatly benefited from moving review by 
decision-makers earlier.  It is extremely costly and frustrating to have a 
working group haggle and resolve its issues, only to find that a 
decision-maker in the critical path has major (ie, showstopping) concerns 
that were not known early in the process.

Hence, the trend toward earlier IANA review of the Considerations section 
is a Very Good Thing.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464