Last Call Review of draft-ietf-mpls-sfl-framework-08
review-ietf-mpls-sfl-framework-08-tsvart-lc-aboba-2020-06-30-00

Subject: Transport Directorate review of draft-ietf-mpls-sfl-framework

Reviewer: Bernard Aboba
Review result: Ready with (Minor) Issues
Document: draft-ietf-mpls-sfl-framework-08
Reviewer: Bernard Aboba
Review Date: 2020-06-30
Intended Status: Informational

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

Summary:
        This document is ready for publication, but has some minor issues
        that could be addressed.

Comments:
        The document is short and clearly written.  While it references
        the requirements in RFC 8372, it does not refer to them, so it's
        hard to verify whether this document does address those
        requirements (and how).

        Also, this document doesn't cover data collection or SFL allocation,
        so there is quite a bit that is out of scope. This makes me wonder
        whether an implementation of this specification could interoperate
        with other implementations based solely on this specification. 

Major Issues:
        No major issues found 

Minor Issues:

Section 6 Privacy Considerations

Section 3 states: 

"  There are many possible additional actions such as
   the measurement of the number of received packets in a flow,
   triggering IPFIX inspection, triggering other types of Deep Packet
   Inspection, or identification of the packet source."

[BA] Based on the above statements, it would seem that this specification
has potential uses (e.g. DPI) that have inherent privacy implications. 
This seems to be worth mentioning.

   "Whilst the inclusion of the additional
   granularity does allow greater insight into the flow characteristics
   it does not specifically identify which node originated the packet
   other than by inspection of the network at the point of ingress, or
   inspection of the control protocol packets."

[BA] By definition, flow identities provide insight into flow characteristics.
By correlating the flow identity with persistent identifiers such as MAC
addresses, the flow identity can be linked to a device or user
without needing to inspect the network at the point of ingress or to
inspect control protocol packets. So there can be an incremental privacy
impact, even if the flow identifier does not itself identify a
user. 

Section 7 Security Considerations

"The issue noted in Section 6 is a security consideration."

[BA] I don't think that the privacy issues described in Section 6 need necessarily be referenced
in the security considerations section.  I think you can delete this sentence.