Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)

Nick Hilliard <> Sat, 29 October 2016 14:47 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C5AC61295BC for <>; Sat, 29 Oct 2016 07:47:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.201
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kpEGq46ovWMm for <>; Sat, 29 Oct 2016 07:47:30 -0700 (PDT)
Received: from ( [IPv6:2a03:8900:0:100::5]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8AAB71295F3 for <>; Sat, 29 Oct 2016 07:47:30 -0700 (PDT)
Received: from cupcake.local ( [] (may be forged)) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id u9TElQg4093290 (version=TLSv1 cipher=ECDHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 29 Oct 2016 15:47:26 +0100 (IST) (envelope-from
X-Authentication-Warning: Host [] (may be forged) claimed to be cupcake.local
Message-ID: <>
Date: Sat, 29 Oct 2016 15:47:25 +0100
From: Nick Hilliard <>
User-Agent: Postbox 5.0.5 (Macintosh/20161020)
MIME-Version: 1.0
To: Brian Dickson <>
References: <20161020215938.GE1074@Vurt.local> <> <> <> <> <> <> <> <20161021164241.GC32387@Vurt.local> <20161022123423.GD79185@Space.Net> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.2.3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Archived-At: <>
Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 29 Oct 2016 14:47:33 -0000

Brian Dickson wrote:
> What I am proposing, is to make the document internally consistent.
> The last paragraph of section 1 (Introduction) reads as follows:
>     To address these shortcomings, this document defines a Large BGP
>        Communities attribute encoded as one or more twelve-octet values,
>        each consisting of a four-octet ASN and two four-octet operator-
>        defined values, each of which can be used to denote properties or
>        actions significant to that ASN
>  Making the field descriptions and wording in section 2 agree with this,
> is the intent.


hmm yes, I agree this is a problem that needs to be fixed.

> Since there has been no disagreement on the introduction, and in
> fact that the introduction was offered as proof that there was no
> need to change the wording (to which I disagree), I was suggesting
> the changes that move toward the general understanding conveyed in
> the introduction.

The spec for the first 4 octets in the document is "Global
Administrator" and this is located in section 2.  The introduction is an
introduction, not a definition.  The text for this has been cleaned up
to make it consistent with section 2 and Job plans to post -07 later
today (see for diffs).  I've also gone through the
rest of the document to ensure that there are no other inconsistencies
in this area.

The other issues you raised in your email were all raised prior to
John's email of oct 24, and I don't really want to get bogged down in
another round of arguments about them.