Hi Adrian, Thank you very much for the comments. I'll try to address all your comments in the new revisions. Given the time and bandwidth, I may leave some parts (e.g., security concern) to future revisions.
Yes, gRPC is a recursive acronym and "g" doesn't mean google although we all know where it comes from ;) Haoyu -----Original Message----- From: Adrian Farrel [mailto:adr...@olddog.co.uk] Sent: Tuesday, October 16, 2018 12:40 PM To: opsawg@ietf.org Cc: draft-song-opsawg-...@ietf.org Subject: Thoughts on draft-song-opsawg-ntf Hi authors and working group. I just had cause to read this document and thought I would share my comments on the list. The draft appears as -00, but it is a little more mature than that implies because it replaces draft-song-ntf-02. I think a foundation document on telemetry would be useful for the IETF, and the OPSAWG may be a good place to discuss and progress that work. This document seems like a reasonable starting point for that work although there will inevitably need to be some additions and modifications. Actually, I found this document pretty complete. My comments are a combination of substantive issues and nits. Hope this helps. Regards, Adrian == Discussion points == In 1.4 you have Since SNMP is poll-based, it incurs low data rate and high processing overhead. I don't think this is quite fair on SNMP. The protocol also includes Notifications allowing information to be output by a device. Your main point about low data rates and high overhead, still stand, but with a different slant. --- Although you talk about IPFIX quite a bit later in the document, I think that, as part of the scene setting, you might include a paragraph about it early in 1.4. --- The text after Figure 1 did not completely convince me of the need for interaction between the three "telemetry planes". Perhaps you could expand the examples and discussion to highlight/clarify this? --- Clearly you are going to have to write some Security Considerations. There is quite a lot to say about what is a layered security model with plenty of attack vectors, and substantial risks as the telemetry data can result in operational changes that could harm data delivery and even bring the network down. Furthermore, examination of telemetry data can reveal weaknesses in the network. == Nits == The authors will need to reduce the number of front page names to 5. Move the others to a Contributors section. Might as well do this sooner rather than later. --- Abstract This document suggests the necessity of an architectural framework for network telemetry in order to meet the current and future network operation requirements. Suggest you change this a little because you actually provide the framework. How about... This document provides an architectural framework for network telemetry in order to meet the current and future network operation requirements. --- You need to write an Introduction section and present it as Section 1. You don't need a lot of text: start with the Abstract and expand it a little. --- The Requirements Language text should move to a new Section 1.1 --- You should expand the abbreviations on first use. I see: AI ARCA ML OAM SDN --- A couple of the terms in 1.3 are confusing. > gNMI: gPRC Network Management Interface Should that be gRPC? > gRPC: gRPC Remote Procedure Call This seems circular. --- Not sure that RFC 1157 is the best reference for SNMP in section 1.4. How about 3416? --- Figure 3 Does gPRC mean gRPC? _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg
