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

Brian Dickson <brian.peter.dickson@gmail.com> Sat, 22 October 2016 21:48 UTC

Return-Path: <brian.peter.dickson@gmail.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 7B851126D74 for <idr@ietfa.amsl.com>; Sat, 22 Oct 2016 14:48:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level:
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 fV3HMD6PgSzF for <idr@ietfa.amsl.com>; Sat, 22 Oct 2016 14:48:22 -0700 (PDT)
Received: from mail-pf0-x232.google.com (mail-pf0-x232.google.com [IPv6:2607:f8b0:400e:c00::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E19A1294E3 for <idr@ietf.org>; Sat, 22 Oct 2016 14:48:21 -0700 (PDT)
Received: by mail-pf0-x232.google.com with SMTP id 128so76315009pfz.0 for <idr@ietf.org>; Sat, 22 Oct 2016 14:48:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1/3D2P2uySLsv7xWQWfg9FCh9dSrnqHptK5MfncAY7I=; b=Mo0nG0W9L5sKjkNPB+4cr7gUEjiKutiJotkE9KhnBmf2UqOPyuGR88Hb+P4IJ7i++2 CioVA6BANT7N5A8Hrdt6ijCAgNYukBYe0mzo923nZ4nKP9QzhkrInEFP/wtYkTzUkr1Z OJ1/Q6b1bDDxbm/tsoFyfE0GomyRKEmGYZHeKYt0HRpgh+u7Yo7kA6JqoTSymSrKRnAN VHsB6dPoluMgUetlt+rUGkHNQwsSDQgWFAVPgvwmHkAwDUD1krjw79RMN2xYP7dQQPvD ZoM6AV2sGICHzJPXPxdPOssyO03wRIOmX8fwgiuh3ixgnFG9rHo9CvxE4aA7tArTh0vo ITGQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=1/3D2P2uySLsv7xWQWfg9FCh9dSrnqHptK5MfncAY7I=; b=PTsW6zxeip5maMoOeP/u0ztgv2WaD2fTW7XXqYiX5AxXWnpQSw+qQeIvv+gxIjC7Zt 2zQKfzNUlT+fasmLRT08LsoVCEnhyV8Xk0KSohWajdeJfLl2a6hmkH54JtKEjOVlZImh gmd1wBoYFGsFetIPCflLQ7dqDONkb130jTDffKA3gWbjv1iuWVQ9ppAQvoyATLDG3NRf 8Nfivk/2xGY290BYvAUmiz499AUUPP8mRaw8fwuLKd0qNumzeD5oFM2E/ugzwfOMS1Op N6DjGOvs6IEr+ITMhzAgZOTlaPpZSONK9iCk6z7m3oGgR2K2VH5JycDuOecbw5s/FdYB iAyg==
X-Gm-Message-State: ABUngvdp1PBPbRZsJ85Boj4aloblIIuYob8vp4bfikUkUZTrre/j1ITAXWZ0JlKzts2PMg==
X-Received: by 10.99.167.75 with SMTP id w11mr11927427pgo.16.1477172900803; Sat, 22 Oct 2016 14:48:20 -0700 (PDT)
Received: from [192.168.5.105] (c-73-92-109-167.hsd1.ca.comcast.net. [73.92.109.167]) by smtp.gmail.com with ESMTPSA id uh10sm14413224pab.5.2016.10.22.14.48.18 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sat, 22 Oct 2016 14:48:18 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-363C285B-6143-4ECC-ADD5-44613191DB0B"
Mime-Version: 1.0 (1.0)
From: Brian Dickson <brian.peter.dickson@gmail.com>
X-Mailer: iPhone Mail (14A456)
In-Reply-To: <25cfd19e-cf33-7380-89c0-d11bc6128139@i3d.net>
Date: Sat, 22 Oct 2016 14:48:16 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <0EADF517-72CF-47DA-B9D4-69B3CACE02E5@gmail.com>
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> <20161020215938.GE1074@Vurt.local> <adb00bcd7b8e45db857eae7019c646fc@XCH-ALN-014.cisco.com> <ae5da282-201c-f745-9f26-67ce73826bd5@i3d.net> <CA+b+ERkV2PBtzzx=uoygDzvTyJzunROCNX=0Y4phvGdn=oK5Xw@mail.gmail.com> <20161021154958.GR27221@gir.theapt.org> <CA+b+ERmrzCtFLP98D0YzRc-BJNbBWp3Ce6yKZr2cg1_QS0Oz5w@mail.gmail.com> <2ddbfbaf-7b99-53b9-365c-269fcc7746e7@i3d.net> <CAH1iCirkxRXqe0-7=NEjRuO46Kv+GfMASuDJxCXngMRU2c7kAw@mail.gmail.com> <25cfd19e-cf33-7380-89c0-d11bc6128139@i3d.net>
To: "i3D.net - Martijn Schmidt" <martijnschmidt@i3d.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/sDG8D8OE5MXoCJcipLZrgkwJxEg>
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: Sat, 22 Oct 2016 21:48:25 -0000

Hi, Martin,

My concern is that there are differences between the language in the introduction, in the main body, and in the additional text.

Similar to the difference between a newspaper headline and the article content, if there is any disconnect, which takes precedence?

I'd like every place it's used, for the GA==ASN to be crystal clear.

If it were the other way around (intro wrong or unclear, main definition right), I would be fine with it.

IMHO the only place it actually needs to be fixed is where I initially indicated.
Either works: no 2119 language and "is an ASN", or use of "MUST".

Brian

Sent from my iPhone

> On Oct 22, 2016, at 3:39 AM, i3D.net - Martijn Schmidt <martijnschmidt@i3d.net> wrote:
> 
> Hi Brian,
> 
> Doesn't the existing wording "The Global Administrator field is intended to allow different Autonomous Systems to define Large BGP Communities without collision." already achieve what you want, if you feel that RFC2119 language is not necessary?
> 
> Best regards,
> Martijn
> 
>> On 10/22/2016 12:15 AM, Brian Dickson wrote:
>> 
>> 
>>> On Fri, Oct 21, 2016 at 9:21 AM, i3D.net - Martijn Schmidt <martijnschmidt@i3d.net> wrote:
>>> 
>>> Summarizing, any restrictions which can not be enforced don't belong in the IDR document because they're irrelevant to implementors. Arguing about it doesn't change the fact that such recommendations belong in a BCP/GROW document. It is that simple.
>> 
>> I'd like to pick a nit with the argument here, as a counter-point to what I think needs to be in the document.
>> 
>> There are plenty of IDR-specified things that are not enforced or enforceable, which are nonetheless necessary to define or specify.
>> 
>> Those include things such as:
>> next-hop
>> router-id
>> cluster-id
>> AS-path component(s) [injecting ASNs via prepend mechanisms]
>> MED
>> Including Global Administrator (with a definition of it as _being_ an ASN), is all that is required -- if necessary, rewording it to not use RFC 2119 language. 
>> 
>> Like all of those other things, they can be set by operators, and are not able to be enforced without severely restricting operators' activities.
>> 
>> Implementors who apply restrictions on those, may encounter resistance from their customers, their sales folks and potential customers, and their customers' peers.
>> 
>> Brian
> 
> -- 
> Met vriendelijke groet / Kindest regards, 
> Martijn Schmidt
> 
> 
> <i3Dlogo-email.png>	
> Martijn Schmidt | Network Architect
> Email: martijnschmidt@i3d.net | Tel: +31 10 8900070
> 
> i3D.net B.V. | Global Backbone AS49544
> Van Nelleweg 1, 3044 BC Rotterdam, The Netherlands
> VAT: NL 8202.63.886.B01
> 
> Website | Case Studies | LinkedIn
> 
> _______________________________________________
> Idr mailing list
> Idr@ietf.org
> https://www.ietf.org/mailman/listinfo/idr