[Dots] Éric Vyncke's No Objection on draft-ietf-dots-telemetry-20: (with COMMENT)

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

Éric Vyncke has entered the following ballot position for
draft-ietf-dots-telemetry-20: 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-dots-telemetry/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for the work put into this document. Based on Med Boucadair’s reply,
I have cleared my DISCUSS.

Please find below one blocking DISCUSS points (kept for archiving), some
non-blocking COMMENT points (but replies would be appreciated even if only for
my own education).

Please also have a look at Ted Lemon's INT directorate review at
<https://datatracker.ietf.org/doc/review-ietf-dots-telemetry-19-intdir-lc-lemon-2022-01-23/>.
I share Ted's concern about have three independent topics in a single document
rather than in 3 documents.

Special thanks to Valery Smyslov for the shepherd's write-up including the
section about the WG consensus even if I had appreciated a justification for
the PS status.

I hope that this helps to improve the document,

Regards,

-éric

# Previous DISCUSS kept for archiving only

## Section 8.1.5 (and others)

Please note that I am not a YANG expert, but it seems to me that
"attack-detail* [vendor-id attack-id]" indicates that vendor-id & attack-id are
the keys to attack-detail, i.e., there can only have one attack-detail per pair
of vendor-id & attack-id. So, there is no way to have multiple
sequential/simultaneous attacks, i.e., should the start-time be also part of
the key?

# COMMENT

I am ambivalent with respect to the amount of context introduction in each
(sub)-section: it is for sure good for a new reader, but it also lengthens the
read for a more knowledgeable one.

## Abstract

Should the abstract mention the presence of a YANG model ?

## Section 2

Should the text specifies that tsid and tmid are monotonically increasing
values and not just a mere opaque identifier ?

Ben Kaduk also pointed the IESG members' attention to the use of "PEN" or
"Enterprise Number". As there is a § in this section about "Enterprise Number",
this would be the right place to state that this document uses "Enterprise
Number" or "Private Enterprise Number" or "PEN" for the same concept through
the rest of the document and stick to one wording. My own taste prefers "PEN"
even if RFC 5612 uses "Enterprise Number" but it is a matter of taste.

## Section 4.3

Should there be some words about using one upstream 'pipe' to reach the DOTS
server protecting another 'pipe' ? Or is it too obvious ?

## Section 7.2

Possibly a bad reading the unit/capacity section of mine, but how can 1.0 and
1.499 be differentiated with this notation? I.e., both will be represented 1
with a 50% difference though...

## Section 7.3

Are the authors/WG expecting that all IP packets are equal ? I.e., that the
downstream devices can handle IPv4 and IPv6 at the same rate ? Or should the
baseline information be different based on IP protocol version ? Or will the
normal use use only one-address-family 'target-prefix' ? Then, of course how to
decide the sum of traffic to the same network but over IPv4 or IPv6?

I would have preferred to use 'next-header' rather than 'protocol' or is the
expected behaviour to parse the IPv6 extension header chain to find the
transport protocol ? Same comment for other use of 'protocol' as in section 8.1.

Quite often ICMP types (and codes) are used in ACL for the same purpose as
transport-layer ports, was the use of ICMP types/codes considered?

## Section 7.3.1

Nice to see IPv6-only examples :-)

## Section 8

Suggestion to add some words about the "attack-detail* [vendor-id attack-id]"
leaf early in the text without waiting for section 8.1.5

## Section 8.1.6

Should figure 34 use the example PEN ? I.e., 32473 rather than 345 ?

## Section 11.1

Is it really useful to have both "bits" and "bytes" as units ? One is easily
derived from the other and this would be easier for every application to only
have "bits".

Suggestion use "octet" rather than "byte".