Re: Last Call: <draft-leiba-cotton-iana-5226bis-08.txt> (Guidelines for Writing an IANA Considerations Section in RFCs) to Best Current Practice

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]