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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 18/01/2022 13:05, mohamed.boucadair@xxxxxxxxxx wrote:
Hi Tom,

Thank you for the follow-up.

Please see inline for two proposed changes.

Cheers,
Med

-----Message d'origine-----
De : tom petch <daedulus@xxxxxxxxxxxxx>
Envoyé : mardi 18 janvier 2022 11:06

<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 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'!


[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    |
                +--------+--------------+------------------+

 ok, reluctantly


...

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.


[Med] Went with the following change:

OLD:

     vendor-id:  Vendor ID is a security vendor's Enterprise Number as
        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].


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


_____________________________________

--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call




[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux