[sfc] Alissa Cooper's Abstain on draft-ietf-sfc-serviceid-header-12: (with COMMENT)

[Alissa Cooper via Datatracker <[e-mail]>]

Alissa Cooper has entered the following ballot position for
draft-ietf-sfc-serviceid-header-12: Abstain

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

I support Benjamin's DISCUSS.

The privacy properties of the mechanism specified in this document do not
comport with the recommendations in RFC 8165 or RFC 6973. The document makes no
normative recommendations to minimize the identifiability or linkability of the
information in the context header. It specifies no normative transport or
object encryption, which RFC 8300 conditionally requires (as does RFC 8371 for
similar identifiers). (Furthermore, although this documents says the context
header should only be used within an administrative domain, RFC 8300 allows for
NSH to be used across administrative boundaries if I understand correctly.) The
document does not suggest best practices for minimizing the persistence or
uniqueness of the identifiers conveyed when circumstances allow it. As Ben
noted, many functions performed by SFs don't need to be aware of actual
subscriber identifiers that have some other purpose in the network (IP address,
mobile network identifiers, etc.).

For other protocols that convey unique subscriber identifiers, even protocols
that are not end-to-end like DHCP, the IETF has specified detailed guidance to
minimize the privacy impact of exposing these identifiers. See, e.g., RFC 7844
and RFC 8064/7721. That level of analysis and guidance is what I would expect
for this specification. I suspect that is an unpopular view, though, so I'm
abstaining.