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

[[e-mail]]

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]>; The IESG <[e-mail]>; Greg Mirsky <[e-mail]>; [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]<mailto:[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
   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.