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
last-call@xxxxxxxx mailing lists by 2022-01-24. Exceptionally, comments may
be sent to iesg@xxxxxxxx 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
IETF-Announce@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf-announce
.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
