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
- Re: Last Call: DHCP Domain Search Option to Propo… Marty Borden
- Re: Last Call: DHCP Domain Search Option to Propo… Thomas Narten
- IANA Considerations in IDs (was Re: Last Call: DH… Thomas Narten