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

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 1 Apr 2021 11:45:33 -0400

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: [email-masked]
Resent-To: [email-masked], [email-masked], 
[email-masked]
Date: Thu, 01 Apr 2021 08:40:19 -0700
From: IETF Secretariat <[email-masked]>
To: [email-masked], [email-masked]

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/

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)

---

From: Joel Halpern <[email-masked]>
Date: Thu, 29 Apr 2021 11:39:35 -0400

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   +1-508-333-2270 (cell)
>   2386 Panoramic Circle, Apopka, FL 32703 USA
> [email-masked] <mailto:[email-masked]>
> 
> 
> On Thu, Apr 1, 2021 at 11:46 AM Joel M. Halpern <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     Resent-From: [email-masked] <mailto:[email-masked]>
>     Resent-To: [email-masked]
>     <mailto:[email-masked]>, [email-masked]
>     <mailto:[email-masked]>,
>     [email-masked] <mailto:[email-masked]>
>     From: IETF Secretariat <[email-masked]
>     <mailto:[email-masked]>>
>     To: [email-masked]
>     <mailto:[email-masked]>, [email-masked]
>     <mailto:[email-masked]>
> 
> 
>     <https://datatracker.ietf.org/doc/draft-ietf-sfc-nsh-tlv/>
> 
>     Comment:
>     _______________________________________________
>     sfc mailing list
>     [email-masked] <mailto:[email-masked]>
>     https://www.ietf.org/mailman/listinfo/sfc
>     <https://www.ietf.org/mailman/listinfo/sfc>
>

---

From: <[email-masked]>
Date: Thu, 29 Apr 2021 15:54:49 +0000

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:[email-masked]] De la part de Joel Halpern
> Envoyé : jeudi 29 avril 2021 17:40
> À : [email-masked]
> 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
> 
> >   2386 Panoramic Circle, Apopka, FL 32703 USA [email-masked]
> > <mailto:[email-masked]>
> >
> >
> >     The IETF WG state of draft-ietf-sfc-nsh-tlv has been changed to
> "In
> >     WG Last
> >     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.
> [email-masked]

_________________________________________________________________________________________________________________________

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.

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 29 Apr 2021 12:29:15 -0400

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