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

[Éric Vyncke via Datatracker <[e-mail]>]

É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