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

From: "Murray S. Kucherawy" <[email-masked]>
Date: Wed, 26 Jan 2022 07:38:06 -0800

Hi all,

The new version posted yesterday fixes the original problem but I think it
has a new one.  It now says:

   IANA is requested to assign the following types (Table 1) from the
   "NSH IETF- Assigned Optional Variable-Length Metadata Types" registry
   available at [IANA-NSH-MD2
<https://datatracker.ietf.org/doc/html/draft-ietf-sfc-nsh-tlv-12#ref-IANA-NSH-MD2>].These
Metadata Types only apply when the
   Metadata Class is 0x000 (IETF Base NSH MD Class)

I would argue that the trailing sentence is not part of the instructions to
IANA, and should be presented elsewhere in the document.  It's information
for implementers, not for IANA.

-MSK

On Sun, Dec 5, 2021 at 11:18 PM <[email-masked]> wrote:

> 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
>
> > -----Message d'origine-----
> > De : Martin Vigoureux <[email-masked]>
> > Envoyé : vendredi 3 décembre 2021 17:53
> > À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>;
> > [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)
> >
> > 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
> >
> > Le 2021-12-03 à 11:32, [email-masked] a écrit :
> > > Hi Yuehua,
> > >
> > > For Murray's DISCUSS point, I would proceed with this change rather
> than
> > the one in -10:
> > >
> > >
> > > ====
> > >   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 from the "NSH
> > IETF-
> > >       Assigned Optional Variable-Length Metadata Types" (0x0000 IETF
> > Base
> > >       NSH MD Class) registry available at [IANA-NSH-MD2]:
> > >
> > > ===
> > >
> > > 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,
> > >> I appreciate your comments.
> > >> Please see inline with Yuehua-n>>
> > >>
> > >> Best Regards,
> > >> Yuehua Wei
> > >> ZTE Corporation
> > >> ------------------原始邮件------------------
> > >> 发件人：MartinVigoureux
> > >> 收件人：Murray Kucherawy;The IESG;
> > >> 抄送人：[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 :
> > >>> 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
> > >> Yuehua-1>>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
> > >> 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.
> > >
>
>
> _________________________________________________________________________________________________________________________
>
> 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: Thu, 27 Jan 2022 11:35:42 +0800 (CST)

Hi Murray,
Thank you for pointing it out. 
Fixed in the new version : https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/

Best Regards,
Yuehua Wei
M: +86 13851460269 E: [email-masked]
------------------原始邮件------------------
发件人：MurrayS.Kucherawy
收件人：[email-masked];
抄送人：Martin Vigoureux;魏月华00019655;[email-masked];[email-masked];[email-masked];[email-masked];[email-masked];
日 期 ：2022年01月26日 23:38
主 题 ：Re: [sfc] Murray Kucherawy's Discuss on draft-ietf-sfc-nsh-tlv-09: (with DISCUSS and COMMENT)
Hi all,

The new version posted yesterday fixes the original problem but I think it has a new one.  It now says:

IANA is requested to assign the following types (Table 1) from the    "NSH IETF- Assigned Optional Variable-Length Metadata Types" registry    available at [IANA-NSH-MD2].These Metadata Types only apply when the    Metadata Class is 0x000 (IETF Base NSH MD Class)

I would argue that the trailing sentence is not part of the instructions to IANA, and should be presented elsewhere in the document.  It's information for implementers, not for IANA.

-MSK

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.
> Cc : [email-masked]; [email-masked]; [email-masked];
> Objet : Re: [sfc] Murray Kucherawy's Discuss on draft-ietf-sfc-nsh-tlv-09:
> I don't oppose to that but this is what confused Murray, so introducing it
> > For Murray's DISCUSS point, I would proceed with this change rather than
> the one in -10:
> >
> >
> > ====
> >   OLD:
> >> Objet : Re: [sfc] Murray Kucherawy's Discuss on draft-ietf-sfc-nsh-tlv-
> 09:
> >>> I'm having trouble understanding the first thing you've got in Section
> >> Thanks for catching this. This is indeed a bit confusing but the intent
> of
> >> Assigned Optional Variable-Length Metadata Types" registry available at
> >> [IANA-NSH-MD2]:
> >> -m
> >>
> >> Yuehua-4>>Will resolve Francesca's comment in the email thread reply to
> >> Yuehua-4>>Francesca's
> >>
> >>>
> >>>
> >>>
> >>>
> >>
_________________________________________________________________________________________________________________________
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.