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

[Barry Leiba <[e-mail]>]

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

Barry

On Fri, Oct 30, 2020 at 4:18 AM <[e-mail]> wrote:
>
> 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.
>