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

[[e-mail]]

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
------------------原始邮件------------------
发件人：[e-mail]
收件人：Martin Vigoureux;魏月华00019655;[e-mail];
抄送人：[e-mail];[e-mail];[e-mail];[e-mail];[e-mail];
日 期 ：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
> -----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.