[mpls] Barry Leiba's No Objection on draft-ietf-mpls-sfl-framework-10: (with COMMENT)

Barry Leiba via Datatracker <noreply@ietf.org> Fri, 18 September 2020 16:16 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: mpls@ietf.org
Delivered-To: mpls@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F78B3A00C9; Fri, 18 Sep 2020 09:16:23 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Barry Leiba via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-mpls-sfl-framework@ietf.org, mpls-chairs@ietf.org, mpls@ietf.org, Tarek Saad <tsaad.net@gmail.com>, tsaad.net@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.17.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Barry Leiba <barryleiba@computer.org>
Message-ID: <160044578316.29422.16391227942596603238@ietfa.amsl.com>
Date: Fri, 18 Sep 2020 09:16:23 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/lMRWcZzf7NYJG31Q7sWTLGfOAAU>
Subject: [mpls] Barry Leiba's No Objection on draft-ietf-mpls-sfl-framework-10: (with COMMENT)
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Sep 2020 16:16:23 -0000

Barry Leiba has entered the following ballot position for
draft-ietf-mpls-sfl-framework-10: 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-mpls-sfl-framework/



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

Thanks for a clear, well-written document that was an easy read.  Just a few
nits here:

— Section 3 —

   would introduce network wide forwarding state.

“network-wide” needs a hyphen

   Note that to achieve the goals set out above SFLs need to be
   allocated from the platform label table.

A comma after “above” will help readability here (avoiding a reading of “above
SFLs”).

— Section 4.1 —
The title says “applications label” and the first paragraph says “application
label”.  It seems that this should be consistent.

   function present runs over the "normal" stack, and SFL enabled flows

“SFL-enabled” needs a hyphen (also in Section 4.2).

— Section 4.1.1 —

   However it is recognised that, if
   there is an applications need, the SFL MAY be to some other value.

I think “MAY be set to some other value” (add “set”) reads better.

— Section 4.2 —

   If the LSP label is present, it processed exactly as it would
   normally processed and then it is popped.

Missing words: “it is processsed” and “normally be processed”.

   This reveals the SFL which
   in the case of [RFC6374] measurements is simply counted and then

Punctuation: “SFL, which, in the case of [RFC6374] measurements, is”

   system described in this document the behaviour of two approaches are
   indistinguishable and thus either may be implemented.

Missing word: “of the two approaches”.
And “behaviours”, needs to be plural.

— Section 4.3 —

   application is large, and consequently the increase in the number of
   allocated labels needed to support the SFL actions consequently
   becomes too large to be viable.

You have “consequently” twice, and should remove one of them.

— Section 5 —

   The introduction to an SFL to an existing flow may cause that flow to

Make it, “The introduction of an SFL to an existing flow”.

   This in turn may invalidate the certain uses

Remove “the”.

— Section 6 —

   This privacy threat may
   be mitigated by encrypting the control protocol packets, regularly
   changing the synonymous labels and by concurrently using a number of
   such labels.

The second item isn’t parallel to the other two.  Either make it “by regularly”
(to make the second item match the third) or remove “by” before “concurrently”
(to make the third match the second).

Also, is “and” right?  Would you do all three of these together?  Or should it
be “or”?  I’m not sure, but I wanted to check.