Subject: [netmod] rfc6991bis: yang:percentage

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 17 Jul 2020 21:16:38 +0200

- Percentages are frequently used in YANG models but usages differ a
    lot in precision and range. It is not clear what the proper
    generic definition of a percentage type would be and whether it is
    worth having it.

    RFC 7950 example:

         typedef percent { type uint8 { range "0 .. 100"; } }

    RFC 8294:

         typedef percentage { type uint8 { range "0..100"; } }

    I-Ds:
         typedef percentage { type decimal64 { fraction-digits 5; } }
         typedef percentile { type decimal64 { fraction-digits 2; } }

    The yang catalogue seems to be down. :-(

  - Proposal: do not add a percentage type since it is trivial to
    define a context specific percentage type that matches range and
    precision requirements (and there is already a definition in RFC
    8294 for those who need exactly that definition).

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 20 Jul 2020 11:19:45 +0200

>     8294 for those who need exactly that definition).

I agree with this proposal. It is also possible to use

   units percent;

where necessary.

Lada

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod

-- 
Ladislav Lhotka 
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Benoit Claise <[email-masked]>
Date: Thu, 30 Jul 2020 14:58:22 +0200

> I agree with this proposal. It is also possible to use
On the other hand, when I look at the numerous percent/percentage 
occurrences in YANG model, it doesn't hurt to define that typedef.

https://yangcatalog.org/yang-search/ => search on "node name" and 
typedef only
We can find 56 entries from IETF, IEEE, BBF, OC, MEF, vendors
Most of them points to:

    *typedef*  percent {
    	*type*  uint8 {
    		*range*  "0 .. 100";

    	}
    }

Regards, Benoit

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 30 Jul 2020 15:25:57 +0200

On Thu, Jul 30, 2020 at 02:58:22PM +0200, Benoit Claise wrote:
> https://yangcatalog.org/yang-search/ => search on "node name" and typedef
> only

But that one is already defined in RFC 8294 in ietf-routing-types.
Does it make sense to define it again in yang-types?

/js

---

From: Benoit Claise <[email-masked]>
Date: Thu, 30 Jul 2020 15:58:16 +0200

> Does it make sense to define it again in yang-types?

My point was taht it makes sense to group typedefs in a few documents: 
RFC6991, 6991bis (hopefully published soon) and .... my bad,  I forgot 
that RFC 8294 is "Common YANG _data types_ for the routing area"

So we're good. Thanks.

Regards, Benoit

---

From: William Lupton <[email-masked]>
Date: Thu, 30 Jul 2020 16:48:41 +0100

except that percent doesn't really seem like a routing-specific data type!

(perhaps the "right" thing to do is to deprecate, and eventually obsolete,
the routing one and define it in a core netmod module?)

On Thu, 30 Jul 2020 at 14:59, Benoit Claise <bclaise=
[email-masked]> wrote:

> Juergen Schoenwaelder <[email-masked]> <[email-masked]> writes:
>
>
> RFC6991, 6991bis (hopefully published soon) and .... my bad,  I forgot that
> RFC 8294 is "Common YANG *data types* for the routing area"
>
> So we're good. Thanks.
>
> Regards, Benoit
>
> /js
>
>
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 30 Jul 2020 17:58:38 +0200

> the routing one and define it in a core netmod module?)

Yes, the percentage type is not not routing specific. But if we choose
to go down this route, we likely have to move more definitions, I also
see timeticks64 and uint24 in RFC 8294 that don't seem to be routing
specific. Since RFC 8294 comes from a different WG in a different IETF
"area", deprecation requires some internal communication and
collaboration (but not deprecating also won't hurt much for these
fairly simple types).

/js