Subject: [sfc] Benjamin Kaduk's No Objection on draft-ietf-sfc-serviceid-header-13: (with COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Thu, 10 Dec 2020 06:42:01 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-sfc-serviceid-header-13: No Objection

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/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-sfc-serviceid-header/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

This is just an observation, since we don't seem to have talked about it
the first time around, but this document seems to leave a lot of details
up to the deployment (or implementation?); I wonder how much thought
went into targeting Proposed Standard vs Informational.

Section 3

   per-subscriber policies.  The assessment whether a method for
   defining a subscriber identifier provides the required functionality
   and that it is compliant with SFs capabilities with the intended
   performance levels is deployment specific.

Some nits here; I propose

NEW:
The assessment of whether a method for defining a subscriber identifier
provides the required functionality and whether it is compatible with the
capabilities of the SFs to the intended performance level, is deployment
specific.

   if the NSH-aware SF is instructed to do so.  For example, an SF that
   expects a subscriber identifier generated from an internal IP address
   will discard Subscriber Identifier Context Headers conveying
   identifiers generated from Mobile Subscriber ISDN Number (MSISDN),
   International Mobile Subscriber Identity (IMSI), or malformed IP
   addresses.

It feels a bit odd for a PS document to talk about various types of
identifier like this when any type indicator would be part of the
internal site-specific structure of the opaque data.

Section 4

   The Performance Policy Identifier allows for the distributed
   enforcement of a per-service policy such as a service function path
   to only include specific SFs instances (e.g., SFs located within the
   same DC or those that are exposing the shortest delay from an SFF).

nit: there looks to be a grammar issue here; adding "requiring" before
"a service function path to only include" would probably fix it, but
there are many other options.

   The default behavior of intermediary NSH-aware nodes have to preserve
   such Context Headers (i.e., the information can be passed to next hop
   NSH-aware nodes), but local policy may require an intermediary NSH-
   aware node to strip one after processing it.

Please align the wording here with the (quite well done) version in
the previous section (e.g., s/have to preserve/is to preserve/).

   Nodes that are involved in an SFC-enabled domain are assumed to be
   trusted (Section 1.1 of [RFC8300]).  Means to check that only
   authorized nodes are solicited when a packet is crossing an SFC-
   enabled domain are out of scope of this document.

Sorry for repeating this from my earlier comments, but I would suggest
to s/solicited/traversed/ here.

                                                                If
   encryption is not enabled, the use of non persistent identifiers as
   well as the removal of the Subscriber Identifier Context Headers from
   the NSH by the last SF making use of such headers soften this issue
   (see "data minimization" discussed in Section 3 of [RFC8165]).

I would double-check the location of the "if encryption is not enabled"
clause, here -- use of encryption would be a different partial
mitigation, but the indicated concerns could still apply in an encrypted
setting, just in a different way (depending on which nodes had access to
the decrypted results, etc.).

   If no secure transport encapsulation is enabled, the use of trivial
   subscriber identifier structures together with the presence of
   specific SFs in a service function chain may reveal sensitive
   information to every on-path device (but also to teams managing these
   devices).  [...]

I would suggest promoting the parenthetical to a full clause (offset by
a comma) and to s/but/and/; the consideration seems of similar import to
the exposure to devices.

---

From: <[email-masked]>
Date: Fri, 11 Dec 2020 05:57:45 +0000

Hi Ben, 

Thank you for checking the new version. 

Please see inline for one comment. 

Cheers,
Med

> -----Message d'origine-----
> De : Benjamin Kaduk via Datatracker [mailto:[email-masked]]
> Envoyé : jeudi 10 décembre 2020 15:42
> À : The IESG <[email-masked]>
> Cc : [email-masked]; [email-masked];
> [email-masked]; Greg Mirsky <[email-masked]>;
> [email-masked]
> Objet : Benjamin Kaduk's No Objection on draft-ietf-sfc-serviceid-
> header-13: (with COMMENT)
> 
> 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.)
> 
> 
> This is just an observation, since we don't seem to have talked
> about it the first time around, but this document seems to leave a
> lot of details up to the deployment (or implementation?); I wonder
> how much thought went into targeting Proposed Standard vs
> Informational.
> 
> 

The details that are not called here are those that are typically handled by the control plane (which is out of scope). Similar statements can be found in RFC8300. 

Please note that as per 9.1.5 of RFC8300, the following is needed to register new codes: 

==
   The type values are assigned via Standards Action [RFC8126].
==

We will take care of all your other comments. 

Thank you again for your careful and valuable review.

_________________________________________________________________________________________________________________________

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: <[email-masked]>
Date: Fri, 11 Dec 2020 19:16:31 +0000

Hi Ben and all other reviewers,
Thanks for your very much appreciated help and suggestions.
We have considered your comments hopefully satisfactorily in the just posted updated version below.
Please check whether you are fine with this.
Thanks again and have a nice weekend!
Best Regards
Dirk 

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sfc-serviceid-header/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sfc-serviceid-header-14
https://datatracker.ietf.org/doc/html/draft-ietf-sfc-serviceid-header-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-serviceid-header-14

-----Original Message-----
From: [email-masked] <[email-masked]> 
Sent: Freitag, 11. Dezember 2020 06:58
To: Benjamin Kaduk <[email-masked]>; The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Greg Mirsky <[email-masked]>
Subject: RE: Benjamin Kaduk's No Objection on draft-ietf-sfc-serviceid-header-13: (with COMMENT)

Hi Ben, 

Cheers,
Med

> De : Benjamin Kaduk via Datatracker [mailto:[email-masked]] Envoyé : 
> jeudi 10 décembre 2020 15:42 À : The IESG <[email-masked]> Cc : 
> [email-masked]; [email-masked]; 
> [email-masked] Objet : Benjamin Kaduk's No Objection on 
> draft-ietf-sfc-serviceid-
> email addresses included in the To and CC lines. (Feel free to cut 
> this introductory paragraph, however.)
> 
> 
> This is just an observation, since we don't seem to have talked about 
> it the first time around, but this document seems to leave a lot of 
> details up to the deployment (or implementation?); I wonder how much 
> thought went into targeting Proposed Standard vs Informational.
> 
> 

==

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.

Subject: [sfc] I-D Action: draft-ietf-sfc-serviceid-header-14.txt
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Date: Fri, 11 Dec 2020 19:08:33 +0000
List-Id: Network Service Chaining <sfc.ietf.org>

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Service Function Chaining WG of the IETF.

        Title           : Service Function Chaining: Subscriber and Performance Policy Identification Variable-Length Network Service Header (NSH) Context Headers
        Authors         : Behcet Sarikaya
                          Dirk von Hugo
                          Mohamed Boucadair
	Filename        : draft-ietf-sfc-serviceid-header-14.txt
	Pages           : 13
	Date            : 2020-12-11

Abstract:
   This document defines two Variable-Length Context Headers that can be
   carried in the Network Service Header: the Subscriber and Performance
   Policy Identifiers.  These Context Headers are used to inform Service
   Functions of subscriber- and performance-related information for the
   sake of policy enforcement and appropriate service function chaining
   operations.  The structure of each Context Header, and their use and
   processing by NSH-aware nodes, are described.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sfc-serviceid-header/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sfc-serviceid-header-14
https://datatracker.ietf.org/doc/html/draft-ietf-sfc-serviceid-header-14

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sfc-serviceid-header-14

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
sfc mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sfc