[Dots] Roman Danyliw's No Objection on draft-ietf-dots-telemetry-22: (with COMMENT)

[Roman Danyliw via Datatracker <[e-mail]>]

Roman Danyliw has entered the following ballot position for
draft-ietf-dots-telemetry-22: 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:
----------------------------------------------------------------------

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

Thank you for addressing my DISCUSS and select COMMENTs

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