[Tsv-art] Tsvart last call review of draft-ietf-mpls-sfl-framework-08
Bernard Aboba via Datatracker <email@example.com> Wed, 01 July 2020 00:11 UTC
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AE803A0803; Tue, 30 Jun 2020 17:11:26 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
From: Bernard Aboba via Datatracker <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.org, email@example.com
Reply-To: Bernard Aboba <firstname.lastname@example.org>
Date: Tue, 30 Jun 2020 17:11:26 -0700
Subject: [Tsv-art] Tsvart last call review of draft-ietf-mpls-sfl-framework-08
List-Id: Transport Area Review Team <tsv-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsv-art>, <mailto:email@example.com?subject=unsubscribe>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsv-art>, <mailto:firstname.lastname@example.org?subject=subscribe>
X-List-Received-Date: Wed, 01 Jul 2020 00:11:26 -0000
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 email@example.com 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.
- [Tsv-art] Tsvart last call review of draft-ietf-m… Bernard Aboba via Datatracker
- Re: [Tsv-art] [Last-Call] Tsvart last call review… Stewart Bryant