Re: [sfc] Alvaro Retana's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT)

["Murray S. Kucherawy" <[e-mail]>]

Hi Mohamed,

Thank you, that looks good.

-MSK

On Thu, Jul 15, 2021 at 8:32 AM <[e-mail]> wrote:

> Re-,
>
>
>
> Please see inline.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Murray S. Kucherawy [mailto:[e-mail]]
> *Envoyé :* jeudi 15 juillet 2021 17:18
> *À :* Joel Halpern Direct <[e-mail]>
> *Cc :* Alvaro Retana <[e-mail]>om>; The IESG <[e-mail]>rg>;
> Greg Mirsky <[e-mail]>om>; [e-mail];
> Service Function Chaining IETF list <[e-mail]>
> *Objet :* Re: [sfc] Alvaro Retana's No Objection on
> draft-ietf-sfc-nsh-integrity-06: (with COMMENT)
>
>
>
> On Thu, Jul 15, 2021 at 7:47 AM Joel Halpern Direct <
> [e-mail]> wrote:
>
> Given that the WG intent was that this be an optional extension, can you
> please suggest how we clarify that?
>
>
>
> It's obvious from this discussion that that was the WG intent, but is it
> also your view that this WG intent was made clear in the document?  That
> was certainly not my impression, and I infer from the number of ballot
> comments that that's not a singular view, though certainly that might be
> more obvious to someone directly involved in this space.
>
>
>
> How about this, or something like it, in your Abstract:
>
> CURRENT:
>
>    This specification adds integrity protection directly to the Network
>
>    Service Header (NSH) used for Service Function Chaining (SFC).  Also,
>
>    this specification allows to encrypt sensitive metadata that is
>
>    carried in the NSH.
>
> NEW 1:
>    This specification adds optional integrity protection directly to the Network
>
>    Service Header (NSH) used for Service Function Chaining (SFC).  Also,
>
>    this specification allows to encrypt sensitive metadata that is
>
>    carried in the NSH.
>
> NEW 2:
>    This specification presents an optional method to add
>    integrity protection directly to the Network
>
>    Service Header (NSH) used for Service Function Chaining (SFC).
>
>
>
> *[Med] I like this one. Thanks. *
>
>
>
>   Also,
>
>    this specification allows to encrypt sensitive metadata that is
>
>    carried in the NSH.
>
> ...and in Section 1:
>
> CURRENT:
>    This specification fills that gap.  Concretely, this document adds
>
>    integrity protection and optional encryption of sensitive metadata
>
>    directly to the NSH [...]
>
> *[Med] For this one, I think this is already covered by the text proposed to Alvaro. The NEW text can be seen at: https://tinyurl.com/nsh-integrity-latest <https://tinyurl.com/nsh-integrity-latest> *
>
>    This specification fills that gap for SFC (that is, define the "NSH
>
>    Variable Header-Based Integrity" option mentioned in Section 8.2.1 of
>
>                                     ^^^^^^
>
>    [RFC8300]).
>
>
>
> NEW:
>    This specification presents an optional extension that fills that gap.
>    Concretely, this document adds optional
>
>    integrity protection and encryption of sensitive metadata
>
>    directly to the NSH [...]
>
> -MSK
>
> _________________________________________________________________________________________________________________________
>
> 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.
>
>