Re: [GROW] Suresh Krishnan's No Objection on draft-ietf-grow-large-communities-usage-07: (with COMMENT)

heasley <heas@shrubbery.net> Wed, 10 May 2017 23:33 UTC

Return-Path: <heas@shrubbery.net>
X-Original-To: grow@ietfa.amsl.com
Delivered-To: grow@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0673C126BFD; Wed, 10 May 2017 16:33:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.303
X-Spam-Level:
X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 FI87YNFbnC08; Wed, 10 May 2017 16:32:58 -0700 (PDT)
Received: from guelah.shrubbery.net (guelah.shrubbery.net [198.58.5.1]) by ietfa.amsl.com (Postfix) with ESMTP id ADD981287A5; Wed, 10 May 2017 16:32:58 -0700 (PDT)
Received: by guelah.shrubbery.net (Postfix, from userid 7053) id 496F7815A9; Wed, 10 May 2017 23:32:57 +0000 (UTC)
Date: Wed, 10 May 2017 23:32:57 +0000
From: heasley <heas@shrubbery.net>
To: Suresh Krishnan <suresh.krishnan@gmail.com>
Cc: The IESG <iesg@ietf.org>, grow-chairs@ietf.org, grow@ietf.org, draft-ietf-grow-large-communities-usage@ietf.org
Message-ID: <20170510233257.GA62166@shrubbery.net>
References: <149438282678.22615.11296946678795602668.idtracker@ietfa.amsl.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <149438282678.22615.11296946678795602668.idtracker@ietfa.amsl.com>
X-PGPkey: http://www.shrubbery.net/~heas/public-key.asc
X-note: live free, or die!
X-homer: i just want to have a beer while i am caring.
X-Claimation: an engineer needs a manager like a fish needs a bicycle
X-reality: only YOU can put an end to the embarrassment that is Tom Cruise
User-Agent: Mutt/1.8.0 (2017-02-23)
Archived-At: <https://mailarchive.ietf.org/arch/msg/grow/LRD-cMtBX3y0ZRXqweHKsnsn3-s>
Subject: Re: [GROW] Suresh Krishnan's No Objection on draft-ietf-grow-large-communities-usage-07: (with COMMENT)
X-BeenThere: grow@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Grow Working Group Mailing List <grow.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/grow>, <mailto:grow-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/grow/>
List-Post: <mailto:grow@ietf.org>
List-Help: <mailto:grow-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/grow>, <mailto:grow-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 10 May 2017 23:33:01 -0000

Tue, May 09, 2017 at 07:20:26PM -0700, Suresh Krishnan:
> Suresh Krishnan has entered the following ballot position for
> draft-ietf-grow-large-communities-usage-07: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-grow-large-communities-usage/
> 
> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Overall the document was well written and easy to read. I did have one
> question though. It is not clear how the values for the Local data part 1
> are matched up to the functions and communicated between the peer ASes?
> Is this going to stay purely a local matter between ASes or is there
> going to be a movement towards some sets of known functions (e.g. the BGP
> blackhole community RFC7999)?

LD1 and LD2 are expected to be unique to and defined by the GA (ASN).
No effort was made to address standardizing LD1 or LD2 values and this
was intentionally avoided in discussion of both this draft and RFC8092,
which itself creates no well-knowns like RFC7999.  well-knowns such as
RFC7999 are well served by RFC1997 communities and may co-exist with
RFC8092 communities, thus there is no need to duplicate them.

An effort could be made to standardize LD1 or LD2 or define well-knowns
requiring the utility of RFC8092, but that is considered out of scope
for this draft - and likely a rathole best explored separately.

Thanks for reviewing.

Prost