Re: [Idr] WG LC for draft-ietf-idr-extcomm-iana-00.txt

Eric Rosen <erosen@cisco.com> Mon, 16 September 2013 18:26 UTC

Return-Path: <erosen@cisco.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50B2511E82EA for <idr@ietfa.amsl.com>; Mon, 16 Sep 2013 11:26:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -10.599
X-Spam-Level:
X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LMuPot2beZkB for <idr@ietfa.amsl.com>; Mon, 16 Sep 2013 11:26:33 -0700 (PDT)
Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id EA18321F9D92 for <idr@ietf.org>; Mon, 16 Sep 2013 11:26:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1281; q=dns/txt; s=iport; t=1379355993; x=1380565593; h=from:to:cc:subject:in-reply-to:reply-to:date:message-id; bh=sil2HRGX1/0qtXVjZ8TLu9EX1n1jdoNs5Qj37D81M+Y=; b=PI5br7OLkGLxci6tKQrSfyzgObIBOT2AF8fsuJ1bH+fwtfvC9Nvk6B5o JdbizO2/XZwSMTL6Bgl3zO964VxjxuLe+YkQtdwoq+CEebo0H8D2cu3hp nZu8BsPczbLQv+qbzVi9HarA7UscHEsiZsSt9d0PRRcczqX/hjkHT3LAe o=;
X-IronPort-AV: E=Sophos;i="4.90,917,1371081600"; d="scan'208";a="260528492"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-4.cisco.com with ESMTP; 16 Sep 2013 18:26:32 +0000
Received: from erosen-linux.cisco.com (erosen-linux.cisco.com [161.44.70.34]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id r8GIQVwr027661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 16 Sep 2013 18:26:32 GMT
Received: from erosen-linux (localhost.localdomain [127.0.0.1]) by erosen-linux.cisco.com (8.13.8/8.13.8) with ESMTP id r8GIQVdl030294; Mon, 16 Sep 2013 14:26:31 -0400
From: Eric Rosen <erosen@cisco.com>
To: Qin Wu <bill.wu@huawei.com>
In-reply-to: Your message of Fri, 13 Sep 2013 02:22:33 -0000. <B8F9A780D330094D99AF023C5877DABA43C0030A@nkgeml501-mbs.china.huawei.com>
Date: Mon, 16 Sep 2013 14:26:31 -0400
Message-ID: <30293.1379355991@erosen-linux>
Cc: idr wg <idr@ietf.org>, erosen@cisco.com, Susan Hares <shares@ndzh.com>, 'Yakov Rekhter' <yakov@juniper.net>
Subject: Re: [Idr] WG LC for draft-ietf-idr-extcomm-iana-00.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: erosen@cisco.com
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/idr>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 16 Sep 2013 18:26:39 -0000

> I believe it is better to add a reference to each registry to point out
> Where the attributed is defined and how to use this attribute.

These references should appear on the IANA web page (where the line length
is not restricted to 72 characters), but we didn't think it necessary to
include them in the draft

> I believe IPv6-address-Specific Extended Community should use the similar
> Syntax as the other registries, i.e., using 1st octet to indicate type and
> 2nd Octet to indicate subtype.

To me, there's not much value in having separate Sub-Type registries for the
IPv6-address-specific extended communities, as an IPv6-address-specific
extended community always begins with two octets of registered codepoint.
This is much simpler than the case of the "ordinary" extended communities,
which may begin with either octet or two octets of registered codepoint.  So
I think what we have proposed is satisfactory.  Of course, your proposal
would work also.

(What makes it complicated to administer the codepoints for the  "ordinary"
extended communities is that fact that the sub-type field isn't necessarily
present; sometimes the second octet is part of the value field.  The
IPv6-address-specific extended community doesn't have this issue.)