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

[[e-mail]]

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:[e-mail]]
> Envoyé : vendredi 30 octobre 2020 05:32
> À : The IESG <[e-mail]>
> Cc : [e-mail]; [e-mail];
> [e-mail]; Greg Mirsky <[e-mail]>;
> [e-mail]
> Objet : Barry Leiba's No Objection on draft-ietf-sfc-serviceid-
> header-11: (with COMMENT)
> 
> 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.)
> 
> 


_________________________________________________________________________________________________________________________

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.