At 06:47 02-10-2014, The IESG wrote:
The IESG has received a request from an individual submitter to consider
the following document:
- 'Guidelines for Writing an IANA Considerations Section in RFCs'
<draft-leiba-cotton-iana-5226bis-08.txt> as Best Current Practice
The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@xxxxxxxx mailing lists by 2014-10-30. Exceptionally, comments may be
As an overall comment, some text in the draft is repetitive. The
text was also in RFC 5226. The language in the draft was
accessible. I would have suggested to make the draft less lengthy
but that would entail more work for the authors.
From Section 1:
"For IETF protocols, that role is filled by the Internet
Assigned Numbers Authority (IANA) [RFC2860]."
Given that there seems to be a service mark for "Internet Assigned
Numbers Authority", shouldn't there be an IPR disclosure?
"IANA services are currently provided by the International Corporation
for Assigned Names and Numbers (ICANN)."
According to www.icann.org there is an "Internet Corporation For
Assigned Names and Numbers".
I suggest using (see RFC 6220 for rationale):
"The IETF Protocol Parameter Registry Operator role is currently
undertaken by
Internet Corporation For Assigned Names and Numbers."
I suggest considering whether to rename "IANA Considerations" to
"IETF Protocol Parameters Considerations" (Section 1.1).
Section 1.2 has a URL for www.iana.org. I suggest dropping that
section (re. discussion about iana.org in the IANAPLAN working group).
In Section 1.3:
'For this document, "the specification" as used by RFC 2119 refers to
the processing of protocol documents within the IETF standards
process.'
There was a thread about registration policies (see
http://www.ietf.org/mail-archive/web/ietf/current/msg88598.html
). My reading of the quoted text is that the key words do not apply
to documents in the IRTF and Independent Streams.
Section 2.1 might require some coordination with IANAPLAN. Two of
the examples in Section 2.1 (ADSP) refers to a RFC which has been
classified as "Historic". I suggest not using Historic RFCs as
examples. There isn't a "IETF Consensus" policy anymore.
In Section 2.2:
"For examples of documents that establish registries, consult"
I suggest using "please read" instead of "consult".
In Section 2.3:
"In particular, when a registry policy that requires involvement of
Working Groups, directorates, or other bodies to be actively involved
and to support the effort, requests frequently run into concerns that
"it's not worth doing a Standards-Track RFC for something this
trivial," when, in fact, that requirement was created by the Working
Group in the first place, by placing the bar that high."
Are directorates involved in registry policy?
I suggest changing "Standards-Track RFC" to RFC as even an RFC is a
high bar and it is a non-trivial requirement.
"Therefore, Working Groups and other document developers should use
care in selecting appropriate registration policies when their
documents create registries. They should select the least strict
policy that suits a registry's needs, and look for specific
justification for policies that require significant community
involvement (Specification Required, in terms of the well-known
policies)."
I am commenting on the above and not arguing for a change. What is
missing (in my opinion) is for the persons who will use the registry
in future to consider whether the proposed (registry) policy is not
too much work them.
Section 2.3.2 discusses about multiple policies in combination. It
is better to:
(i) Keep policies as simple as possible.
(ii) Have the same rules for everyone.
A combination of multiple policies makes it difficult for someone
unfamiliar with the registration process to understand what he or she
has to do to get an assignment. I suggest having such cases as one
policy, for example, "Expert Review" with information about what the
expert would need (e.g. an external specification).
In Section 3.3:
"In order to allow assignments in such cases, the IESG is granted
authority to override registration procedures and approve assignments
on a case-by-case basis."
In other words the registry policy used is "IESG Approval". There is
already a good description of that in Section 4.10. I do not see the
need to emphasize that the IESG has the authority to do so.
It seems that Section 3.3 is trying to address a different problem
than what is in RFC 7120, i.e. the registration procedure does not
adequately cover the reality of registry operation. For example,
there was an RFC published because an email address had to be
updated. It is onerous to go through such an effort for an email
address change. If that happens a few times it is a sign that the
registration procedure should be updated. Using a higher
registration procedure fulfills the documented registration
requirements. I suggest leaving the case of working group documents
to Section 3.4.
In Section 11:
"All IETF mailing lists associated with evaluating or discussing
assignment requests as described in this document are subject to
whatever rules of conduct and methods of list management are
currently defined by Best Current Practices or by IESG decision."
The "IESG decision" was in RFC 5226 too.
Regards,
S. Moonesamy