[ANCP] IANA issue with draft-ietf-ancp-mc-extensions-11.txt and RFC6320

"Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com> Mon, 18 November 2013 17:28 UTC

Return-Path: <matthew.bocci@alcatel-lucent.com>
X-Original-To: ancp@ietfa.amsl.com
Delivered-To: ancp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 9077921F9F8F for <ancp@ietfa.amsl.com>; Mon, 18 Nov 2013 09:28:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -108.846
X-Spam-Status: No, score=-108.846 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 48CB-JlZuGr4 for <ancp@ietfa.amsl.com>; Mon, 18 Nov 2013 09:27:56 -0800 (PST)
Received: from ihemail4.lucent.com (ihemail4.lucent.com []) by ietfa.amsl.com (Postfix) with ESMTP id 0175D11E8152 for <ancp@ietf.org>; Mon, 18 Nov 2013 09:26:52 -0800 (PST)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (h135-239-2-42.lucent.com []) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id rAIHQl0B000500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 18 Nov 2013 11:26:49 -0600 (CST)
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com []) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id rAIHQl6C002411 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 18 Nov 2013 18:26:47 +0100
Received: from FR711WXCHMBA05.zeu.alcatel-lucent.com ([]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([]) with mapi id 14.02.0247.003; Mon, 18 Nov 2013 18:26:47 +0100
From: "Bocci, Matthew (Matthew)" <matthew.bocci@alcatel-lucent.com>
To: Tom Taylor <tom.taylor.stds@gmail.com>, "ancp@ietf.org" <ancp@ietf.org>
Thread-Topic: IANA issue with draft-ietf-ancp-mc-extensions-11.txt and RFC6320
Thread-Index: AQHO5INbb71mhMRRT06DUgsIsW2Kzg==
Date: Mon, 18 Nov 2013 17:26:46 +0000
Message-ID: <CEAFFB7B.57C67%matthew.bocci@alcatel-lucent.com>
In-Reply-To: <52844883.5010607@gmail.com>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="euc-kr"
Content-ID: <3DA57BF6D2A8E047858520D309F08DF4@exchange.lucent.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.57 on
Subject: [ANCP] IANA issue with draft-ietf-ancp-mc-extensions-11.txt and RFC6320
X-BeenThere: ancp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Access Node Control Protocol working group mailing list <ancp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ancp>, <mailto:ancp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ancp>
List-Post: <mailto:ancp@ietf.org>
List-Help: <mailto:ancp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ancp>, <mailto:ancp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Nov 2013 17:28:02 -0000


There are a couple of issues that we have picked up with this draft, and
the registries that were created on request of RFC6320, is as follows.

The draft assigns a code point 3 in the ANCP Capability Type Registry for
NAS-Initiated Replication. However, that value is currently reserved,
rather than unassigned.

The definition of “reserved" in RFC5226 is as follows:

"Reserved:  Not to be assigned.  Reserved values are held for
            special uses, such as to extend the namespace when it become
            exhausted.  Reserved values are not available for general

This was set as reserved by RFC6320. I assume it was reserved for the
multicast draft, but this seems to clash with the definition of reserved

Secondly, the draft requests some allocations from the ANCP result codes
registry. The IANA web page states that future allocation from the the
IETF consensus range should start from 0x100. However, the draft requests
allocations starting form 0x64. I believe that this is a result of a
decimal/hex typo. This should be corrected, and also the FCFS range
starting at 0x1000 (which I suspect should mean 1000).

It is probably easier to resolve this by making the multicast draft update
RFC6320 in terms of the rules associated with the relevant IANA registries.

Here is how I suggest we do it:
- Add a sentence to the IANA section requesting that they change the
allocation policy for the IETF Review section of the results codes
registry so that it is sequential starting at 0x64.
- Add a note to the abstract and the introduction explaining this.
- Add an Updates: 6320 statement to the draft header.
- While we area about it, please  also check that the ‘Specification
required’ range really starts at 0x1000 rather than 1000.