Hi Tom, Thank you for the review. Much appreciated. Please see inline. Cheers, Med > -----Message d'origine----- > De : tom petch <daedulus@xxxxxxxxxxxxx> > Envoyé : vendredi 14 janvier 2022 13:32 > À : last-call@xxxxxxxx > Cc : dots-chairs@xxxxxxxx; valery@xxxxxxxxxxx; dots@xxxxxxxx; draft- > ietf-dots-telemetry@xxxxxxxx > 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 > > 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. [Med] You may look at RFC4949, but that document requires a refresh. For the particular DoS case, RFC4732 is still a good reading reference. > > 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). [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. > > URI for IANA are inconsistent, http: and https: - since IANA allows > http: (hurrah) I am easy with either but do like consistency [Med] Fixed this one https://www.iana.org/assignments/enterprise-numbers.html. Thanks. > > "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 [Med] We could shorten the prefix but the issue is still there: have to include a prefix. > > TBA: Overlapping pipe scope (see Section 12). > could do with an explanatory note, perhaps one for the RFC Editor > [Med] Sure. Added a note to Section 12.2. > > 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 [Med] Fixed. > > The user has to understand that [Enterprise-Numbers] is the same as > Private Enterprise Numbers", which may not be apparent; consistent > terminology is good. [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. > > 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:-( > [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. > Security COnsiderations uses part of the YANG Guidelines template but > 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. > 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 > > . > > _________________________________________________________________________________________________________________________ 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. -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
