Subject: [Dots] Last Call: <draft-ietf-dots-telemetry-19.txt> (Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry) to Proposed Standard

From: The IESG <[email-masked]>
Date: Mon, 10 Jan 2022 06:32:16 -0800

The IESG has received a request from the DDoS Open Threat Signaling WG (dots)
to consider the following document: - 'Distributed Denial-of-Service Open
Threat Signaling (DOTS) Telemetry'
  <draft-ietf-dots-telemetry-19.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2022-01-24. Exceptionally, comments may
be sent to [email-masked] instead. In either case, please retain the beginning
of the Subject line to allow automated sorting.

Abstract

   This document aims to enrich the DOTS signal channel protocol with
   various telemetry attributes, allowing for optimal Distributed
   Denial-of-Service (DDoS) attack mitigation.  It specifies the normal
   traffic baseline and attack traffic telemetry attributes a DOTS
   client can convey to its DOTS server in the mitigation request, the
   mitigation status telemetry attributes a DOTS server can communicate
   to a DOTS client, and the mitigation efficacy telemetry attributes a
   DOTS client can communicate to a DOTS server.  The telemetry
   attributes can assist the mitigator to choose the DDoS mitigation
   techniques and perform optimal DDoS attack mitigation.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-dots-telemetry/

No IPR declarations have been submitted directly on this I-D.

---

From: tom petch <[email-masked]>
Date: Fri, 14 Jan 2022 12:32:19 +0000

Some stray thoughts

I wonder if there is a recognised terminology for attacks, threats and 
such-like.  I have been looking at I2NSF I-D recently and they are, 
well, different.  I note too that secdir reviews thereof queried some of 
the I2NSF terminology but what is right and what is wrong?.  I am 
reminded of the efforts to produce a second version of the Security 
Glossary some time ago.

I find the use of -g and -ps alien.  I worked out what they mean but 
cannot help feeling that there is a clearer way to express this, such as 
pps, bps, Bps (YANG does not like capitalisation but does allow it where 
it is widely recognised, which, for me, Bps is).

URI for IANA are inconsistent, http: and https: - since IANA allows 
http: (hurrah) I am easy with either but do like consistency

"The DOTS telemetry module (Section 10.1) uses "enumerations" rather
    than "identities" to define units, samples, and intervals because
    otherwise the namespace identifier "ietf-dots-telemetry" must be
    included when a telemetry attribute is included "
Well yes but that is saying the ietf-dots-telemetry is a bad choice of 
prefix - the 'ietf' is redundant and the 'telemetry' is prolix

       TBA: Overlapping pipe scope (see Section 12).
could do with an explanatory note, perhaps one for the RFC Editor

    vendor-id:  Vendor ID is a security vendor's Enterprise Number as
       registered with IANA [Enterprise-Numbers].  It is a four-byte
       integer value.
No, it is an integer which in this model is uint32 which can be 
represented in a number of ways

The user has to understand that [Enterprise-Numbers] is the same as 
Private Enterprise Numbers", which may not be apparent; consistent 
terminology is good.

YANG TLD is out of date and URI lacks https:

Authors vary between the frontispiece, the YANG modules and Authors' 
Addresses

Two references in the YANG modules I do not see in the I-D References
       <https://www.iana.org/assignments/protocol-numbers/>.
       "Section 4.4.2 of RFC UUUU.";
