Re: [sfc] Submission of draft-ietf-sfc-nsh-tlv-04.txt

Thank you.  I look forward to the responses from the authors.

Yours,
Joel

On 1/7/2021 11:55 AM, mohamed.boucadair@orange.com wrote:
> Re-,
> 
> I would be more than happy to provide text but the issue is that I don't know what is the intent/purpose of many of these TLVs.
> 
> Consider for example this one:
> 
> ==
> 4.7.  Universal Resource Identifier
> 
> [[removing the figure]]
> 
>     where
> 
>        URI (Universal Resource Identifier) Type is four bits-long field
>        that specifies the format of the URI field.  This document defines
>        the following values for the URI Type field:
> 
>        *  0x1: URI in standard string format as defined in [RFC3986].
> 
>        *  0x2: URI represented in a compacted hash format.
> ==
> 
> I fail to see what this URI is for and how it can be consumed by upstream SFs.
> 
> The same applies for Ingress Network Node Information and Ingress Network Source Interface. Not clear to me how supplying this information will be useful for upstream SFs.
> 
> Likewise, no clear what is the difference between the Tenant ID in Section 4.2 and 4.3. Why a tenant type is needed in 4.3, but not 4.2.
> 
> The POLICY_ID and Tenant ID are likely to trigger similar discussion (at least by the IESG) as what is documented for Performance Policy Identification and Subscriber ID in draft-ietf-sfc-serviceid-header. The authors may grab whatever text recorded there, as appropriate.
> 
> Cheers,
> Med
> 
>> -----Message d'origine-----
>> De : Joel M. Halpern [mailto:jmh@joelhalpern.com]
>> Envoyé : jeudi 7 janvier 2021 17:03
>> À : BOUCADAIR Mohamed TGI/OLN <mohamed.boucadair@orange.com>;
>> wei.yuehua@zte.com.cn; sfc@ietf.org
>> Objet : Re: [sfc] Submission of draft-ietf-sfc-nsh-tlv-04.txt
>>
>> Med, thank you for noting the redundant assignment.
>>
>> Presuming for discussion that more descriptive text would be helpful
>> (that is very often true of many drafts) it seems difficult to ask
>> tha authors to provide that since they have written what they think
>> is needed.
>>
>> Asking you to provide all the text seems a big ask.  Can you at
>> least identify which items and which aspects of those items need
>> more description?
>>
>> Thank you,
>> Joel
>>
>> On 1/7/2021 10:44 AM, mohamed.boucadair@orange.com wrote:
>>> Hi Wei,
>>>
>>> Thank you for sharing this updated version.
>>>
>>> One quick comment: Please remove this line from Section 7 as that
>>> value is already assigned to the service identifier TLV.
>>>
>>> | 0x00  |             Reserved             | This document |
>>>
>>> I still do think that more text is needed to understand the usage
>> of
>>> the various attributes.
>>>
>>> Cheers,
>>>
>>> Med
>>>
>>> *De :*sfc [mailto:sfc-bounces@ietf.org] *De la part de*
>>> wei.yuehua@zte.com.cn *Envoyé :* mardi 5 janvier 2021 03:29 *À :*
>>> sfc@ietf.org *Objet :* [sfc] Submission of
>>> draft-ietf-sfc-nsh-tlv-04.txt
>>>
>>> Dear chairs and SFCers，
>>>
>>> I uploaded ver04 of
>>> “Network Service Header Metadata Type 2 Variable-
>> Length Context Headers”
>>> draft.
>>>
>>> I updated the draft according to the comments received from the
>> SFC
>>> mailing list.
>>>
>>> Your comments are always welcome and helpful.
>>>
>>> And I would like to ask the WG for the consideration of the WGLC.
>>>
>>> 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.
> 
> _______________________________________________
> sfc mailing list
> sfc@ietf.org
> https://www.ietf.org/mailman/listinfo/sfc
> 