[sfc] Barry Leiba's No Objection on draft-ietf-sfc-serviceid-header-11: (with COMMENT)

Barry Leiba via Datatracker <noreply@ietf.org> Fri, 30 October 2020 04:32 UTC

Return-Path: <noreply@ietf.org>
X-Original-To: sfc@ietf.org
Delivered-To: sfc@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 79DB43A0114; Thu, 29 Oct 2020 21:32:12 -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-sfc-serviceid-header@ietf.org, sfc-chairs@ietf.org, sfc@ietf.org, Greg Mirsky <gregimirsky@gmail.com>, gregimirsky@gmail.com
X-Test-IDTracker: no
X-IETF-IDTracker: 7.21.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Barry Leiba <barryleiba@computer.org>
Message-ID: <160403233247.1318.15677242757103993593@ietfa.amsl.com>
Date: Thu, 29 Oct 2020 21:32:12 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/sfc/fNLwH35a6I-IqTqabpBWOtRwTVs>
Subject: [sfc] Barry Leiba's No Objection on draft-ietf-sfc-serviceid-header-11: (with COMMENT)
X-BeenThere: sfc@ietf.org
X-Mailman-Version: 2.1.29
List-Id: Network Service Chaining <sfc.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sfc>, <mailto:sfc-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sfc/>
List-Post: <mailto:sfc@ietf.org>
List-Help: <mailto:sfc-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sfc>, <mailto:sfc-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 30 Oct 2020 04:32:12 -0000

Barry Leiba has entered the following ballot position for
draft-ietf-sfc-serviceid-header-11: 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-sfc-serviceid-header/



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

I found this to be hard to read, despite its short length.  I hope my comments
below can help with that.

— Abstract —

   This document defines Subscriber and Performance Policy Identifiers
   Network Service Header Variable-Length Context Headers to inform

That string of capitalized words really is indecipherable.  I think that’s
because it’s talking about three separate things (Identifiers, Network Service
Headers, and Context Headers) with nothing to separate them.  Can you reword
the sentence to fix that?

Maybe, “This document defines Subscriber and Performance Policy Identifiers
that can be put into variable-length Context Headers within the Network Service
Header to inform...”?

— Section 1 —

   NAT functionality can reside in a distinct
   node which for 3GPP network can be the Packet Data Network (PDN)
   Gateway (PGW) as specified in [TS23401] in case of 4G or the User
   Plane Function (UPF) facing the external Data Network (DN) [TS23501]
   in case of 5G, respectively.

That’s a long sentence with at least one grammatical error, and it’s hard to
read.  May I suggest splitting it?:

NEW
   NAT functionality can reside in a distinct node.  For a 4G 3GPP
   network, that node can be the Packet Data Network (PDN)
   Gateway (PGW) as specified in [TS23401].  For a 5G 3GPP
   network it can be the User Plane Function (UPF) facing the
   external Data Network (DN) [TS23501].
END

   This approach avoids
   to require additional internal structures of the Context Headers

You can’t “avoid to require”.  You can say that the approach “avoids the
requirement of additional...”, or, better, simply “avoids additional...”.

— Section 3 —

   In order
   to prevent interoperability issues, the type the identifiers carried
   in the Subscriber Identifier Context Headers and their format to be
   injected in such header should be configured to nodes authorized to
   inject and consume such headers.

I can’t parse that sentence, and I can’t suggest a fix because I have no idea
what it’s trying to say.  I don’t know whether the issue is grammar or
difficult wording.  Can you please fix it?

   Local policies may require running additional validation checks on
   the content of these Context Headers (e.g., accept only some lengths,
   types) and the behavior to adopt at NSH-aware SFs.

You lose me here at “and the behavior”: I don’t see how it’s supposed to
connect to the rest of the sentence.  Are you trying to say that: 1. Local
policies may require running validation checks, and 2. Local policies may
define the behavior to adopt ?

Or is it something else?

   However, this specification does not require nor preclude
   such NSH-aware SFs may be instructed to ignore the Context Header

This also doesn’t parse.  I think you can fix this by adding “that” after
“preclude“.

— Section 4 —

   Dedicated service-specific performance identifiers are defined to
   differentiate between services requiring specific treatment to
   exhibit a performance characterized by, e.g., ultra-low latency (ULL)
   or ultra-high reliability (UHR).

Another sentence I can’t make sense of.  Can you please re-word it?

   adapted dynamically by on-the move SFC path and SF instance

Nit: you need one more hyphen, “on-the-move”.

   Multiple Performance Policy Identifier Context Headers MAY be present
   in the NSH; each carrying an opaque value

Nit: change the semicolon to a comma.

   o  Performance Policy Identifier: Represents an opaque value pointing
      to specific performance policy to be enforced.  The structure and
      semantic of this field is deployment-specific.

Nit: “semantics” as a noun is always used in plural form.

— Section 6 —

   Access to subscriber data usually requires specific access privilege
   levels.  To avoid bypassing this guard, it is not advised that an SF
   maintaining logs for operational reasons to also log the content of
   Subscriber and Performance Policy Context Headers received in NSH
   packets if the SF does not use the content of that header for its
   operation.

The second sentence has some grammatical errors and is hard to read, partly
because of a chain of negatives (avoid bypassing, not advised, does not use). 
Please reword this to say things more directly.  Maybe something like this?:

NEW
   Access to subscriber data usually requires specific access privilege
   levels.  To maintain that protection, an SF keeping operational logs
   should not log the content of a Subscriber and Performance Policy
   Context Header received in an NSH packet unless the SF actually
   uses the content of that particular header for its operation.
END

(And can you also eliminate “received in an NSH packet” from that sentence?  I
think so.)