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

From: <[email-masked]>
Date: Tue, 1 Feb 2022 10:04:29 +0000

Hi Roman, 

Thank you for the review. The proposed changes can be tracked at: https://tinyurl.com/dots-telemetry-latest

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : Roman Danyliw via Datatracker <[email-masked]>
> Envoyé : lundi 31 janvier 2022 21:38
> À : The IESG <[email-masked]>
> Cc : [email-masked]; [email-masked];
> [email-masked]; [email-masked]; [email-masked]
> Objet : Roman Danyliw's Discuss on draft-ietf-dots-telemetry-20: (with
> DISCUSS and COMMENT)
> 
> 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?
> 

[Med] We didn't consider such a tag in the protocol design for at least two reasons: 
* The language setting is basically part of the (offline) "customization" that will take place when setting mitigation platforms.
* We are relying upon RFC7950, which does not mention RFC5646:

==
9.4.  The string Built-In Type

   The string built-in type represents human-readable strings in YANG.
   Legal characters are the Unicode and ISO/IEC 10646 [ISO.10646]
   characters, including tab, carriage return, and line feed but
   excluding the other C0 control characters, the surrogate blocks, and
   the noncharacters.  The string syntax is formally defined by the rule
   "yang-string" in Section 14.
==

Note that none of the RFCed YANG modules I'm aware of includes a tag language, e.g., the description leaf in RFC8343:

     +--rw interfaces
        +--rw interface* [name]
           +--rw name                        string
           +--rw description?                string
           +--rw type                        identityref 

The only mention in RFC8040 (used for DOTS data channel) is an example that defines the following:

         leaf language {
           type string;
           description "Language identifier string.";
           reference "RFC 5646.";
         }

(which does not reflect the formal tag pattern in 5646)

Things would be straightforward if there was an approach that harmonizes the use of language tags among YANG modules by considering, e.g., an IANA-maintained module that echoes the content of language-subtag-registry. But we don't have that. 

My preferred approach would be to simply add the following to Section 8.1.6: 

"Future versions of the "ietf-dots-mapping" module may be considered to indicate a language tag [RFC5646]."

But, if you still think there is a value in adding an optional tag mechanism for this specific YANG module, we can reuse the same definition as in draft-ietf-i2nsf-nsf-monitoring-data-model. 

> 
> ----------------------------------------------------------------------
> 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?
> 

[Med] We are using "deviations" as per the definition in rfc7950#section-5.6.3. Added a pointer to that section. 

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

[Med] The focus we set for this I-D is a minimal information for describing attacks. We can consider other optional attributes but, as you rightfully mentioned, this can be handled by assigning a new attack-id or updating the description. 

> 
> A few editorial suggestions to consider:
> 
> ** Section 1.  Editorial.  s/more complex and hard to/more complex and
> harder to/
> 

[Med] Fixed

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

[Med] The first sentence highlights more the dynamic aspect of the attacks. 

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

[Med] we were referring to the attacks scenario that are discussed above. Changed to "the aforementioned attack scenarios"

> 
> ** Section 2.  Typo. s/whike/while/
> 
> ** Section 2.  Typo. s/to be considered to be/considered to be/
> 

[Med] Fixed. Thanks. 

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

[Med] Section 1 is more generic while this section includes some more DOTS details.

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

[Med] We were specifically referring to ML aspects here, but I agree that we can generalize: s/Statistical and artificial intelligence algorithms (e.g., machine learning)

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

[Med] Split into two sentences as displayed in the diff. 

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

[Med] ACK.

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

[Med] Fixed. Thanks. 

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: Roman Danyliw <[email-masked]>
Date: Wed, 2 Feb 2022 14:04:56 +0000

Hi Med!

These edit on language tags looks good.  Thank you.

Roman

> -----Original Message-----
> From: [email-masked] <[email-masked]>
> Sent: Tuesday, February 1, 2022 5:04 AM
> To: Roman Danyliw <[email-masked]>; The IESG <[email-masked]>
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> Subject: RE: Roman Danyliw's Discuss on draft-ietf-dots-telemetry-20: (with
> DISCUSS and COMMENT)
> 
> Hi Roman,
> 
> Thank you for the review. The proposed changes can be tracked at:
> https://tinyurl.com/dots-telemetry-latest
> 
> Please see inline.
> 
> Cheers,
> Med
> 
> > De : Roman Danyliw via Datatracker <[email-masked]> Envoyé : lundi
> > 31 janvier 2022 21:38 À : The IESG <[email-masked]> Cc :
> > [email-masked]; [email-masked];
> > [email-masked]; [email-masked]; [email-masked] Objet : Roman
> > Danyliw's Discuss on draft-ietf-dots-telemetry-20: (with DISCUSS and
> > COMMENT)
> >
> > email addresses included in the To and CC lines. (Feel free to cut
> > this introductory paragraph, however.)
> >
> >
> > ** 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.”.
> * The language setting is basically part of the (offline) "customization" that will
> take place when setting mitigation platforms.
> Note that none of the RFCed YANG modules I'm aware of includes a tag
> language, e.g., the description leaf in RFC8343:
> 
>      +--rw interfaces
>         +--rw interface* [name]
>            +--rw name                        string
> Things would be straightforward if there was an approach that harmonizes the
> use of language tags among YANG modules by considering, e.g., an IANA-
> maintained module that echoes the content of language-subtag-registry. But
> we don't have that.
> 
> But, if you still think there is a value in adding an optional tag mechanism for
> this specific YANG module, we can reuse the same definition as in draft-ietf-
> i2nsf-nsf-monitoring-data-model.
> 
> >
> > Authors: thank you for the clarifying language in Section 4.4
> > explaining how the design of mapping YANG into CBOR
> >
> > 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.
> 
> [Med] The focus we set for this I-D is a minimal information for describing
> attacks. We can consider other optional attributes but, as you rightfully
> mentioned, this can be handled by assigning a new attack-id or updating the
> description.
> 
> >
> > ** Section 1.  Per “The conclusion derived from these real scenarios
> > is that modern …”, what are these “real” scenarios?
> 
> [Med] we were referring to the attacks scenario that are discussed above.
> Changed to "the aforementioned attack scenarios"
> 
> >
> [Med] We were specifically referring to ML aspects here, but I agree that we
> can generalize: s/Statistical and artificial intelligence algorithms (e.g., machine
> learning)
> 
> > sentence if very long and difficult to parse.  Could it be split up
> > for improved readability?
> 
> ___________________________________________________________________
> ______________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations
> confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou
> copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le
> signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
> electroniques etant susceptibles d'alteration, Orange decline toute
> responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged
> information that may be protected by law; they should not be distributed, used
> or copied without authorisation.

---

From: <[email-masked]>
Date: Thu, 3 Feb 2022 09:00:39 +0000

Hi Roman, 

Thank you for checking. That version (-21) is now public: https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-telemetry-21

Cheers,
Med

> De : Dots <[email-masked]> De la part de Roman Danyliw
> Envoyé : mercredi 2 février 2022 15:05
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; The IESG
> <[email-masked]>
> Cc : [email-masked]; [email-masked]; draft-ietf-dots-
> [email-masked]; [email-masked]
> Objet : Re: [Dots] Roman Danyliw's Discuss on draft-ietf-dots-telemetry-
> 20: (with DISCUSS and COMMENT)
> 
> Hi Med!
>