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" <adrian@olddog.co.uk> Tue, 26 April 2016 20:30 UTC

Return-Path: <adrian@olddog.co.uk>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C27FB12D56C; Tue, 26 Apr 2016 13:30:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aW84XjF_vTJu; Tue, 26 Apr 2016 13:30:02 -0700 (PDT)
Received: from asmtp4.iomartmail.com (asmtp4.iomartmail.com [62.128.201.175]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A6A712D0A6; Tue, 26 Apr 2016 13:30:01 -0700 (PDT)
Received: from asmtp4.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id u3QKS4c9011010; Tue, 26 Apr 2016 21:28:04 +0100
Received: from 950129200 (jplon-nat14.juniper.net [193.110.55.14]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id u3QKS302010990 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 26 Apr 2016 21:28:04 +0100
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: <ietf@ietf.org>
References: <20160419141640.31545.54742.idtracker@ietfa.amsl.com>
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: Tue, 26 Apr 2016 21:28:02 +0100
Message-ID: <057701d19ffa$2291b5b0$67b52110$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQD6sjSRIIB+2MCyMyZ0rhhMk0byWqFCSc7AgAhB+rA=
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1679-8.0.0.1202-22286.002
X-TM-AS-Result: No--11.377-10.0-31-10
X-imss-scan-details: No--11.377-10.0-31-10
X-TMASE-MatchedRID: 9zTThWtzImtfsB4HYR80ZggKAWhuC2ojb6bRSg4rpzvM7zpEspqG/yQK VkaL89O9Wvpt4uqyaUEcPMPBmVk68HmKI6b62ffnUSn3o+eoUmzDHSNFHFxB81vym/gvSH4iakc q2RAHKcqD67iPeqoD/gSmL1+CJjGb8P4Bf0DnMRuMVQb49Y23I4LsLasl5ROhxaQNbiRXdZoDkd 7WQNL44uLzNWBegCW2XC3N7C7YzrfkwjHXXC/4IzsAVzN+Ov/sBvOTRKyP23fRw3LGe3O6GsTsE Q2p7sMrzOcn9pmdN6KtnlQyvBfVYw==
Archived-At: <http://mailarchive.ietf.org/arch/msg/ietf/MtU6cutG8UoAvVZeoft23pxtOGU>
Cc: draft-leiba-cotton-iana-5226bis@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: adrian@olddog.co.uk
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Apr 2016 20:30:07 -0000

Hi,

A couple of further thoughts arising from the discussions on the WG chairs'
mailing list (but not claiming the opinions as other than my own).

Section 4.4
Aim to set the expectations of consumers better (and fix the grammar) by...
OLD
 For numbers, the exact
 value is generally assigned by IANA; with names, specific text
   strings can usually be requested.
NEW:
 For numbers, IANA generally assigns the next in-sequence unallocated
 value, but other values may be requested and assigned if an extenuating
 circumstance exists.  With names, specific text strings can usually be
 requested.
END

Section 6
Include hint on best practice for top and bottom of ranges.
OLD
     Reserved: Not assigned and not available for assignment.  Reserved
           values are held for special uses, such as to extend the
           namespace when it becomes exhausted.  Note that this is
           distinctly different from "Unassigned".
NEW
     Reserved: Not assigned and not available for assignment.  Reserved
           values are held for special uses, such as to extend the
           namespace when it becomes exhausted.  Note that this is
           distinctly different from "Unassigned".

          It is common practice for documents that define numeric registries
          to mark the zero value as "Reserved" because this often aids protocol 
          implementations.  It is also common practice to mark the maximum
          value as "Reserved" so that it can be used as part of a strategy to
          extend the registry if the range proves too small in the future.
END

Thanks,
Adrian