Re: [GROW] Genart telechat review of draft-ietf-grow-bgp-reject-07

worley@ariadne.com (Dale R. Worley) Mon, 22 May 2017 20:29 UTC

Return-Path: <worley@alum.mit.edu>
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 5C717126CF9 for <grow@ietfa.amsl.com>; Mon, 22 May 2017 13:29:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.034
X-Spam-Level:
X-Spam-Status: No, score=-0.034 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=no 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 iErJbBw5zJOu for <grow@ietfa.amsl.com>; Mon, 22 May 2017 13:29:12 -0700 (PDT)
Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (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 E8A4A128D3E for <grow@ietf.org>; Mon, 22 May 2017 13:29:09 -0700 (PDT)
Received: from resomta-ch2-02v.sys.comcast.net ([69.252.207.98]) by resqmta-ch2-08v.sys.comcast.net with SMTP id CtvJdYp1KAfZsCtwzdz4cp; Mon, 22 May 2017 20:29:09 +0000
Received: from hobgoblin.ariadne.com ([IPv6:2601:192:4603:9471:222:fbff:fe91:d396]) by resomta-ch2-02v.sys.comcast.net with SMTP id CtwxdDfBMgFBHCtwydXxyB; Mon, 22 May 2017 20:29:08 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id v4MKT6Jn027775; Mon, 22 May 2017 16:29:06 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id v4MKT6Qe027772; Mon, 22 May 2017 16:29:06 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com
To: draft-ietf-grow-bgp-reject.all@ietf.org
Cc: gen-art@ietf.org, grow@ietf.org, ietf@ietf.org
In-Reply-To: <20170522110448.3obnrbam2who3n5x@hanna.meerval.net> (job@ntt.net)
Sender: worley@ariadne.com
Date: Mon, 22 May 2017 16:29:06 -0400
Message-ID: <87y3topre5.fsf@hobgoblin.ariadne.com>
X-CMAE-Envelope: MS4wfAxBBu6rgFrsuUKA/dfrY3rzlEUHyojfmf+F1Vh+nayF4uI4wlQj/VatywxOm9IlzWcjfTuA9a7GhMv4hN/rxCW8DqtsRmvfZiBlIAPr2RjSl70++Cm9 Po46PrWDfJNPutCab6VsjawdR4UmlFRnDEpaRQBxR8ceJs8M6mQXl8mE+yYnpo+XC6YSPS5PhME38j0HSqDuWScvnCG4W5uMdlLNa4pm34ZqfCw0JRIG85XC tfYmbRo99FJYhkPjEPEHeGo2C1m9jo3rydQvvQZrF4c=
Archived-At: <https://mailarchive.ietf.org/arch/msg/grow/PfazLM_AJwo9DaseyqVA9V1X7Ek>
Subject: Re: [GROW] Genart telechat review of draft-ietf-grow-bgp-reject-07
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: Mon, 22 May 2017 20:29:17 -0000

I agree with all the changes that have been discussed, with the
following additional suggestions:

Job Snijders <job@ntt.net> writes:
>>    Appendix A.  Transition Considerations
>> 
>>    It is anticipated that transitioning to a compliant BGP
>>    implementation will require a process thay may take several years.
>> 
>> You probably want to s/a compliant BGP implementation/compliant BGP
>> implementations/, unless you are describing the process for an
>> individual operator, not for all operators collectively.
>
> The process refers to the vendors of BGP implementations, not operators.
> Given that the appendix is targetted mostly to the vendor audience,
> would you have a suggestion within that context?

"Hankins, Greg (Nokia - US)" <greg.hankins@nokia.com> writes:
> How about this change for clarity:
> - old: It is anticipated that transitioning to a compliant BGP implementation
> will require a process thay may take several years.
> - new: Transitioning to a compliant BGP implementation may require a software
> development and release process that can take implementers several years.

I suspect my problems come from not realizing there has been a change of
focus.  (It may be much clearer to routing people.)  So I would suggest
expanding the title of Appendix A to "Transition Considerations for
Vendors of BGP Implementations".

As you point out, in the context of a vendor, the correct wording is "a
compliant BGP implementation".

Even with that change, the change Greg suggests makes sense.  Although
it might be easier to read if the "for an implementor" is brought to the
front of the sentence, where it won't stretch out the flow of the rest
of the sentence.  Something like

    For an implementer, transitioning to a compliant BGP implementation
    may require a software development and release process that can take
    several years.

Perhaps "a software development and release" can be omitted.


"Hankins, Greg (Nokia - US)" <greg.hankins@nokia.com> writes:
> Hi Dale, this paragraphs seems wordy now, so I would suggested splitting
> sentences as follows:
>
> This document updates [RFC4271] so that routes are neither imported nor
> exported unless specifically enabled by configuration.  The solution
> reduces the consequences of these problems, and improves the default level
> of Internet routing security.

In that case, I'd start the second sentence with "This change ..." or
perhaps "This update ..." -- nothing has previously been labeled a
"solution", so the reader has to search a bit to determine the
antecedent.

Dale