Subject: [sfc] Murray Kucherawy's Discuss on draft-ietf-sfc-nsh-integrity-06: (with DISCUSS and COMMENT)

From: Murray Kucherawy via Datatracker <[email-masked]>
Date: Wed, 14 Jul 2021 23:13:41 -0700

Murray Kucherawy has entered the following ballot position for
draft-ietf-sfc-nsh-integrity-06: Discuss

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 DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-integrity/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Enough other Area Directors have said, and I agree, that this should officially
update RFC 8300, so I'd like to have the discussion.  In particular, given that
this was identified as a gap in RFC 8300, and since I don't see any explicit
statement that this is meant to be an optional extension, shouldn't it be an
update?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Only nits to add, given the thorough treatment already given by others:

Section 4.1.2: "The first level of assurance where all NSH data ..." -- add
"is" before "where"?  And the same issue in the next paragraph.

Section 5.2: s/Coves/Covers/

---

From: <[email-masked]>
Date: Thu, 15 Jul 2021 09:54:29 +0000

Hi Murray, 

Thanks for the comments.

I don't have much to add to the DISCUSS point in addition to what both Joel and myself said in other threads. We added new text as agreed with Alvaro and Zahed to make sure that we are referring to an option that is discussed in RFC8300 + we don't recommend against transport security. We will add the update header if this is the conclusion of the IESG discussion. We will follow Martin's guidance on this.

Fixed the nits as you can see in: https://tinyurl.com/nsh-integrity-latest.

Cheers,
Med

> -----Message d'origine-----
> De : Murray Kucherawy via Datatracker [mailto:[email-masked]]
> Envoyé : jeudi 15 juillet 2021 08:14
> À : The IESG <[email-masked]>
> Cc : [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Objet : Murray Kucherawy's Discuss on draft-ietf-sfc-nsh-integrity-
> 06: (with DISCUSS and COMMENT)
> 
> 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.)
> 
> 
> Enough other Area Directors have said, and I agree, that this should
> officially update RFC 8300, so I'd like to have the discussion.  In
> particular, given that this was identified as a gap in RFC 8300, and
> since I don't see any explicit statement that this is meant to be an
> optional extension, shouldn't it be an update?
> 
> 
> Section 4.1.2: "The first level of assurance where all NSH data ..."
> -- add "is" before "where"?  And the same issue in the next
> paragraph.
> 

_________________________________________________________________________________________________________________________

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: "Joel M. Halpern" <[email-masked]>
Date: Thu, 15 Jul 2021 08:52:34 -0400

The whole point of the earlier discussion is that this is an optional 
extension.  The fact that if you do it, it is mandatory to do it as 
described does not make this mandatory for implementations of 8300. 
None of the words in this document have that effect.

if the IESG wants to retroactively change 8300, that may be one of the 
few things that could actually cause the working group to engage, as 
folks were strongly against mandating the support for this.

Yours,
Joel

On 7/15/2021 2:13 AM, Murray Kucherawy via Datatracker wrote:
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc
>

---

From: "Murray S. Kucherawy" <[email-masked]>
Date: Thu, 15 Jul 2021 07:03:10 -0700

On Thu, Jul 15, 2021 at 2:54 AM <[email-masked]> wrote:

> I don't have much to add to the DISCUSS point in addition to what both
> Joel and myself said in other threads. We added new text as agreed with
> Alvaro and Zahed to make sure that we are referring to an option that is
> discussed in RFC8300 + we don't recommend against transport security. We
> will add the update header if this is the conclusion of the IESG
> discussion. We will follow Martin's guidance on this.
>

I honestly did try to find such a thread before posting my position.  I
apologize for missing it.  I'll find and review that, and then get out of
your way.

-MSK