Ben Campbell's No Objection on draft-ietf-rtgwg-lfa-manageability-09: (with COMMENT)

"Ben Campbell" <ben@nostrum.com> Tue, 23 June 2015 21:32 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5455C1A8783; Tue, 23 Jun 2015 14:32:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.001
X-Spam-Level:
X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001] autolearn=ham
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 RO8elNAvs9Jt; Tue, 23 Jun 2015 14:32:14 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A196F1A8769; Tue, 23 Jun 2015 14:32:14 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "Ben Campbell" <ben@nostrum.com>
To: "The IESG" <iesg@ietf.org>
Subject: Ben Campbell's No Objection on draft-ietf-rtgwg-lfa-manageability-09: (with COMMENT)
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.3.p3
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150623213214.6072.5997.idtracker@ietfa.amsl.com>
Date: Tue, 23 Jun 2015 14:32:14 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtgwg/ApO-5hl9NLDqtweerUhdqwa9x5w>
Cc: rtgwg@ietf.org
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.15
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 23 Jun 2015 21:32:16 -0000

Ben Campbell has entered the following ballot position for
draft-ietf-rtgwg-lfa-manageability-09: 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-rtgwg-lfa-manageability/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I've got nothing that rises to the level of a discuss, but I do have a
few comments:

*** Substantive Comments: ***

-- section 4, last paragraph:

This is an odd thing to make normative. It seems more a question of
business and ecosystem decisions.

-- 6.2.4.2:

Can you explain the "color" metaphor, or reference an explanation?

-- 8:

The entirety of the security considerations are of the form of "No new
considerations compared to [RFC5286]". Please offer supporting arguments
for that. For example, a high-level description of the nature of the
changes, new behaviors, or clarifications introduced in this draft, and
how those do or do not impact the security considerations.
*** Editorial Comments: ***

-- General:

There are pervasive grammatical errors, especially incorrect use of
singular and plural forms, missing articles, and incorrect use of commas.
The RFC editor will fix these, but you could save them quite a bit of
work by making another proofreading pass.

Also, throughout the draft, there are lists of examples in the form of
":A,B,C...". I suggest using the form "A,B,C etc.", or even better "For
example , A, B, and C" or "e.g., A, B, and C"

-- section 2, first bullet:

Last sentence is a fragment.

-- 3.1, last paragraph:

This seems to say that, in addition to the technical issues mentioned
here, service providers simply might not like it. Is that really what you
mean to say?

-- 4, last bullet:

Missing "to" . Otherwise, this renders to "... may be able monitor
constantly..."

-- 5, first paragraph: "As all FRR mechanism, ..."

I think there's one or more missing words. Do you mean "As [in/for] all
other FRR mechanisms, ..."?

"Depending of the hardware..."

s/of/on

'... compared to the amount of destinations in RIB."

I suggest " ... compared to the number of destinations in the RIB."

-- 2nd paragraph " ... permit to compute ... "

"Permit" needs a direct object. That is "... permits [something] to
compute...". What is the something?

(Note: This construction appears several times)

-- 6.1, first paragraph: "The granularity of LFA activation should be
controlled ..."

-- 6.1, last bullet in first list: "... SHOULD have a better priority ...
"
s/better/higher

-- 6.2, item 3 in the numbered list: "... an implementation SHOULD pick
only one based on its own
       decision, as a default behavior."

A "default behavior" implies that people might make non-default choices.
I suggest striking the phrase", as a default behavior".



I'm not sure what that means.

-- 2nd paragraph: " ... following criteria:"

I suggest s/criteria/granularities

(Note: I see quite a bit of the use of the word "criteria" when I think
you mean something else. )

-- 6.2.3:

What does "enhanced criteria" mean? Also the word "Downstreamness" seems
a bit of a stretch, but if the RFC editor lets that get by then more
power to you :-)

-- 6.2.4.1:
Please expand SRLG on first mention.

-- 6.2.5.4: 5th paragraph "... it is needed to limit..."

perhaps "... implementations need to limit..."

-- 9 and 10:

Section 9 is out of place (should probably go right before references),
and 10 is empty.