RE: Last Call: <draft-leiba-cotton-iana-5226bis-12.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]

 



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




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