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

From: Barry Leiba via Datatracker <[email-masked]>
Date: Thu, 29 Oct 2020 21:32:12 -0700

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.)

---

From: <[email-masked]>
Date: Fri, 30 Oct 2020 08:18:34 +0000

Hi Barry,

All good suggestions. Thanks. 

I preferred to go with a new version fixing those:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-serviceid-header-12  

Cheers,
Med

> -----Message d'origine-----
> De : Barry Leiba via Datatracker [mailto:[email-masked]]
> Envoyé : vendredi 30 octobre 2020 05:32
> À : The IESG <[email-masked]>
> Cc : [email-masked]; [email-masked];
> [email-masked]; Greg Mirsky <[email-masked]>;
> [email-masked]
> Objet : Barry Leiba's No Objection on draft-ietf-sfc-serviceid-
> header-11: (with COMMENT)
> 
> 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.)
> 
> 
> I found this to be hard to read, despite its short length.  I hope
> my comments below can help with that.
> 
> — Abstract —
> 
> 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 —
> 
> That’s a long sentence with at least one grammatical error, and it’s
> hard to read.  May I suggest splitting it?:
> 
> NEW
> 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
> 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?
> 
> 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?
> 
> This also doesn’t parse.  I think you can fix this by adding “that”
> after “preclude“.
> 
> — Section 4 —
> 
> 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).
> (And can you also eliminate “received in an NSH packet” from that
> sentence?  I think so.)
> 
> 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 30 Oct 2020 10:19:56 -0400

Hi, Med.  Thanks for addressing my comments; great work, as always.

Barry