Subject: [OPSAWG] Éric Vyncke's No Objection on draft-ietf-opsawg-ntf-10: (with COMMENT)

From: Éric Vyncke via Datatracker <[email-masked]>
Date: Fri, 26 Nov 2021 05:20:17 -0800

É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://www.ietf.org/blog/handling-iesg-ballot-positions/
for more information about how to handle DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-ntf/

----------------------------------------------------------------------
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://datatracker.ietf.org/doc/review-ietf-opsawg-ntf-10-intdir-telechat-combes-2021-11-24/

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.

BTW, I like the sections on use cases and challenges but I am ambivalent
whether they are useful in this document.

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 ?

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 ?

-- Section 2 --
Suggest to rely on https://www.rfc-editor.org/materials/abbrev.expansion.txt to
avoid redefining well-known terms as JSON or MIB.

-- 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 ?

-- Section 3.2 --
Should there be a mention of "big data" again when enumerating the 4 Vs ?

-- 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.

Please add a definition/reference for "sFlow".

-- 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.

"In-network customisation" seems partly contradictory with unified models or
did I misread this part ?

For an uneducated reader (like myself), I wonder whether actual packet content
is included in "The data originated from the data plane forwarding chips"

-- Section 3.5 --
In "Efficient data fusion is critical for applications to reduce the overall
quantity of data", is it about "fusion" or "aggregation" ?

-- Section 4.1 --
In figure 2, what is 'template' ? This does not seem a well-defined term,
suggest to remove it.

Also in figure 2, suggest replace "HTTP" by "HTTPS"

In figure 2, what is the meaning of "plain" for data encoding ?

-- Section 4.1.3 --
Could the "quality" in the first paragraph be described as it is rather vague?

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"

Suggest to make the taxonomy part a subsection.

Is there a reason why "AM" is not expanded in "AM [RFC8321]" ?

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.

-- Section 4.2 --
I fail to understand why formatting is part of "Data Generation and Processing"
and not of "Data Encoding and Export".

-- 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.

-- 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.

== NITS ==

-- Section 2 --
Missing ':' after YANG ECA

---

From: Haoyu Song <[email-masked]>
Date: Mon, 29 Nov 2021 21:44:42 +0000

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-masked]> 
Sent: Friday, November 26, 2021 5:20 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Éric Vyncke's No Objection on draft-ietf-opsawg-ntf-10: (with COMMENT)

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&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C55cf9efa9b20491fb28708d9b0df7dca%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637735296220900165%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=SzTLwFyLAXFwT8X5P5sQN%2Bqsk%2FJ5P%2B9wQVy5e8VkiXg%3D&amp;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&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C55cf9efa9b20491fb28708d9b0df7dca%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637735296220900165%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=MOuvJ%2BgSbiyFGWw6qJuOhsL2FvpN87kC3NZ8BQwU4LQ%3D&amp;reserved=0

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&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C55cf9efa9b20491fb28708d9b0df7dca%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637735296220900165%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=fxvlOsv%2Bpe5Ipxhc8u5fRKnBuE1SOQTmPK2QBReipC0%3D&amp;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.

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&amp;data=04%7C01%7Chaoyu.song%40futurewei.com%7C55cf9efa9b20491fb28708d9b0df7dca%7C0fee8ff2a3b240189c753a1d5591fedc%7C1%7C0%7C637735296220900165%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000&amp;sdata=eD5qDhL7%2B%2FmW%2FTBIoAeeg98cFF2AjGK9zHtD1anFyuc%3D&amp;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 --

-- 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 --

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. 

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

HS> Change to "HTTP(S)" to cover both.

HS> Change to "plain text" for clarification. 

-- Section 4.1.3 --

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.  

HS> Done

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 --

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 --

HS> Fixed.