Thanks to the authors for resurrecting this work, and thanks also for addressing comments from the previous review cycle. I went back and read the review comments I entered back in 2014 when the document was last up before the IESG (https://datatracker.ietf.org/doc/draft-leiba-cotton-iana-5226bis/ballot/#adrian -farrel) before I did this review and I feel that the general point still applies that it is really hard for a document author to extract a simple "cookbook for an IANA considerations section". [I'm afraid I can no longer swap in the context of any email threads that happened at that time.] Maybe this is intended to be covered at the URL mentioned in 1.2 - that would be good, but had I held my breath back in 2014 and waited for this URL to receive some content, I would not now be bothering you with this email! (All the detailed nits I raised back then seem to have been addressed, however, so very many thanks!) I think this document is ready for publication, but I wonder whether some further emphasis for clarity might be added to section 4.4. The point I would like to labor is that the assignment is made for a specific use not for a specific person, organization, company, etc. You do already state that changes to the registration of a First Come First Served code point retain compatibility with the current usage of that code point, and this is exactly the right message. But I have recently heard several cases of a code point that was assigned using FCFS as "Foo Corp's BLEAGH protocol" being completely repurposed by Foo Corp as "Foo Corp's YUCK protocol". You appear to be saying that "this should not happen" and I largely agree (modulo - we really know this is not in the field), but how is IANA to interpret this text and how do you expect them to act if Foo Corp sends them mail to say what they have done? Maybe also a forward pointer to 9.4 and 9.5? In 4.9 you have For the Standards Action policy, values are assigned only through Standards Track or Best Current Practice RFCs approved by the IESG. Do you want to harmonize this with language in other sections by saying "IETF Stream" not "approved by the IESG"? 15.1 has a dated title. Cheers, Adrian > 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-12.txt> as Best Current Practice