[OPSAWG] Warren Kumari's No Objection on draft-ietf-opsawg-ntf-11: (with COMMENT)

[Warren Kumari via Datatracker <[e-mail]>]

Warren Kumari has entered the following ballot position for
draft-ietf-opsawg-ntf-11: 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:
----------------------------------------------------------------------

Firstly, thank you for writing this, and thanks to Sheng Jiang for the OpsDir
review.

 I personally think that these sort of "overview" / framework documents are
 really useful; I've often had to get spun up on some new technology and
 reading an RFC which specifies the packet format without a good overview
 document (like this one ) is not helpful...

Anyway, with that soapbox rant over, I have 2 substantive comments and some
nits to help make the document better / more readable. There is no need to
reply to each comment (or at all) - these are non-blocking comments, but fixing
them will help make the RFC Editor's job easier and help ensure that none sneak
through...

1:S1 - Introduction
"All the modules are internally structured in the same way, including
components that allow to configure data sources in ..." P: "that allow for the
configuration" or "that allow the <subject - operator? system?> to configure
what data to..."

"The framework can also simplify the tasks for designing, maintaining, and
understanding a network telemetry system." P:"the task of designing" (or just
"simplify the design, maintenance and understanding of ..."

"At last, we outline the evolution stages of the network telemetry system and
discuss the potential security concerns." P: "Finally, ..." or "Lastly, ...".
Actually, I think "In addition...." would be even better.

S 2.2 Use Cases
"Intent, as defined in [I-D.irtf-nmrg-ibn-concepts-definitions], is a set of
operational goal that a network ..." s/goal/goals/

"SLA Compliance: A Service-Level Agreement (SLA) defines the level of service a
user expects from a network operator," I disagree with this -- an SLA is what a
network operator has agreed to provide, usually with a contract and penalty to
missing it. As a user I *expect* my network operator to always exceed the SLA -
if the SLA specifies 95% uptime, I don't really expect 36 hours of downtime
each month :-P. Also, in many cases I (sadly) *expect* much worse service than
the SLA actually specifies... The Wikipedia
https://en.wikipedia.org/wiki/Service-level_agreement page has some good text
you could use...

"Root Cause Analysis: Any network failure can be the effect of a sequence of
chained events." The use of "Any" here seems odd / wrong -- perhaps "Network
failures are often ..." or "Many network failures..." or just drop the first
sentence and start with "Troubleshooting and recovery require ..."

S 2.3
"The poll-based low-frequency data collection is ill-suited..."
Drop the "The", or s/The/This/

"Subscription-based streaming data directly pushed from the data source (e.g.,
the forwarding chip) is preferred to provide enough data quantity and precision
at scale." Suggest s/enough/sufficient/ (just for flow)

"Comprehensive data is needed from packet processing engine to traffic manager,
from line cards to main control board,..." s/engine/engines/, or, better, "from
the packet processing engine to the traffic manager..."

S 3.1. Top Level Modules
"Therefore, we categorize the network telemetry into four distinct modules with
each having its own interface to Network Operation Applications." It would be
really helpful to list the "four distinct modules" here -- I spent quite a
while looking at the figure (with 5 boxes :-)) trying to infer what you meant.
Just adding them in a parenthetical would work well.

"For example, the forwarding chip has high throughput but limited capacity for
processing complex data and maintaining states, while ..." s/states/state/
(Yes, I get that the forwarding engine manages many different sets of state,
but "maintaining states" still seems weird...)

Again, thank you for writing this, and also for considering / addressing these
nits...