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

["Murray S. Kucherawy" <[e-mail]>]

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 <[e-mail]> 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 <[e-mail]>
> > Envoyé : vendredi 3 décembre 2021 17:53
> > À : BOUCADAIR Mohamed INNOV/NET <[e-mail]>om>;
> > [e-mail]; [e-mail]
> > Cc : [e-mail]; [e-mail]; [e-mail]
> ;
> > [e-mail]; [e-mail]
> > 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, [e-mail] 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 <[e-mail]> De la part de [e-mail]
> > >> Envoyé : vendredi 3 décembre 2021 10:02
> > >> À : [e-mail]; [e-mail]
> > >> Cc : [e-mail]; [e-mail];
> > [e-mail];
> > >> [e-mail]; [e-mail]
> > >> 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;
> > >> 抄送人：[e-mail];sfc-
> > >> [e-mail];[e-mail];[e-mail];
> > >> 日 期 ：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
> > >> [e-mail]
> > >> 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.
>
>