I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  Document editors and WG chairs should treat these comments just
like any other last call comments. I did not review Section 13.


Security Comments:

Given that this document is all about "Guidelines for Writing an IANA
Considerations Section in RFCs", the Security Considerations section
seems OK with regard to existing practice.

However, it is not clear to me that there is adequate defense against
denial of service attacks on IANA. In the real world, there is
something called "abuse of process". For example, there have been
cases in the USA where the law provided that you could stake mineral
rights claims to small areas of federal land for free by filing with
the local land registry office but there was a charge for larger
claims - so of course someone decided to file thousands of contiguous
free small claims, abusing a process intended to benefit people whose
total claims were small. The general solution in the real world for
such things is to go to court and the court can look at the purpose of
the law, its legislative history, etc., and issue orders to stop what
the court judges as abuse. While I don't think it has happened, IANA
should have a clear defense against, for example, someone grabbing a
huge number of values from a first-come-first-served registry with a
large but finite number of values. I suspect IANA would just go to the
IESG and it would all work out, but this document should say something
that IANA can do that. Section 3.3 on Overriding Registration
Procedures considers only cases where procedures should be relaxed. I
think Section 3.3 should clearly provide that IANA can go to the IESG
for anything that the IANA considers abuse of registration procedures.
Most of the text in Section 3.3 is fine. It just needs a few more
words - for example saying the IESG has authority to refuse assignment
that are abusive in the judgment of the IESG when asked to intervene
by IANA, as well as approve assignments under its override authority.


Comments that I Think Are Significant:

Given the completeness of this document in other regards, it seem odd
that it does not mention that there can be and are IANA registries
whose root is not the IETF but some other organization. For example,
the root authority for the IEEE 48-bit MAC address space is the IEEE
Registration Authority (http://standards.ieee.org/develop/regauth/)
and the root authority for the 8-bit CFM Op-Codes and TLV Types spaces
is the IEEE 802.1 Working Group. Nevertheless, IANA maintains
registries for the sub-assignment of code points from within the
ranges of these values that have been granted by the root authority to
the IANA/IETF.

In Section 2.3, we find
   "In particular, when a registry policy that requires involvement of
   Working Groups, directorates, or other bodies ..."
but in the IETF, Working Groups are transient entities. Registry
policy involvement of a WG not allowed and I have my doubts about
allowing "directorates". Use of a mailing list is OK because mailing
lists can be permanent.

And, at the very end of Section 2.3, it seems to imply that
"Specification Required" implies "significant community involvement"
which I think is wrong. My understanding is that there needs to be an
expert to judge that the specification cited in the assignment request
is adequate for interoperability.

Section 2.3.2: Talks about using multiple policies in a registry and
seems to imply the main reason for this would be different sources of
applications for assignment or just the general desirability in some
cases of having alternative policies. Completely missing here is any
reference to the many cases where disjoint ranges of code points are
given different registration policies but that is given in Section 4
where there is no mention of different sources of applications. Also
note that for registries where the assignment of a block of values
makes sense, such as MAC addresses under the IANA OUI, it makes sense
to have different policies for assignment of small ranges or a single
value and more stringent policies for assignment of large ranges. This
stuff probably shouldn't be split between Sections 2.3.2 and 4.

Although Section 4.7 makes it clear that any type of RFC can cause
assignments from a registry, I believe it is the case that any type of
RFC can, if appropriate, create an IANA Registry and it doesn't say
that in the draft unless I missed it...

Contrary to Section 9.1 of this draft, the draft does not have an IANA
Considerations Section.


Comments that I Think are Relatively Minor:

Section 2 seems to put undue emphasis on delegating the maintenance of
a registry to some non-IANA entity. As far as I know, it is extremely
rare that this is appropriate.

In Section 2.3.1, under item number 6, grouping is unclear. A reader
might not know if "significant" is supposed to modify "documentation"
or "expert review". I suggest changing the comma after "expert review"
to a semicolon or deleting the comma after "significant".

This draft frequently uses foobar but is missing an Informative
Reference to RFC 3092.

RFC Editor: Should RFC number 9876 be reserved for document use as it
is used here?


Controversial Comment:

Since I'm sometimes a bit stubborn, I will make one last point on
which, as far as I can tell, no one agrees with me. My point is the
error is the "order of strictness" list. Expert Review and
Specification Required both involve an expert and both involve
documentation. While it is true that Specification Required requires
that the documentation be public, unless there are further provisions,
the "expert" involved in Specification Required is restricted from
making a judgment on anything but the completeness and lack of
ambiguity of the document. On the other hand, I view Expert Review,
without further provisions, as the invocation of general Jon Postelian
review - the expert is to use their judgment, whatever that judgment
might wish to take into account subject only to defensibility and
reasonableness. Just as one example, there is no provision in
Specification Required for any increase in stringency as the number of
remaining code points dwindles even if the last one is being
allocated. On the other hand, one would expect that an Expert Review
expert would impose stricter and stricter reviews as available code
points dwindled (unless there were some explicit further provisions to
the contrary). I view the imposition of the expert's general judgment
to be a MUCH more restrictive criterion than the mere requirement that
documentation be published. I guess I might be willing to agree that
Specification Required and Expert Review were incomparable because, to
say one is stricter than the other, you have to say whether you think
a requirement that the specification be public is strong or weaker
than the requirement that the specification pass the unrestricted
judgment of the expert. But it any case, it is clearly wrong to say
the Specification Required is stricter than Expert Review.


?:

I went to the www.iana.org/protocols page and was unable to find the
Fruit Parameters Registry or the Fruit Access Flags... Maybe the IANA
Considerations Section that should be in this draft shouldn't be empty
but should create that Registry for documentation purposes...


Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street, Milford, MA 01757 USA
 d3e3e3@gmail.com