Re: [sfc] Fwd: IETF WG state changed for draft-ietf-sfc-nsh-tlv

["Joel M. Halpern" <[e-mail]>]

Thank you Med.

I honestly do not remember what the URI was for.  If no one else speaks 
up, the obvious answer is to remove it.

The ingress node and port information is intended to support many use 
cases where that, rather than an or in addition to an abstract 
subscriber ID is needed to apply the SF behavior properly.  (Think about 
a firewall that would normally look at which port a packet came in on.)

Yours,
Joel

On 4/29/2021 11:54 AM, [e-mail] wrote:
> Hi Joel, all,
> 
> The same concerns that I raised back in 01/21 are still valid for this version. I'm resending the comments, fwiw.
> 
> ******
> 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 : sfc [mailto:[e-mail]] De la part de Joel Halpern
>> Envoyé : jeudi 29 avril 2021 17:40
>> À : [e-mail]
>> Objet : Re: [sfc] Fwd: IETF WG state changed for draft-ietf-sfc-nsh-
>> tlv
>>
>> Thank you Donald.  Working group members-- please -- we need comments
>> of support or objection.  reviews are even better.
>>
>> Yours,
>> Joel
>>
>> On 4/29/2021 11:07 AM, Donald Eastlake wrote:
>>> My apologies for taking a while but I do support publication with
>>> changes and I am in the process of doing a review which I hope to
>> post
>>> later today or tomorrow.
>>>
>>> Thanks,
>>> Donald
>>> ===============================
>>>    Donald E. Eastlake 3rd   [phone] (cell)
>>>    2386 Panoramic Circle, Apopka, FL 32703 USA [e-mail]
>>> <mailto:[e-mail]>
>>>
>>>
>>> On Thu, Apr 1, 2021 at 11:46 AM Joel M. Halpern
>> <[e-mail]
>>> <mailto:[e-mail]>> wrote:
>>>
>>>      As requested by the document editors, this starts WG last call
>> for the
>>>      TLV document.  Please speak up.
>>>
>>>      Thank you,
>>>      Joel
>>>
>>>      PS: And we would like a document shepherd for this.
>>>
>>>
>>>      -------- Forwarded Message --------
>>>      Subject: IETF WG state changed for draft-ietf-sfc-nsh-tlv
>>>      Resent-Date: Thu,  1 Apr 2021 08:40:19 -0700 (PDT)
>>>      Resent-From: [e-mail] <mailto:alias-
>> [e-mail]>
>>>      Resent-To: [e-mail]
>>>      <mailto:[e-mail]>,
>> [e-mail]
>>>      <mailto:[e-mail]>,
>>>      [e-mail] <mailto:[e-mail]>
>>>      Date: Thu, 01 Apr 2021 08:40:19 -0700
>>>      From: IETF Secretariat <[e-mail]
>>>      <mailto:[e-mail]>>
>>>      To: [e-mail]
>>>      <mailto:[e-mail]>, [e-mail]
>>>      <mailto:[e-mail]>
>>>
>>>
>>>      The IETF WG state of draft-ietf-sfc-nsh-tlv has been changed to
>> "In
>>>      WG Last
>>>      Call" from "WG Document" by Joel Halpern:
>>>
>>>      https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/
>>>      <https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/>
>>>
>>>      Comment:
>>>      This starts a two week last call for this document.  Please
>> speak
>>>      up.  We
>>>      need to see support for sending this to the IESG.  Silence is
>> not
>>>      consent.
>>>      The last call will end at the end of 16-April-2021.
>>>
>>>      Thank you,
>>>      Joel (and Jim)
>>>
>>>      _______________________________________________
>>>      sfc mailing list
>>>      [e-mail] <mailto:[e-mail]>
>>>      https://www.ietf.org/mailman/listinfo/sfc
>>>      <https://www.ietf.org/mailman/listinfo/sfc>
>>>
>>
>> _______________________________________________
>> 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.
> 
> _______________________________________________
> sfc mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sfc
>