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
> À : BOUCADAIR Mohamed INNOV/NET <mohamed.boucadair@xxxxxxxxxx>; 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
>
> <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 |
+--------+--------------+------------------+
...
>
> >> 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].
_________________________________________________________________________________________________________________________
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
