OK, we can take these comments as inout for the revision of 2434.
Brian
JFC (Jefsey) Morfin wrote:
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@xxxxxxxxxxx>
> > .. 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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf