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 at gmail.com