IANA Considerations in IDs (was Re: Last Call: DHCP Domain Search Option to Proposed Standard )

Thomas Narten <narten@raleigh.ibm.com> Fri, 28 September 2001 13:50 UTC

Received: by ietf.org (8.9.1a/8.9.1a) id JAA15279 for ietf-outbound.10@ietf.org; Fri, 28 Sep 2001 09:50:02 -0400 (EDT)
Received: by ietf.org (8.9.1a/8.9.1a) id JAA14887 for ietf-mainout; Fri, 28 Sep 2001 09:41:05 -0400 (EDT)
X-Authentication-Warning: ietf.org: majordom set sender to owner-ietf@ietf.org using -f
Received: from hygro.adsl.duke.edu (cichlid.adsl.duke.edu [152.16.64.203]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14883 for <ietf@ietf.org>; Fri, 28 Sep 2001 09:41:02 -0400 (EDT)
Received: from hygro.adsl.duke.edu (narten@localhost) by hygro.adsl.duke.edu (8.11.6/8.9.3) with ESMTP id f8SDb1801378; Fri, 28 Sep 2001 09:37:01 -0400
Message-Id: <200109281337.f8SDb1801378@hygro.adsl.duke.edu>
To: mborden@acm.org, ietf@ietf.org
Subject: IANA Considerations in IDs (was Re: Last Call: DHCP Domain Search Option to Proposed Standard )
In-Reply-To: Message from "Fri, 28 Sep 2001 06:54:28 EDT." <200109281054.f8SAsSU06300@hygro.adsl.duke.edu>
Date: Fri, 28 Sep 2001 09:37:01 -0400
From: Thomas Narten <narten@raleigh.ibm.com>
Sender: owner-ietf@ietf.org
Precedence: bulk
X-Loop: ietf@ietf.org

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

> > How can this be issued with as a Proposed Standard RFC with a
> > 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.

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