Subject: [sfc] Shepherd's review of draft-ietf-sfc-nsh-integrity

From: Greg Mirsky <[email-masked]>
Date: Tue, 23 Mar 2021 09:27:13 -0700

Dear Authors,
thank you for your work on this very important and well-written document.
It is easy to read and grasp the technical concept of the proposed
solutions. Below, please find my notes and proposals addressing editorial
nits:

   - s/referred to is/referred to as/
   - s/integrity protected/integrity-protected/g
   - s/access to an information/access to information/
   - s/See for example,/See, for example,/
   - Is there a need to use the normative language in the following text or
   make the "should adopt" text more assertive:

      An NSH-aware SF can also be instructed about the behavior it
      should adopt after consuming a context information that was
      supplied in the NSH.

   - s/a context information/context information/
   - s/A first level/The first level/
   - s/A second level/The second level/
   - s/four octet/four-octet/
   - s/The documents does not/The document does not/
   - s/for certain amount/for a certain amount/
   - s/variable length/variable-length/
   - s/excluding/, excluding/g
   - s/In typical deployments/In typical deployments,/
   - s/used to integrity protect/used to protect the integrity of/g
   - s/proceeds then/proceeds/
   - s/been tampered/been tampered with/
   - s/such those/such as those/
   - s/out of scope/out of the scope/
   - s/rate limited/rate-limited/
   - s/secdir/SecDir/ or extend it completely

Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 23 Mar 2021 10:53:54 -0700

Dear Authors,
I should have checked IDnits results early. From me looking at it, two
DownRefs marked as the most severe issues:

   - normative reference to RFC 7665 SFC Architecture
   - normative reference to RFC 8877 Guidelines for Defining Packet
   Timestamps

In my opinion, the former is reasonable as a reader must be familiar with
the SFC architecture. Do you think that the latter reference can be moved
to the Informational References list?

Regards,
Greg

On Tue, Mar 23, 2021 at 9:27 AM Greg Mirsky <[email-masked]> wrote:

>    - Is there a need to use the normative language in the following text
>    or make the "should adopt" text more assertive:
>

---

From: <[email-masked]>
Date: Tue, 23 Mar 2021 18:05:01 +0000

Hi Greg,

Good catch for 8877. We can move it to informative as the only citation is:

   This section follows the template provided in Section 3 of [RFC8877].

I lost the context what we had it as normative.

Cheers,
Med

De : Greg Mirsky [mailto:[email-masked]]
Envoyé : mardi 23 mars 2021 18:54
À : [email-masked]; [email-masked]; Service Function Chaining IETF list <[email-masked]>
Objet : Re: Shepherd's review of draft-ietf-sfc-nsh-integrity

Dear Authors,
I should have checked IDnits results early. From me looking at it, two DownRefs marked as the most severe issues:

  *   normative reference to RFC 7665 SFC Architecture
  *   normative reference to RFC 8877 Guidelines for Defining Packet Timestamps
In my opinion, the former is reasonable as a reader must be familiar with the SFC architecture. Do you think that the latter reference can be moved to the Informational References list?

Regards,
Greg

On Tue, Mar 23, 2021 at 9:27 AM Greg Mirsky <[email-masked]<mailto:[email-masked]>> wrote:
Dear Authors,
thank you for your work on this very important and well-written document. It is easy to read and grasp the technical concept of the proposed solutions. Below, please find my notes and proposals addressing editorial nits:

  *   s/referred to is/referred to as/
  *   s/integrity protected/integrity-protected/g
  *   s/access to an information/access to information/
  *   s/See for example,/See, for example,/
  *   Is there a need to use the normative language in the following text or make the "should adopt" text more assertive:
      An NSH-aware SF can also be instructed about the behavior it
      should adopt after consuming a context information that was
      supplied in the NSH.

  *   s/a context information/context information/
  *   s/A first level/The first level/
  *   s/A second level/The second level/
  *   s/four octet/four-octet/
  *   s/The documents does not/The document does not/
  *   s/for certain amount/for a certain amount/
  *   s/variable length/variable-length/
  *   s/excluding/, excluding/g
  *   s/In typical deployments/In typical deployments,/
  *   s/used to integrity protect/used to protect the integrity of/g
  *   s/proceeds then/proceeds/
  *   s/been tampered/been tampered with/
  *   s/such those/such as those/
  *   s/out of scope/out of the scope/
  *   s/rate limited/rate-limited/
  *   s/secdir/SecDir/ or extend it completely
Regards,
Greg

_________________________________________________________________________________________________________________________

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: <[email-masked]>
Date: Tue, 23 Mar 2021 18:11:31 +0000

Re-,

Thank you for the review.

You can track the changes at: https://tinyurl.com/nsh-integrity-latest.

Please see inline.

Cheers,
Med

De : Greg Mirsky [mailto:[email-masked]]
Envoyé : mardi 23 mars 2021 17:27
À : [email-masked]; [email-masked]; Service Function Chaining IETF list <[email-masked]>
Objet : Shepherd's review of draft-ietf-sfc-nsh-integrity

Dear Authors,

  *   s/referred to is/referred to as/
[Med] The OLD one is correct.

[Med] Fixed.

  *   s/access to an information/access to information/
[Med] Changed to “NSH-supplied information”

[Med] Fixed.

  *   Is there a need to use the normative language in the following text or make the "should adopt" text more assertive:
      An NSH-aware SF can also be instructed about the behavior it
      should adopt after consuming a context information that was
      supplied in the NSH.
[Med] I don’t think so. This is more on the control plane side.

[Med] OK

[Med] Fixed

[Med] Idem.

[Med] OK

[Med] Fixed. Thanks.

[Med] Fixed.

[Med] OK

[Med] OK

[Med] OK

[Med] OK

[Med] Fixed

[Med] Left the OLD one.

[Med] Sure.

[Med] OK

[Med] OK

[Med] Expanded it
Regards,
Greg

---

From: Greg Mirsky <[email-masked]>
Date: Tue, 23 Mar 2021 18:58:13 -0700

Hi Med,
thank you for your thoughtful response. I am OK with the proposed updates,
they address my comments perfectly.

Regards,
Greg

On Tue, Mar 23, 2021, 11:11 <[email-masked]> wrote:

> *De :* Greg Mirsky [mailto:[email-masked]]
> *Envoyé :* mardi 23 mars 2021 17:27
> *À :* [email-masked]; [email-masked]; Service
> Function Chaining IETF list <[email-masked]>
> *Objet :* Shepherd's review of draft-ietf-sfc-nsh-integrity
>
>
>
> Dear Authors,
>
> *[Med] The OLD one is correct. *
>
> *[Med] Fixed. *
> *[Med] Changed to “NSH-supplied information”*
>
> *[Med] Fixed. *
> *[Med] I don’t think so. This is more on the control plane side. *
>
>
> *[Med] OK*
> *[Med] Fixed*
> *[Med] Idem. *
> *[Med] OK*
> *[Med] Fixed. Thanks. *
> *[Med] Fixed. *
> *[Med] OK*
> *[Med] OK*
> *[Med] OK*
> *[Med] OK*
> *[Med] Fixed*
> *[Med] Left the OLD one. *
>
> *[Med] Sure.*
> *[Med] OK*
> *[Med] OK*
> *[Med] Expanded it*