[sfc] Warren Kumari's No Objection on draft-ietf-sfc-nsh-integrity-06: (with COMMENT)

[Warren Kumari via Datatracker <[e-mail]>]

Warren Kumari has entered the following ballot position for
draft-ietf-sfc-nsh-integrity-06: 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 DISCUSS and COMMENT positions.


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



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

I support Roman and Eric's DISCUSS points.

I also found:
"Note that some transport encapsulations (e.g., IPsec) only provide hop-by-hop
security between two SFC data plane elements (e.g., two Service Function
Forwarders (SFFs), SFF to SF) and do not provide SF-to-SF security of NSH
metadata.  For example, if IPsec is used, SFFs or SFs within a Service Function
Path (SFP) that are not authorized to access the privacy-sensitive metadata
will have access to the metadata." to be incredibly hard to read/parse. I think
that my confusion comes in around the "that are not authorized to access the
privacy-sensitive metadata will have access to the metadata." test, and thing
that the last sentence should be rewritten to start with "Because IPsec does
not... it exposes privacy-sensitive metadata to..."

Also, thanks to Jürgen Schönwälder for the OpsDir review, and to the authors
for addressing the comments.