[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.)
- [sfc] Barry Leiba's No Objection on draft-ietf-sf… Barry Leiba via Datatracker
- Re: [sfc] Barry Leiba's No Objection on draft-iet… mohamed.boucadair
- Re: [sfc] Barry Leiba's No Objection on draft-iet… Barry Leiba