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

Mikael Abrahamsson <swmike@swm.pp.se> Thu, 20 October 2016 10:13 UTC

Return-Path: <swmike@swm.pp.se>
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 4A05E129581 for <idr@ietfa.amsl.com>; Thu, 20 Oct 2016 03:13:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.432
X-Spam-Level:
X-Spam-Status: No, score=-2.432 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.431, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
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 AiaSN2BFKwEa for <idr@ietfa.amsl.com>; Thu, 20 Oct 2016 03:13:51 -0700 (PDT)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5A034129577 for <idr@ietf.org>; Thu, 20 Oct 2016 03:13:51 -0700 (PDT)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id BFC85A2; Thu, 20 Oct 2016 12:13:48 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1476958428; bh=+BS84+ak9hmk8HlvGftX6aVQdi0JPabNXKxiXsniqq4=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=AcI8Dzrl/B8xB2vJBBNGXWkplYwN3Ej7eX6oQV//Eyp+O3HWQ+oyeTFLibCh3T8FX r06raq4BA9XVgpXEfnE/Sq1lM9CjHrBygFb/ZYujjmHQ2HVT638jB0DWMwsZKF0VPr ckRlwXH7XnPRXhGmddNVn9MWCxe+uGOfsG37DXVA=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id B2696A1; Thu, 20 Oct 2016 12:13:48 +0200 (CEST)
Date: Thu, 20 Oct 2016 12:13:48 +0200 (CEST)
From: Mikael Abrahamsson <swmike@swm.pp.se>
To: "t.petch" <ietfc@btconnect.com>
In-Reply-To: <01ad01d22ab2$2c8c4060$4001a8c0@gateway.2wire.net>
Message-ID: <alpine.DEB.2.02.1610201212500.12036@uplift.swm.pp.se>
References: <01f301d228b4$e3319ef0$a994dcd0$@ndzh.com> <20161017215134.GA464@pfrc.org> <20161018190851.GC15392@shrubbery.net> <20161018191521.GT95811@Vurt.local> <9EFC9BAA-F917-4C70-A139-1F69CAECF9C0@pfrc.org> <007201d229f6$b4ae9680$4001a8c0@gateway.2wire.net> <20161019185405.GA12214@puck.nether.net> <CAH1iCirF_1ODLtLzeVhKmQPDeeGcczcQCSPXDcro=OQv2ipR3A@mail.gmail.com> <5807F3AF.9080200@foobar.org> <CA+b+ERn_7Bs8CeAgKrxSPiMPOCsE4pH9hoD+76tEDrWM-KYVRw@mail.gmail.com> <CAH1iCirF2C-83z3hYC4bBqMYW7zHs1eeofySVipyODo=8FNQxg@mail.gmail.com> <CA+b+ER=oyCTF24f1pAQQjA0ogMCtqw0rKWzT7+jcNpL4WjPjHQ@mail.gmail.com> <CAH1iCipd+wyFVwvunjVFxF1t52j3_sKm5efGXzNH8xwHLndaHQ@mail.gmail.com> <alpine.DEB.2.02.1610200756430.12036@uplift.swm.pp.se> <01ad01d22ab2$2c8c4060$4001a8c0@gateway.2wire.net>
User-Agent: Alpine 2.02 (DEB 1266 2009-07-14)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/T1wzbRFOhRPnkn3j9tKcwRXmfdY>
Cc: IETF IDR WG <idr@ietf.org>
Subject: Re: [Idr] WG LC on draft-ietf-idr-large-community-03.txt (10/17/2016 to 10/31/2016)
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: Thu, 20 Oct 2016 10:13:53 -0000

On Thu, 20 Oct 2016, t.petch wrote:

> In theory, I agree with you but in practice, I expect it will be at
> least a year or two before GROW produces such a document.  In the
> meantime, I would go with Jeff's suggestion to include an 'Operational
> Considerations' section in this I-D (and that then could refer to
> RFC7454 and clarify the meaning of 'high order bits').
>
> But I think that we have yet to agree what such a section would say.

Exactly. So do you still want to delay the progress of this document until 
we (perhaps never) reach consensus on what the fields should be?

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se