Hi Carsten,
I confirm that what I meant is "bits per second" to align with rfc8299#6.12.1.
I'm actually for more explicit units similar to what we are using in another
active spec:
==
enum bit-ps {
value 2;
description
"Bits per Second (bit/s).";
}
enum byte-ps {
value 3;
description
"Bytes per second (Byte/s).";
}
==
However, we are in a territory where we are trying to map as much to the above
service model and hence use the same labels for the units.
FWIW, RFC8466 used to have the following:
=
leaf pbs {
type uint64;
units "bps";
description
"Peak Burst Size. It is measured in bytes per
second.";
}
=
...which is weird. This is why we don't blindly inherit that
draft-ietf-opsawg-l2nm and went for the following:
leaf pbs {
type uint64;
units "bytes per second";
description
"Peak Burst Size.";
}
Cheers,
Med
> -----Message d'origine-----
> De : Carsten Bormann <[email protected]>
> Envoyé : lundi 4 octobre 2021 17:50
> À : BOUCADAIR Mohamed INNOV/NET <[email protected]>
> Cc : Francesca Palombini <[email protected]>; The IESG
> <[email protected]>; [email protected]; opsawg-
> [email protected]; [email protected]; [email protected]
> Objet : Re: [OPSAWG] Francesca Palombini's Discuss on draft-ietf-opsawg-
> l3sm-l3nm-16: (with DISCUSS and COMMENT)
>
> On 2021-10-04, at 13:34, [email protected] wrote:
> >
> > bytes per second (bps),
>
> Whoa.
>
> I know that the IETF doesn’t usually care about precision in these things,
> but “bps” is kitchen slang for “bit/s”, so this is very confusing.
>
> (Given that we have done the work in RFC 8428 and 8798, I’d rather see
> that we use it, instead of creating more confusion at each further step.
> We do have ms and B/s in RFC 8798, because people using SenML asked for
> that.)
>
> Grüße, Carsten
_________________________________________________________________________________________________________________________
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.
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