The latter is not an RFC I am familiar with (but then that is true of 
most RFC:-(

     reference
       "IANA: Private Enterprise Numbers";
would be clearer with a URI, whereever it occurs which is in more than 
one place

Security COnsiderations uses part of the YANG Guidelines template but 
not all; TLS is notable for its absence.

Tom Petch

On 10/01/2022 14:32, The IESG wrote:
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
> .
>

---

From: <[email-masked]>
Date: Mon, 17 Jan 2022 09:35:20 +0000

Hi Tom, 

Thank you for the review. Much appreciated. 

Please see inline. 

Cheers,
Med

> -----Message d'origine-----
> De : tom petch <[email-masked]>
> Envoyé : vendredi 14 janvier 2022 13:32
> À : [email-masked]
> Cc : [email-masked]; [email-masked]; [email-masked]; draft-
> [email-masked]
> Objet : Re: Last Call: <draft-ietf-dots-telemetry-19.txt> (Distributed
> Denial-of-Service Open Threat Signaling (DOTS) Telemetry) to Proposed
> Standard
> 
> Some stray thoughts
> 

[Med] You may look at RFC4949, but that document requires a refresh. For the particular DoS case, RFC4732 is still a good reading reference. 

> it is widely recognised, which, for me, Bps is).

[Med] *-g is used to identify nodes of gauge type while *-ps identifies nodes that are expressed as a value "per second". We don't include the reasoning of the naming convention as what matters is the description of the attributes, not their names. We can add a note if you think this is helpful. 

> http: (hurrah) I am easy with either but do like consistency

[Med] Fixed this one https://www.iana.org/assignments/enterprise-numbers.html. Thanks. 

> prefix - the 'ietf' is redundant and the 'telemetry' is prolix

[Med] We could shorten the prefix but the issue is still there:  have to include a prefix.  

> could do with an explanatory note, perhaps one for the RFC Editor

[Med] Sure. Added a note to Section 12.2. 

> represented in a number of ways

[Med] Fixed. 

> Private Enterprise Numbers", which may not be apparent; consistent

[Med] Not sure a (which) change is needed. The current text says:  

   vendor-id:  Vendor ID is a security vendor's Enterprise Number as
      registered with IANA [Enterprise-Numbers].

with:

   [Enterprise-Numbers]
              "Private Enterprise Numbers", 4 May 2020,
              <http://www.iana.org/assignments/enterprise-numbers.html>.

> YANG TLD is out of date and URI lacks https:

[Med] OK

> 
> Authors vary between the frontispiece,

[Med] That is not an issue. 

 the YANG modules and Authors'
> Addresses

[Med] Fixed Tiru's address. Thanks. 

> The latter is not an RFC I am familiar with (but then that is true of

[Med] :-) Changed to "RFC 9132". Thanks. 

>      reference
>        "IANA: Private Enterprise Numbers"; would be clearer with a URI,
> whereever it occurs which is in more than one place
> 

[Med] Will leave this one for the RFC editor. 

> not all

[Med] That is on purpose:
* we don't use it in 13.1 because this YANG module is not used for management purposes:

   The DOTS telemetry module (Section 10.1) is not intended to be used
   via NETCONF/RESTCONF for DOTS server management purposes.  It serves
   only to provide a data model and encoding following [RFC8791].

* as we are pointing to rfc8783#section-10, only new considerations are included here. 

; TLS is notable for its absence.

[Med] That's covered in the 9132 and 8738. We don't repeat these aspects here. 

> > The IESG has received a request from the DDoS Open Threat Signaling WG
> > (dots) to consider the following document: - 'Distributed
> > Denial-of-Service Open Threat Signaling (DOTS) Telemetry'
> > The IESG plans to make a decision in the next few weeks, and solicits
> > final comments on this action. Please send substantive comments to the
> > [email-masked] mailing lists by 2022-01-24. Exceptionally,
> > comments may be sent to [email-masked] instead. In either case, please
> > retain the beginning of the Subject line to allow automated sorting.
> >
> > Abstract
> >
> >

_________________________________________________________________________________________________________________________

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: tom petch <[email-masked]>
Date: Tue, 18 Jan 2022 10:05:54 +0000

<inline excising the agreed ones>

> [Med] You may look at RFC4949, but that document requires a refresh. For the particular DoS case, RFC4732 is still a good reading reference.

Yes. When RFC4949 was an I-D I quoted from it and got an off-list 
comment from an AD that that I-D was controversial and at least some AD 
thought it should not be published.  RFC2828 is fine, if dated, RFC4949 
not, so I do not refer to it.

> [Med] *-g is used to identify nodes of gauge type while *-ps identifies nodes that are expressed as a value "per second". We don't include the reasoning of the naming convention as what matters is…

Well yes, I worked that out but I still find those suffix jarring. I 
think that the concept of gauge is not well known so the -g will not be 
obvious and ps is much used for 'post scriptum'!

> [Med] We could shorten the prefix but the issue is still there:  have to include a prefix.

Depends what the default is, at least with XML.  This came up recently 
with I2NSF where I sought and got clarification on the NETMOD list that 
most of the prefix in the examples were not needed.  I don't know how 
well this fits with CoAP.

> [Med] Not sure a (which) change is needed. The current text says:

In most walks of life, if you have a registry and a private registry, 
then users will assume that the registry is public and the private 
registry is private and that there are two separate registries.  Here 
there is just the one and the correct name is 'Private Enterprise 
Number' sometimes abbreviated to PEN.  Experts will know that there is 
no Public Enterprise Number, others will not so I think we should use 
Private Enterprise Number in all cases and not just Enterprise Number.

> [Med] Fixed Tiru's address. Thanks.

Well the YANG has 'Author: Konda ...' and it is not immediately obvious 
whioh that is.  I like consistency  although I recognise that I18N can 
make that awkward.

Tom Petch

---

From: <[email-masked]>
Date: Tue, 18 Jan 2022 13:05:11 +0000

Hi Tom, 

Thank you for the follow-up. 

Please see inline for two proposed changes. 

Cheers,
Med

> Envoyé : mardi 18 janvier 2022 11:06
> À : BOUCADAIR Mohamed INNOV/NET <[email-masked]>; last-
> [email-masked]
> >> De : tom petch <[email-masked]> Envoyé : vendredi 14 janvier
> >> 2022 13:32
> >>
> >> Some stray thoughts
> >>
...
> > [Med] *-g is used to identify nodes of gauge type while *-ps
> identifies nodes that are expressed as a value "per second". We don't
> include the reasoning of the naming convention as what matters is the
> description of the attributes, not their names. We can add a note if you
> think this is helpful.
> 
> 

[Med] OK. Added this NEW text: 

   Some parameters (e.g., low percentile values) may be associated with
   different YANG types (e.g., decimal64 and yang:gauge64).  To easily
   distinguish the types of these parameters while using meaningful
   names, the following suffixes are used:

               +--------+--------------+------------------+
               | Suffix | YANG Type    | Example          |
               +--------+--------------+------------------+
               | -g     | yang:gauge64 | low-percentile-g |
               | -c     | container    | connection-c     |
               | -ps    | per second   | connection-ps    |
               +--------+--------------+------------------+

...
> Private Enterprise Number in all cases and not just Enterprise Number.

[Med] Went with the following change:

> >        registered with IANA [Enterprise-Numbers].

NEW:
   vendor-id:  Vendor ID is a security vendor's enterprise number as
      registered in the IANA's "Private Enterprise Numbers" registry
      [Enterprise-Numbers].

---

From: tom petch <[email-masked]>
Date: Wed, 19 Jan 2022 12:34:43 +0000

>     names, the following suffixes are used:
  ok, reluctantly

>        registered in the IANA's "Private Enterprise Numbers" registry

You have still got half a dozen or so uses of 'Enterprise Number' in the 
I-D and my preference would be to change them all to 'Private Enterprise 
Number'!  As I said before, an expert knows that there is no Public 
Enterprise Number, others do not.

Tom Petch

>
> _____________________________________

---

From: <[email-masked]>
Date: Wed, 19 Jan 2022 12:56:43 +0000

Hi Tom, 

Thank you for checking the changes and sharing your feedback. 

Please see inline. 

Cheers,
Med

> Envoyé : mercredi 19 janvier 2022 13:35
...
> >> Number' sometimes abbreviated to PEN.  Experts will know that there
> >> is no Public Enterprise Number, others will not so I think we should
> >> use Private Enterprise Number in all cases and not just Enterprise
> Number.
> >>
> >
> Number'!

[Med] No change is made for the other occurrences on purpose. For example,  

   The examples use the Enterprise Number 32473 defined for
   documentation use [RFC5612].

no change is made to that text because we want to be consistent with existing RFC5612 which says the following:  

   IANA has updated the registration for Enterprise Number 32473 to
   point to this RFC.

  As I said before, an expert knows that there is no Public
> Enterprise Number, others do not.

[Med] Added this new entry to the terminology section:

NEW:
   The document uses IANA-assigned Enterprise Numbers.  These numbers
   are also known as "Private Enterprise Numbers" and "SMI (Structure of
   Management Information) Network Management Private Enterprise Codes"
   [Enterprise-Numbers].

