Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt

Nick Hilliard <nick@foobar.org> Sun, 16 October 2016 21:10 UTC

Return-Path: <nick@foobar.org>
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 C912C1294F8 for <idr@ietfa.amsl.com>; Sun, 16 Oct 2016 14:10:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] 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 J88Ywl6Y16i9 for <idr@ietfa.amsl.com>; Sun, 16 Oct 2016 14:10:55 -0700 (PDT)
Received: from mail.netability.ie (mail.netability.ie [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D141E129467 for <idr@ietf.org>; Sun, 16 Oct 2016 14:10:54 -0700 (PDT)
X-Envelope-To: idr@ietf.org
Received: from cupcake.local (089-101-070074.ntlworld.ie [89.101.70.74] (may be forged)) (authenticated bits=0) by mail.netability.ie (8.15.2/8.15.2) with ESMTPSA id u9GLApLq017005 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 16 Oct 2016 22:10:52 +0100 (IST) (envelope-from nick@foobar.org)
X-Authentication-Warning: cheesecake.ibn.ie: Host 089-101-070074.ntlworld.ie [89.101.70.74] (may be forged) claimed to be cupcake.local
Message-ID: <5803ECD9.3060405@foobar.org>
Date: Sun, 16 Oct 2016 22:10:49 +0100
From: Nick Hilliard <nick@foobar.org>
User-Agent: Postbox 5.0.4 (Macintosh/20161007)
MIME-Version: 1.0
To: Brian Dickson <brian.peter.dickson@gmail.com>
References: <57F92043.20301@foobar.org> <A9BBA442-361F-444F-9AFC-33FAAF5F6061@gmail.com> <00ff01d22214$a9832440$4001a8c0@gateway.2wire.net> <57FAD3EA.6070800@foobar.org> <020b01d223a1$f0e34a20$4001a8c0@gateway.2wire.net> <20161011095417.GL19434@gir.theapt.org> <1476317462333.82977@dacor.de> <00fb01d2252f$700c2360$4001a8c0@gateway.2wire.net> <370dd06bff7c425db78dc82c5bce8907@XCH-ALN-014.cisco.com> <015001d226da$32df80c0$4001a8c0@gateway.2wire.net> <20161015124556.GW57491@Vurt.local> <8D4A7FDB-FBAC-4914-AE32-7D46EDC564C7@gmail.com>
In-Reply-To: <8D4A7FDB-FBAC-4914-AE32-7D46EDC564C7@gmail.com>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/xg9V0LqMKmtRFAH9YegQSDSdFaM>
Cc: idr <idr@ietf.org>
Subject: Re: [Idr] I-D Action: draft-ietf-idr-large-community-01.txt
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
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: <https://mailarchive.ietf.org/arch/browse/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: Sun, 16 Oct 2016 21:10:57 -0000

Brian Dickson wrote:
> > My concern starts with the protocol rather than the implementation,
> > seeing getting the protocol right as the first step, even if it does
> > not seem possible at present for a router to enforce the protocol
> > rigidly.

Brian,

this is indeed one part of the problem: the lack of a protocol for
handling your suggestion.  If you have suggestions for a new protocol
which will allow a router to determine whether the global administrator
field is an ASN, along with an adequate definition of what you intend
the term "ASN" to mean in this context, then please post a separate
draft and the WG can chew it over.

Until there is a protocol in place to make this viable, demanding MUST
instead of SHOULD is creating a requirement for standards-track
mandatory compliance with a poorly-defined specification which, as you
note, cannot be enforced. This is not wise, and it has no place in a
standards-track document.

Nick