Hi Éric, Thank you very much for the review. Please find some response in line (marked as HS>). We'll publish the updated draft soon. Thanks!
Best regards, Haoyu -----Original Message----- From: Éric Vyncke via Datatracker <[email protected]> Sent: Friday, November 26, 2021 5:20 AM To: The IESG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; [email protected]; [email protected]; [email protected] Subject: Éric Vyncke's No Objection on draft-ietf-opsawg-ntf-10: (with COMMENT) Éric Vyncke has entered the following ballot position for draft-ietf-opsawg-ntf-10: No Objection 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%7C55cf9efa9b20491fb28708d9b0df7dca%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637735296220900165%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=SzTLwFyLAXFwT8X5P5sQN%2Bqsk%2FJ5P%2B9wQVy5e8VkiXg%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%7C55cf9efa9b20491fb28708d9b0df7dca%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637735296220900165%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=MOuvJ%2BgSbiyFGWw6qJuOhsL2FvpN87kC3NZ8BQwU4LQ%3D&reserved=0 ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Thank you for the work put into this document. All in all, this is a very good introduction document to telemetry but I am unsure whether it is a 'framework' (and this is a real concern of mine). Due to the amount of documents on the next IESG telecast agenda, I did not review the appendixes. Please find below some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Special thanks to Alexander Clemm for the shepherd's write-up about the WG consensus. Thanks also to Jean-Michel Combes for his Internet directorate review at: https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Freview-ietf-opsawg-ntf-10-intdir-telechat-combes-2021-11-24%2F&data=04%7C01%7Chaoyu.song%40futurewei.com%7C55cf9efa9b20491fb28708d9b0df7dca%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637735296220900165%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=fxvlOsv%2Bpe5Ipxhc8u5fRKnBuE1SOQTmPK2QBReipC0%3D&reserved=0 I believe that Jean-Michel spotted a serious issue in the security section but I trust the Security Area Directors on this specific topic and will not raise a block DISCUSS on this point especially as Haoyu Song has taken some actions. I hope that this helps to improve the document, Regards, -éric As a non-English speaker, the document title is a little ambiguous at first sight: is it about telemetry about network data or about using the network to get some telemetry ? Unsure whether this ambiguity can be removed. HS> The document is about telemetry on network data. The ambiguity should be cleared by the abstract and introduction. BTW, I like the sections on use cases and challenges but I am ambivalent whether they are useful in this document. HS> We introduce the use cases and challenges as the motivation to the work. A lot of the concepts in this framework could be used for other applications beyond network layer telemetry. Was this extension considered by the authors ? HS> We limit our scope to network layer in this document. There are several informative references to IRTF & IETF drafts, which is OK of course but those drafts may never be published. Perhaps, is it premature to publish this document ? HS> Some of such references (mostly in appendix) refer to specific techniques. Even if they will not become standard in the future, the technique will still be useful. -- Section 2 -- Suggest to rely on https://nam11.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.rfc-editor.org%2Fmaterials%2Fabbrev.expansion.txt&data=04%7C01%7Chaoyu.song%40futurewei.com%7C55cf9efa9b20491fb28708d9b0df7dca%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637735296220900165%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&sdata=eD5qDhL7%2B%2FmW%2FTBIoAeeg98cFF2AjGK9zHtD1anFyuc%3D&reserved=0 to avoid redefining well-known terms as JSON or MIB. HS> Thank you for the suggestion. We don't redefine the terms but want to spell out the terms and provide a little more information just in case the readers are not familiar with them. -- Section 3 -- No need to reply but I am unsure whether the paragraph about SDN, AN, ... brings any value to this document. -- Section 3.1 -- Should there be some words about whether actual packet content is part of telemetry ? HS> Packet content is related to user privacy. In our latest revision we have made it clear that the user privacy should be protected. The architecture we proposed will not concern about packet content. We'll clarify this point in the text. -- Section 3.2 -- Should there be a mention of "big data" again when enumerating the 4 Vs ? HS> Add "the attributes of big data" to the text -- Section 3.3 -- Is it the forwarding chip that generate, package, and send the telemetry as hinted in the first bullet ? I would guess that the chip indeed collects the data but it is up to another component to do rest. HS> Many forwarding chips can directly generate and send telemetry data. Please add a definition/reference for "sFlow". HS> Done -- Section 3.4 -- Should there also be a mention of common naming/ID if data needs to be merged among different sources ? I.e., having common keys with the same format or at least having some equivalence. HS> Add "based on common naming/ID" to the text "In-network customisation" seems partly contradictory with unified models or did I misread this part ? HS> The data itself can be customized but the models and interfaces are common. For an uneducated reader (like myself), I wonder whether actual packet content is included in "The data originated from the data plane forwarding chips" HS> This is clarified as earlier suggested. -- Section 3.5 -- In "Efficient data fusion is critical for applications to reduce the overall quantity of data", is it about "fusion" or "aggregation" ? HS> Change to "aggregation" -- Section 4.1 -- In figure 2, what is 'template' ? This does not seem a well-defined term, suggest to remove it. HS> Done Also in figure 2, suggest replace "HTTP" by "HTTPS" HS> Change to "HTTP(S)" to cover both. In figure 2, what is the meaning of "plain" for data encoding ? HS> Change to "plain text" for clarification. -- Section 4.1.3 -- Could the "quality" in the first paragraph be described as it is rather vague? HS> Different applications have their own definition of "quality", and therefore specific challenges. Later in this section "The data should be structured and labeled", what is meant by 'labeled' ? And later in the same §, I am unsure how to understand "data types"... (as I read "data types" as float vs. integer) or is it simply "data" HS> The data label can help the data to be identified and used by applications. For example, when and where the data is collected. The "data types" here means the different types of telemetry data which should not be confused with the data type in programming languages. Suggest to make the taxonomy part a subsection. HS> Done Is there a reason why "AM" is not expanded in "AM [RFC8321]" ? HS> The abbreviation has been introduced in the glossary. In "Big Data sources that analyse streams of information, such as Twitter messages", I am afraid that I fail to understand how sources can analyse data. HS> add "can" to the text. It means the data owner can analyze the data. -- Section 4.2 -- I fail to understand why formatting is part of "Data Generation and Processing" and not of "Data Encoding and Export". HS> "Formatting" is a part of the data generation and processing and "encoding" is a part of data export. For example, IOAM will collect data and organize/order (i.e., format) the data based on the instruction. When exporting the data, "encoding" is needed to comply with the protocol used. -- Section 4.4 -- Please excuse my lack of knowledge in this domain, but I have hard time to understand how MIB & YANG modules can help in data generation and processing in figure 5. Should there be some additional clarifications ? Again, possibly because I am not an expert in this field. HS> MIB/YANG can be used to specify what data to be collected so to guide the generation and processing of the desired data from the raw sources. -- Section 5 -- It is unclear for me whether the 4 stages (BTW why starting at stage 0 rather than stage 1 ?) are about telemetry (as a means) or about use cases. HS> It's about escalated application requirements to a telemetry system. == NITS == -- Section 2 -- Missing ':' after YANG ECA HS> Fixed. _______________________________________________ OPSAWG mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsawg
