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

From: <[email-masked]>
Date: Fri, 3 Dec 2021 17:02:23 +0800 (CST)

Dear Martin and Murray,
I appreciate your comments.
Please see inline with Yuehua-n>>

Best Regards,
Yuehua Wei
ZTE Corporation
------------------原始邮件------------------
发件人：MartinVigoureux
收件人：Murray Kucherawy;The IESG;
抄送人：[email-masked];[email-masked];[email-masked];[email-masked];
日 期 ：2021年12月02日 18:47
主 题 ：Re: Murray Kucherawy's Discuss on draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT)
Hello Murray
Le 2021-12-02 à 7:34, Murray Kucherawy via Datatracker a écrit :
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-sfc-nsh-tlv-09: 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/blog/handling-iesg-ballot-positions/
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/
>
>
>
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> I'm having trouble understanding the first thing you've got in Section 7.  You
> have one table of assignments to make, but you're referencing two distinct
> sub-registries under "Network Service Header (NSH) Parameters", namely "NSH MD
> Class" and "NSH IETF-Assigned Optional Variable-Length Metadata Types".  There
> doesn't appear to be a "metadata context type registry".  I think this change
> clarifies what you mean, but please tell me if I'm wrong:
>
> OLD:
>
>     IANA is requested to assign the following types from the "NSH IETF-
>     Assigned Optional Variable-Length Metadata Types" (0x0000 IETF Base
>     NSH MD Class) registry available at [IANA-NSH-MD2]:
>
>     This document defines the following new values (Table 1) in the
>     Network Service Header (NSH) metadata context Type registry:
>
> NEW:
>
>     IANA is requested to assign the following types (Table 1) from the IETF
>     Review range in the "NSH MD Class" sub-registry of the "Network Service
>     Header (NSH) Parameters" registry:
Thanks for catching this. This is indeed a bit confusing but the intent
of the draft doesn't match with your suggestion:
The new metadata defined by this document shall be registered in "NSH
IETF-Assigned Optional Variable-Length Metadata Types".
So each object will have its own type but all will be of the same MD
Class (0x0000, which is the only value registered by 8300, and which is
in the "NSH MD Class" registry).
So I think the new text should simply be:
IANA is requested to assign the following types from the "NSH IETF-
Assigned Optional Variable-Length Metadata Types" registry available
at [IANA-NSH-MD2]:
-m

Yuehua-1>>Will delete "(0x0000 IETF Base NSH MD Class)" which is confusing and not needed here

>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> Thank you for a well done shepherd writeup.
>
> I support Ben's DISCUSS position, particularly the first point.

Yuehua-2>>Will resolve Ben's comments in the email thread reply to Ben's

> A suggestion on organization: I think what you have as the top of Section 7
> should be a subsection (e.g., 7.1), and then the other subsections moved down.
> It doesn't make sense to me to have these registrations be dominant over the
> others; they're all just a set of IANA actions.

Yuehua-3>>Accepted. will update to ver10

> I have the same comment as Francesca about Section 4.1.

Yuehua-4>>Will resolve Francesca's comment in the email thread reply to Francesca's

---

From: <[email-masked]>
Date: Fri, 3 Dec 2021 10:32:39 +0000

Hi Yuehua, 

For Murray's DISCUSS point, I would proceed with this change rather than the one in -10:

====
 OLD:

 NEW:

===

Please note that the assigned values should be bound to the MD Class 0x0000.

Cheers,
Med

> -----Message d'origine-----
> De : sfc <[email-masked]> De la part de [email-masked]
> Envoyé : vendredi 3 décembre 2021 10:02
> À : [email-masked]; [email-masked]
> Cc : [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Objet : Re: [sfc] Murray Kucherawy's Discuss on draft-ietf-sfc-nsh-tlv-09:
> (with DISCUSS and COMMENT)
> 
> Dear Martin and Murray,
> 抄送人：[email-masked];sfc-
> [email-masked];[email-masked];[email-masked];
> 日 期 ：2021年12月02日 18:47
> 主 题 ：Re: Murray Kucherawy's Discuss on draft-ietf-sfc-nsh-tlv-09: (with
> DISCUSS and COMMENT) Hello Murray Le 2021-12-02 à 7:34, Murray Kucherawy
> via Datatracker a écrit :
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> >
> > Please refer to
> > https://www.ietf.org/blog/handling-iesg-ballot-positions/
> > I'm having trouble understanding the first thing you've got in Section
> > 7.  You have one table of assignments to make, but you're referencing
> > two distinct sub-registries under "Network Service Header (NSH)
> > Parameters", namely "NSH MD Class" and "NSH IETF-Assigned Optional
> > Variable-Length Metadata Types".  There doesn't appear to be a
> > "metadata context type registry".  I think this change clarifies what
> you mean, but please tell me if I'm wrong:
> >
> > OLD:
> >
> Thanks for catching this. This is indeed a bit confusing but the intent of
> the draft doesn't match with your suggestion:
> So each object will have its own type but all will be of the same MD Class
> (0x0000, which is the only value registered by 8300, and which is in the
> "NSH MD Class" registry).
> Assigned Optional Variable-Length Metadata Types" registry available at
> [IANA-NSH-MD2]:
> -m
> 
> Yuehua-1>>Will delete "(0x0000 IETF Base NSH MD Class)" which is
> Yuehua-1>>confusing and not needed here
> 
> >
> >
> > A suggestion on organization: I think what you have as the top of
> > Section 7 should be a subsection (e.g., 7.1), and then the other
> subsections moved down.
> > It doesn't make sense to me to have these registrations be dominant
> > over the others; they're all just a set of IANA actions.
> 
> Yuehua-4>>Will resolve Francesca's comment in the email thread reply to
> Yuehua-4>>Francesca's
> 
> >
> >
> >
> >
> 
> _______________________________________________
> sfc mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sfc

