Hi Benjamin, Thank you very much for the review and suggestions. We'll update the document accordingly. Please see below for some inline response. Thanks!
Best regards, Haoyu -----Original Message----- From: Benjamin Kaduk via Datatracker <[email protected]> Sent: Thursday, December 2, 2021 3:55 PM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Subject: Benjamin Kaduk's Abstain on draft-ietf-opsawg-ntf-12: (with COMMENT) Benjamin Kaduk has entered the following ballot position for draft-ietf-opsawg-ntf-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://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fblog%2Fhandling-iesg-ballot-positions%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cc7879ca6fb9f4ce0e84608d9b5ef1794%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637740860777850482%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=ZE%2FsHakG%2FKHLe%2BggRd20khc%2F09JIUwv6EQb9jwtkm%2Bw%3D&reserved=0 for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-opsawg-ntf%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7Cc7879ca6fb9f4ce0e84608d9b5ef1794%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637740860777850482%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=U12enw6njHNOFbWicKmSYIH8bzUC70jIQrlHKGMbdY8%3D&reserved=0 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thanks for making the applicability statement more prominent in the -12. I think the document paints an exciting picture of a new mindset in which to frame discussion of network monitoring and management (even if it does stray too far into marketing language for my taste in places). It doesn't do quite as well at convincing me that an entirely new technology suite is merited (as opposed to just extending existing protocols to align with the new mindset), but I am willing to admit the possibility that the new technology suite is the right approach. That said, I have strong misgivings about the current state of the document, mostly relating to privacy considerations and the risk of pervasive monitoring, so I am balloting Abstain. While we do clearly say to not analyze individual users, we also have guidance (e.g., in §2.1) that only says "no user packet content should be collected". However, packet contents are not the only things that can be a threat to user privacy, and we've seen numerous instances where just metadata about user flows are sufficient to make strong conclusions about user behavior that impact user privacy. But if we try to strengthen the requirement to be not collecting any data about user packets, the utility of the system decreases greatly, and I don't see a clear way to reconcile the impasse. (There are also a few lingering references to "user flows", "user packets", "user traffic", etc. in the main body text, especially in §2.3. I'm not convinced that all of the instanaces of these phrases are compatible with the applicability statement.) Furthermore, the applicability statement seems to be a case of wishful thinking. I do not see any proposals for technical measures to enforce that data is not collected from networks where endpoints represent users, and I also don't see any mechansisms to disincentivize such use in favor of other, more privacy-friendly, alternatives. So even if we consider such usage of the network telemetry framework to be an abuse case rather than a use case, if we are going to honestly document the implications of the technology, I can't escape the conclusion that we need to consider these scenarios in our assessment of whether we are defining the right technology. <HS> In this informational document, we only provide the high level guidelines. Given many related technologies and standards have been developed, we expect these technologies and standards can address the privacy issues. The detailed mechanism is out of the scope of this document. Though I am balloting Abstain, I will also some specific comments on the document that might help improve it, even if I may not be completely happy with the resulting document (for the reasons described above). It's pretty surprising to see a document that mentions autonomic networking and aims to achieve self-managing networks make no reference at all to the IETF ANIMA WG or its outputs, a group that is specifically chartered to produce protocols and procedures for automated network management. In particular, it's my understanding that ANMIA has had very little traction with network Intent thus far, and this document references IRTF documents in many places (both for Intent and other things). Are we confident that these concepts are ready to move from the IRTF into the engineering world? <HS> We'll add reference to the IETF ANIMA WG as an example for the effort of autonomic networking. Section 1 Network visibility is the ability of management tools to see the state and behavior of a network, which is essential for successful In the TLS WG we've sometimes seen participants use the term "visibility" to include the plaintext of encrypted data flows. While I have no reason to believe that that's a universally held understanding of the term, I mention it only to ask that clarification be provided if the intent of the term here is to include such decryption capabilities. If the intent is only to observe the normal visible wire image of the protocol, I don't see particular need for clarification. <HS> Your latter understanding is right and it's from the network operator's perspective to understand what's going on in their networks. Section 2 forward. When a network's endpoints do not represent individual users (e.g. in industrial, datacenter, and infrastructure contexts), network operations can often benefit from large-scale data collection without breaching user privacy. In the vein of my toplevel remarks, I don't think that just "a network's endpoints do not represent individual users" is sufficient to ensure that large-scale data collection does not breach user privacy. It covers first-order effects, I think, but we've seen a lot of research indicating that second- and higher-order analyses can still extract information that reduces user privacy. <HS> If network operators want to protect user privacy, they can achieve it with many means, and otherwise they can also easily violate it. We just claim a high level principle and don't provide detailed mechanisms and policies. The issue is out of scope of this document. Section 2.1 To preserve the privacy of end-users, no user packet content should be collected. Specifically, the data objects generated, exported, and collected by a network telemetry application should not include any packet payload from traffic associated with end-users systems. Also in the vein of my toplevel remarks, while "do not include user traffic payload" is a minimum requirement, and I'm happy to see it stated clearly, it in and of itself is not sufficient to fully protect end-user privacy. Section 2.2 visibility into networks. The ultimate goal is to achieve the security with no, or only minimal, human intervention. It's easy to achieve security without human intervention, if you're willing to accept a high false positive rate and denial of legitimate traffic. Should we say something about tempering the security goal with a need for not disrupting legitimate traffic flows? <HS> we'll add "and without needing to disrupt legitimate traffic flows." for completeness. Section 2.3 Conventional OAM only covers a narrow range of data (e.g., SNMP only handles data from the Management Information Base (MIB)). This argument feels a bit weak given that anyone with an OID arc (that is, just about anyone) can add to the MIB. <HS> We agree that everything is extensible if we decide to do so. Here we just state the past status. Section 2.4 Network telemetry has emerged as a mainstream technical term to refer It's a little surprising to see network telemetry called a "mainstream" term here, when up in §1 we said that it lacks an unambiguous definition. <HS> It's used everywhere already in networking industry but people have different understanding on it. That's part of the reason we have this document. * Model-based: The telemetry data is modeled in advance which allows applications to configure and consume data with ease. [...] * In-Network Customization: The data that is generated can be customized in network at run-time to cater to the specific need of applications. This needs the support of a programmable data plane which allows probes with custom functions to be deployed at flexible locations. I'm having a hard time seeing how data that's customized in-network at runtime would be compatible with being modeled in advance. Maybe the disclaimer about "not expected to be held by every specific technique" is intended to apply here, but it might be worth acknowledging the tradeoff. <HS> Due to the diversity of the techniques, the disclaimer applies to most of the characteristics. * In-band Data Collection: In addition to the passive and active data collection approaches, the new hybrid approach allows to directly collect data for any target flow on its entire forwarding path [I-D.song-opsawg-ifit-framework]. I'm pretty skeptical that the functionality that's claimed here (and in the referenced draft) can be achieved while complying with the existing requirements from current IETF RFCs. I recognize that this is under the "an ideal [solution] may also have" heading, but it still feels a little premature to include. <HS> Related techniques are already RFC (e.g., Alternate Marking) or in the RFC queue (e.g., IOAM). Section 3.1 I'm having a really hard time seeing how figure 2 is internally consistent if it lists "plain text" as the only option for data encoding of data modelled using YANG (e.g., in the forwarding plane column). <HS> In the figure we only list some representative elements. If there are other good examples, we can also include them. Section 3.1.1 network statistics and state data. The management plane includes many protocols, including some that are considered "legacy", such as SNMP and syslog. Regardless the protocol, management plane telemetry It's not clear that we gain any real value from labeling SNMP and syslog as "legacy". Perhaps we should just skip the examples and avoid debate on what is or isn't legacy (leaving each person to hold their own opinion on that question)? <HS> Suggestion adopted. Section 3.1.2 Then in case of an unusually poor UE KPI or a service disconnection, it is non-trivial to delimit and pinpoint the issue in the responsible protocol layer (e.g., the Transport Layer or the Network Layer), the responsible protocol (e.g., ISIS or BGP at the Network Layer), and finally the responsible device(s) with I don't really follow the example of IS-IS or BGP "at the Network Layer" -- in what sense do we use "network layer" here? <HS> It is the conventional sense of network layer. Section 3.3 I don't really understand the logic behind the direction of arrowheads in Figure 4. I'd be more inclined to just remove the figure than add more explanatory text, though, as the relationships don't seem terribly key to the core purpose of this document. <HS> The arrow means "derived from" or "built with" Section 5 * Authentication and signing of telemetry data to make data more trustworthy. Signing is typically treated as a way to provide authentication; it might make more sense to discuss "authentication and integrity protection" in terms of the typical security properties we consider. <HS> Suggestion adopted. NITS Section 1 operations. Based on the distinction of modules and function components, we can map the existing and emerging techniques and It would be "distinction between" or "definition of", I think. protocols into the framework. The framework can also simplify the designing, maintaining, and understanding a network telemetry system. The "the" leading into "designing, maintaining, and understanding" should be removed. The purpose of the framework and taxonomy is to set a common ground for the collection of related work and provide guidance for future technique and standard developments. To the best of our knowledge, s/technique/techniques/ Section 1.2 AI: Artificial Intelligence. In network domain, AI refers to the machine-learning based technologies for automated network operation and other tasks. "the network domain" SNMP: Simple Network Management Protocol. Version 1, 2, and 3 are specified in [RFC1157], [RFC3416], and [RFC3414], respectively. RFC 3411 might be a better reference for SNMPv3, as it's the architecture doc (rather than the user-based security model doc). Section 2 It is conceivable that an autonomic network [RFC7575] is the logical next step for network evolution following Software Defined Network I think "Software Defined Networking" would fit better in this situation. protocols are insufficient for these use cases. The discussion underlines the need of new methods, techniques, and protocols, as well as the extensions of existing ones, which we assign under the s/need of/need for/ Section 2.2 Given increasingly sophisticated attack vector coupled with "vectors" plural visibility into networks. The ultimate goal is to achieve the security with no, or only minimal, human intervention. s/the// visibility that is provided through network telemetry data. Any violation must be notified immediately, potentially resulting in updates to how the policy or intent is applied in the network to The subject of the verb "notified" is the target of the notification, not the thing that the notification is about. So "reported" might fit better here. operators need to evaluate how they can deliver the services that can meet the SLA based on realtime network telemetry data, including data from network measurements. s/deliver the services/deliver services/ Section 2.3 * Comprehensive data is needed from packet processing engines to traffic manager, from line cards to main control board, from user flows to control protocol packets, from device configurations to operations, and from physical layer to application layer. It's possible to read this as a set of "from A to B" relations where A is sending data to B". I think that's not the intent, and this is just intending to show a broad spread of scenarios across many different axes; if that's the case, I'd suggest "... needed, ranging from" * The conventional passive measurement techniques can either consume excessive network resources and render excessive redundant data, Something seems awry around "render excessive redundant data", to the extent that I can't extrct meaning and propose an alternative. Section 2.4 overall network automation needs. Efforts are made to normalize the data representation and unify the protocols, so to simplify data analysis and provide integrated analysis across heterogeneous "so as to" Section 2.5 network with a low data sampling rate. Only when issues arise or critical trends emerge should telemetry data source be modified and telemetry data rates boosted as needed. I think we need ""the telemetry data source". Section 3.1.2 * An example of the control plane telemetry is the BGP monitoring protocol (BMP), it is currently used for monitoring the BGP routes I'd end the sentence at this comma to avoid a comma splice. Section 3.2 responsible for configuring the desired data that might not be directly available form data sources. The subscription data can s/form/from/ Section 5 * Protocol transport used telemetry data and inherent security capabilities; There seems to be a word or two missing here, maybe "used for" and "its inherent". Section A.3.6 Various data planes raises unique OAM requirements. IETF has s/raises/raise/ <HS> Thank you very much for catching the nits! _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
