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

"Adrian Farrel" <> Thu, 21 April 2016 15:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4737F12DE7B; Thu, 21 Apr 2016 08:11:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id NSOy-vKmho35; Thu, 21 Apr 2016 08:11:23 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CCCB712E436; Thu, 21 Apr 2016 08:11:19 -0700 (PDT)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id u3LF95tG009304; Thu, 21 Apr 2016 16:09:05 +0100
Received: from 950129200 ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id u3LF93K5009266 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 21 Apr 2016 16:09:04 +0100
From: "Adrian Farrel" <>
To: <>
References: <>
In-Reply-To: <>
Subject: RE: Last Call: <draft-leiba-cotton-iana-5226bis-12.txt> (Guidelines for Writing an IANA Considerations Section in RFCs) to Best Current Practice
Date: Thu, 21 Apr 2016 16:09:05 +0100
Message-ID: <06b601d19bdf$bf725b10$3e571130$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQD6sjSRIIB+2MCyMyZ0rhhMk0byWqFCSc7A
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--12.327-10.0-31-10
X-imss-scan-details: No--12.327-10.0-31-10
X-TMASE-MatchedRID: gjZGo2H/wj9fsB4HYR80ZggKAWhuC2ojb6bRSg4rpzuo+b+yOP0oGOhu cPsHg+lUVou3tdUwrwv+5Sngvyncm4XVLLOFXneznVTWWiNp+v+sBP5mv7DuayG8WMGwsRk0+6X wUEj2jUrctUcKuR6f5ATqfG8+r3FKZFRqrQuuReFdIpzA9POr8uBgp+G3IXxrIfg3G4Q08Gj+tn MvnQl+U/AFbtEwRr9cvMCF9IKt8R4BDyUlObljv691/YHX0i1lu1b0t4ooa9vROhK+RFWo5hzll v0af4rKafcnFY/rkJAAzLwZoZKu8lDAEECFhQnKeUyVZX4ivrtzd7C7BtJobusoDDE6CvPdPlF5 N5t2gL/us5Y6tXWJTG2+sEpeMprvCEMM7muZaodMkJTSstTiqM/rSr8VfmGwRoS5c9eVHmoDdbq f2nbl9FXEvU+FtIj3eAZCO3WnFdSL3nwNzypZrJgGnz93PV93s+SyIdviDnyhUoducQu06XkvYG lzSDgV2TaDGX0BbTtIcWiYbodCz2bRarzMLj8yngIgpj8eDcC063Wh9WVqghziNLWewPgd+gtHj 7OwNO3Ix3Icp6zuW/KlLG2J0ZSz489InB5iHeKtG/HGcy1UeOmAfNw/VyJk
Archived-At: <>
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 21 Apr 2016 15:11:27 -0000

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
-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.


> 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