_________________________________________________________________________________________________________________________

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: Martin Vigoureux <[email-masked]>
Date: Fri, 3 Dec 2021 17:52:49 +0100

Med,

I don't oppose to that but this is what confused Murray, so introducing 
it back as is may not be the best thing to do. Also, I don't think this 
is relevant for the registration of the new values. The body of document 
is very explicit that they are for MD Class 0x0000.

-m

---

From: <[email-masked]>
Date: Mon, 6 Dec 2021 07:18:34 +0000

Hi Martin, 

I think the confusion can be clarified if we read this part from RFC8300:

   The Type values within the IETF Base NSH MD Class, i.e., when the MD
   Class is set to 0x0000 (see Section 9.1.4), are the Types owned by
   the IETF.  Per this document, IANA has created a registry for the
   Type values for the IETF Base NSH MD Class called the "NSH IETF-
   Assigned Optional Variable-Length Metadata Types" registry, as
   specified in Section 2.5.1.

The reasoning for calling out 0x0000 under the IANA section is to save a check for IANA to make sure that the requested codepoints are for this specific MD Class. 

Anyway, I think that the current text should be fixed:

==

==

The second sentence should be deleted. It is this part which is confusing.

Cheers,
Med

> De : Martin Vigoureux <[email-masked]>
> Envoyé : vendredi 3 décembre 2021 17:53
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>;
> [email-masked]; [email-masked]
> I don't oppose to that but this is what confused Murray, so introducing it
> back as is may not be the best thing to do. Also, I don't think this is
> relevant for the registration of the new values. The body of document is
> very explicit that they are for MD Class 0x0000.
> 
> -m
> 
> >>>      IANA is requested to assign the following types (Table 1) from
> the
> >> IETF
> of
> Class
> __________________________________________________________________________
> > 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,
> > This message and its attachments may contain confidential or privileged
> information that may be protected by law;

---

From: <[email-masked]>
Date: Mon, 6 Dec 2021 17:57:16 +0800 (CST)

Dear Martin and mohamed,
Thank you for the comments and clarification. 
I would like to delete the second paragraph and wouldn't calling out 0x0000

Best Regards,
Yuehua Wei
ZTE Corporation
------------------原始邮件------------------
发件人：[email-masked]
收件人：Martin Vigoureux;魏月华00019655;[email-masked];
抄送人：[email-masked];[email-masked];[email-masked];[email-masked];[email-masked];
日 期 ：2021年12月06日 15:18
主 题 ：RE: [sfc] Murray Kucherawy's Discuss on draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT)
Hi Martin,
I think the confusion can be clarified if we read this part from RFC8300:
The Type values within the IETF Base NSH MD Class, i.e., when the MD
Class is set to 0x0000 (see Section 9.1.4), are the Types owned by
the IETF.  Per this document, IANA has created a registry for the
Type values for the IETF Base NSH MD Class called the "NSH IETF-
Assigned Optional Variable-Length Metadata Types" registry, as
specified in Section 2.5.1.
The reasoning for calling out 0x0000 under the IANA section is to save a check for IANA to make sure that the requested codepoints are for this specific MD Class.
Anyway, I think that the current text should be fixed:
==
IANA is requested to assign the following types from the "NSH IETF-
Assigned Optional Variable-Length Metadata Types" registry available
at [IANA-NSH-MD2]:
This document defines the following new values (Table 1) in the
Network Service Header (NSH) metadata context Type registry:
==
The second sentence should be deleted. It is this part which is confusing.
Cheers,
Med