<inline excising the agreed ones>
On 17/01/2022 09:35, mohamed.boucadair@xxxxxxxxxx wrote:
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
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.
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.
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.
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'!
"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.
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.
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:
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
registered with IANA [Enterprise-Numbers].
with:
[Enterprise-Numbers]
"Private Enterprise Numbers", 4 May 2020,
<http://www.iana.org/assignments/enterprise-numbers.html>.
Authors vary between the frontispiece,
[Med] That is not an issue.
the YANG modules and Authors'
Addresses
[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.
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.
Tom Petch
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.
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
