Reviewer: Bernard Aboba
Review result: Ready with Issues
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@xxxxxxxx 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.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
