Message-Id: <6.2.1.2.2.20050609183510.046e8030@mail.jefsey.com>
Date: Thu, 09 Jun 2005 18:54:01 +0200
To: Brian E Carpenter <brc@zurich.ibm.com>
From: "JFC (Jefsey) Morfin" <jefsey@jefsey.com>
In-Reply-To: <42A8463D.7000708@zurich.ibm.com>
References: <42ut2e$2gut56@mx21.mrf.mail.rcn.net>
	<200506081359.20078.blilly@erols.com>
	<6.2.1.2.2.20050609092203.046a1130@mail.jefsey.com>
	<42A8463D.7000708@zurich.ibm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Cc: ietf@ietf.org
Subject: Re: IANA Considerations
Precedence: list
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

At 15:38 09/06/2005, Brian E Carpenter wrote:
>Please see RFC 2434 = BCP 26

Dear Brian,
I was probably not clear enough. Bruce quoted RFCs, and others points 
postdate RFC 2434. Current http://www.iana.org site is not the best 
documentation site I saw. It said two things:

1. a IANA related obligations registry. Where obligations to IANA, authors, 
users, etc. would be registered and easily displayed.
2. in the IANA considerations to explicit the way IANA overload will be 
fought. This last point (with XML registries) is a point under 
consideration and of concern for those having to fund the IANA as ccTLDs. 
It might lead to make alternatives being considered earlier than advisable 
for good transition. For example a daily interruption of IANA registries 
for an hour or random drops calling for a recall of the requested page, a 
timer, a copyrigh response first, etc. could be ways to prevent 
applications designers to call on IANA XML files everytime they need one of 
their data.

jfc

>    Brian
>
>
>JFC (Jefsey) Morfin wrote:
>>Dear Bruce,
>>you know what? I think it would be great to write a IANA obligations RFC. 
>>It would say that the IANA MUST maintain a list of all the obligations 
>>RFC authors should respect when writting the IANA considerations, and to 
>>document whatever additional information IANA may need (for example if a 
>>DoS might result from a possible misuse of what they ask and the proposed 
>>solutions).
>>jfc
>>At 19:59 08/06/2005, Bruce Lilly wrote:
>>
>>> > Re: Last Call: 'Email Submission Between Independent Networks' to BCP
>>> >  Date: 2005-06-08 10:50
>>> >  From: Ned Freed <ned.freed@mrochek.com>
>>>
>>> > > .. RFC2119, when used, must be a normative reference.  Likewise,
>>> > > you'll need to add a "null" IANA considerations section.
>>> >
>>> > Agreed on the RFC 2119 reference. However, I do not believe there is any
>>> > requirement for "null" IANA considerations sections. (A scan of recently
>>> > published standards track RFCs turned up several that don't have such 
>>> a section
>>> > - 4022, 4015, etc.) Aren't we paddding out our documents with enough 
>>> useless
>>> > boilerplate already without adding yet another useless section to the 
>>> mix?
>>>
>>>The IETF Internet-Drafts page notes that "All Internet-Drafts that are
>>>submitted to the IESG for consideration as RFCs must conform to the
>>>requirements specified in the I-D Checklist".  The current version of
>>>the ID-Checklist clearly states:
>>>
>>>The following are REQUIRED sections in all Internet-Drafts:
>>>[...]
>>>IANA Considerations
>>>A
>>>Must specify if IANA has to create a new registry or modify rules for
>>>an existing registry.
>>>B
>>>Must specify if the document requires IANA to assign or update values
>>>in an IANA registry before RFC publication.
>>>C
>>>See "Guidelines for Writing an IANA Considerations Section in RFCs"
>>>[RFC2434] and in some cases also "IANA Allocation Guidelines For Values
>>>In the Internet Protocol and Related Headers" [RFC2780]. In some case
>>>"Assigning Experimental and Testing Numbers Considered Useful" [RFC3692]
>>>may help as well.
>>>D
>>>If there is no action for IANA, the section should say that, e.g.,
>>>including something like "This document has no actions for IANA."
>>>
>>>And the RFC-Editor's "instructions to RFC Authors" (draft successor to
>>>RFC 2223, on hold) notes:
>>>       Current policy (not documented in [IANA98]) is to include an IANA
>>>       Considerations section always, even if it is "null", i.e., even if
>>>       there are no IANA considerations.  This is helpful to IANA.
>>>       However, the RFC Editor may remove any null IANA considerations
>>>       sections before publication.
>>>
>>>I believe the requirements exist to ensure that draft authors give due
>>>consideration to IANA Considerations and that IANA can readily determine
>>>if some action is or is not required.  Evidently (and unfortunately) the
>>>IETF Secretariat apparently doesn't enforce that part of the ID-Checklist
>>>rules.
>>>
>>>As the RFC Editor removes null sections, you won't find them in published
>>>RFCs.  But Internet-Drafts are REQUIRED to have them.
>>>
>>>_______________________________________________
>>>Ietf mailing list
>>>Ietf@ietf.org
>>>https://www1.ietf.org/mailman/listinfo/ietf
>>
>>_______________________________________________
>>Ietf mailing list
>>Ietf@ietf.org
>>https://www1.ietf.org/mailman/listinfo/ietf
>


_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf