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

[tom petch <[e-mail]>]

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:
>
> 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
> [e-mail] mailing lists by 2022-01-24. Exceptionally, comments may
> be sent to [e-mail] 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.
>
>
>
>
>
> _______________________________________________
> IETF-Announce mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ietf-announce
> .
>