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

[Martin Vigoureux <[e-mail]>]

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.
>