Better?

---

From: tom petch <[email-masked]>
Date: Fri, 21 Jan 2022 11:31:37 +0000

>     Management Information) Network Management Private Enterprise Codes"

I cannot see us agreeing on this.  The fact that the terminology of 
RFC5612 is not what it might be does not, for me, sanction other such 
glitches.

Tom Petch

>
> _________________________________________________

---

From: <[email-masked]>
Date: Tue, 25 Jan 2022 15:57:53 +0000

Hi Tom, 

The changes to take into account the outcome of this thread can be seen at https://www.ietf.org/rfcdiff?url2=draft-ietf-dots-telemetry-20 

I highly appreciate your effort to review as much documents in the IETF LC. Big thanks for that. Your review is ACKed in the document. 

Cheers,
Med

> Envoyé : vendredi 21 janvier 2022 12:32
> >> De : tom petch <[email-masked]> Envoyé : mercredi 19 janvier
> >> 2022 13:35
> >>
> > ...
> >>> ...
> >>>>
> >>>>>> The user has to understand that [Enterprise-Numbers] is the same
> >>>>>> as Private Enterprise Numbers", which may not be apparent;
> >>>>>> consistent terminology is good.
> >>>>>
> >>>> In most walks of life, if you have a registry and a private
> >>>> registry, then users will assume that the registry is public and
> >>>> the private registry is private and that there are two separate
> >>>> registries.  Here there is just the one and the correct name is
> >>>> 'Private Enterprise Number' sometimes abbreviated to PEN.  Experts
> >>>> will know that there is no Public Enterprise Number, others will
> >>>> not so I think we should use Private Enterprise Number in all cases
> >>>> and not just Enterprise
> >> Number.
> >>>>
> >>>
> >>>>>       vendor-id:  Vendor ID is a security vendor's Enterprise
> >>>>> Number
> >> as
> >> You have still got half a dozen or so uses of 'Enterprise Number' in
> >> the I-D and my preference would be to change them all to 'Private
> >> Enterprise Number'!
> >
> > no change is made to that text because we want to be consistent with
> existing RFC5612 which says the following:
> >