Subject: [Dots] Roman Danyliw's Discuss on draft-ietf-dots-telemetry-20: (with DISCUSS and COMMENT)

From: Roman Danyliw via Datatracker <[email-masked]>
Date: Mon, 31 Jan 2022 12:38:02 -0800

Roman Danyliw has entered the following ballot position for
draft-ietf-dots-telemetry-20: Discuss

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/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

** Sections 8.1.5 and 9.1. These sections describe a human readable text field,
“attack-description”.  Per Section 4.2 of BCP 18, “[p]rotocols that transfer
text MUST provide for carrying information about the language of that text.”. 
Practically, can a field to list a language tag field (RFC 5646 and
https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry)
be added in all places that “attack-description” is defined or at the top level?

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

Authors: thank you for the clarifying language in Section 4.4 explaining how
the design of mapping YANG into CBOR

** Section 4.4.  Per “Server deviations are strongly discouraged …”, what kind
of “deviations” are being referenced here?  Is it the use of NETCONF/RESTCONF?

** Section 8.1.6.  An attack type appears to be characterized by a vendor-id,
vendor-name, last-updated, attack-id and attack-description.  Would an
additional field of attack-id-revision (or attack-id-version) be beneficial
too?  I’m imagining a workflow where a vendor’s definition of an attack (and
the associated detection rule/logic) changes overtime and it might be useful to
version that – akin to the snort/suricata’s “rev:” field.  A vendor could of
course assign a new attack-id but this might impact down-stream analysis.

A few editorial suggestions to consider:

** Section 1.  Editorial.  s/more complex and hard to/more complex and harder
to/

** Section 1.  Editorial
These attacks are assembled from dynamic attack vectors
   (Network/Application) and tactics.  As such, multiple attack vectors
   formed by multiple attack types and volumes are launched
   simultaneously towards a victim.

What is the difference between the first and the second sentence?

** Section 1.  Per “The conclusion derived from these real scenarios is that
modern …”, what are these “real” scenarios?

** Section 2.  Typo. s/whike/while/

** Section 2.  Typo. s/to be considered to be/considered to be/

** Section 3.1.  It seems like much of this information is a re-statement of
what was said in Section 1.  Does it need to be said twice?

** Section 3.1.  “Machine learning approaches …”, do you mean statistical and
artificial intelligence algorithms? ML is only a particular approach.

** Section 4.1.  Per “Telemetry information has aspects …”, this sentence if
very long and difficult to parse.  Could it be split up for improved
readability?

** Section 8.1.4.  typo.  s/subattributes/sub-attributes/

** Section 11.1.  Typo. s/extremly/extremely/