Subject: Re: [netmod] for a future rfc6991bis

From: Qin Wu <[email-masked]>
Date: Tue, 6 Nov 2018 01:25:43 +0000

Another case would be :

“

typedef percentage {

      type decimal64 {

         fraction-digits 5;

         range "0..100";

     }

   description "Percentage.";
   }
”
Which is defined ietf-connectionless-oam.yang module.

-Qin
发件人: netmod [mailto:[email-masked]] 代表 Xufeng Liu
发送时间: 2018年11月6日 3:49
收件人: [email-masked]
抄送: NETMOD WG <[email-masked]>
主题: Re: [netmod] for a future rfc6991bis

The draft that asked for the percentage type is: https://tools.ietf.org/html/draft-ye-ccamp-mw-topo-yang-02

They currently define:

              leaf availability {
                type decimal64 {
                  fraction-digits 4;
                  range "0..99.9999";
                }
                description "Availability level of the link";
              }

Thanks,
- Xufeng

On Sun, Nov 4, 2018 at 7:07 AM Balázs Lengyel <[email-masked]<mailto:[email-masked]>> wrote:

+1 to percentage.

Balazs
On 2018. 11. 03. 3:44, Xufeng Liu wrote:
Remember that some draft asked for a type of percentage value to the nearest hundredth. Wondering if it can be put in.

Thanks,
- Xufeng

On Fri, Nov 2, 2018 at 11:39 AM tom petch <[email-masked]<mailto:[email-masked]>> wrote:
---- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]<mailto:[email-masked]>>
To: "Kent Watsen" <[email-masked]<mailto:kwatsen@juniper..net>>
Cc: <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, October 30, 2018 10:14 AM

> On Tue, Oct 30, 2018 at 12:05:17AM +0000, Kent Watsen wrote:
> >
> > >> In addition, it might be good to introduce [inet?] types for RFC
5322
> > >> (Internet Message Format) including perhaps:
> > >>
> > >>   - email-address        (addr-spec, per Section 3.4.1)
> > >>   - named-email-address  (name-addr, per Section 3.4)
> > >>
> > >
> > > Where are these used? Or have these already been used somewhere?
> >
> > I'm unaware of these ever having been used before.  I am working on
a private module for which I want to configure an email address.  After
some searching, I concluded that no such types have been defined, and
thus thought that they might be good candidates for addition.

We could defined a user-name, of the form localpart@domainpart as is
widely used to identify a user in operations but which does not, in my
experience, owe anything to i18n, just a straightforward character set;
yes it would not boil the ocean, but could be useful.  I am surprised
not to find such a definition somewhere in our 40 or so NETCONF I-Ds.

Tom Petch

> >
>
> It would be good to have strong use cases. I fear that defining this
> type won't be easy given that we also have internationalized email
> addresses (RFC 6530 provides an overview) and we might have to create
> a union of RFC 5322 addresses and "SMTPUTF8 (compliant) addresses".
>
> /js
>
> --
> 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/>
>
> _______________________________________________
> netmod mailing list
> [email-masked]<mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netmod

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

_______________________________________________

netmod mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/netmod<https://www..ietf.org/mailman/listinfo/netmod>

--

Balazs Lengyel                       Ericsson Hungary Ltd.

Senior Specialist

Mobile: +36-70-330-7909              email: [email-masked]<mailto:[email-masked]>

---

From: "Yemin (Amy)" <[email-masked]>
Date: Tue, 6 Nov 2018 02:21:33 +0000

If the percentage is defined as following, as a author of draft-ye-ccamp-mw-topo-yang-02, we will be happy to use it.
But it's better to include in RFC6991bis, as percentage is a generic and widely used item.

BR,
Amy
________________________________
发件人: netmod [[email-masked]] 代表 Qin Wu [[email-masked]]
发送时间: 2018年11月6日 9:25
收件人: Xufeng Liu; [email-masked]
抄送: NETMOD WG
主题: Re: [netmod] for a future rfc6991bis

Another case would be :

“

typedef percentage {

      type decimal64 {

         fraction-digits 5;

         range "0..100";

     }

-Qin

They currently define:

              leaf availability {
                type decimal64 {
                  fraction-digits 4;
                  range "0..99.9999";
                }

Thanks,
- Xufeng

+1 to percentage.

Balazs

Thanks,
- Xufeng

---- Original Message -----
From: "Juergen Schoenwaelder" <[email-masked]<mailto:[email-masked]>>
To: "Kent Watsen" <[email-masked]<mailto:kwatsen@juniper..net>>
Cc: <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, October 30, 2018 10:14 AM

5322

Tom Petch

netmod mailing list

https://www.ietf.org/mailman/listinfo/netmod<UrlBlockedError.aspx>

--

Senior Specialist

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 6 Nov 2018 15:16:13 +0100

Well, the draft-ye-ccamp-mw-topo-yang-02 definition excludes 100%,
which is likely not generally useful. In fact, even 150% can be in
some contexts a perfectly sensible percentage. So we may need to
provide some flexibility here, i.e., having a base time where the
range can be refined and refined types with an upper limit set to 100%
for use in situations where this limit is sensible.

The more difficult aspect seems to be precision, I am not sure YANG
allows subtyping the fractional part. RFC 7950 seems to be silent
about this and in the general case this would not be meaningful. But
in this particular case, when the number range is limited, it would
actually be OK to allow this (but then we have to have a limit and
we can't set the upper limit to max).

/js

> [email-masked]

---

From: "Yemin (Amy)" <[email-masked]>
Date: Wed, 7 Nov 2018 07:49:54 +0000

Hi Juergen,

What we don't like in current RFC6991 is the type is uint8 which doesn't allow fraction. 
For the range, if the defintion can cover the our range(0..99.9999), it will be acceptable. 
In your suggestion below, does that mean the base defintion is without range, while refined types can chosse the range they like?

BR,
Amy
________________________________________
发件人: Juergen Schoenwaelder [[email-masked]]
发送时间: 2018年11月6日 22:16
收件人: Yemin (Amy)
抄送: Qin Wu; Xufeng Liu; [email-masked]; NETMOD WG
主题: Re: [netmod] for a future rfc6991bis

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 7 Nov 2018 09:34:01 +0100

On Wed, Nov 07, 2018 at 07:49:54AM +0000, Yemin (Amy) wrote:

> For the range, if the defintion can cover the our range(0..99.9999),
> it will be acceptable.  In your suggestion below, does that mean the
> base defintion is without range, while refined types can chosse the
> range they like?

I was thinking loud. Let me detail somewhat more what was going on in
my head:

  We could define a percent type without the upper bound being
  whatever the decimal covers but fixing the precision of the
  fractional part. We could then narrow the upper bound via
  subtyping:

     typedef percent {
       type decimal {
         fraction-digits 4;
         range "0..max";
       }
     }

     typedef percent' {
       type percent { range 0..100; }
     }

  If wanted flexibility on the fractional part, we could define
  percent with a fixed range and the largest number of fraction digits
  possible and then we could subtype this to obtain a precision that
  makes sense in the usage contexts (although it is not clear whether
  YANG 1.1 really allows this, if not this may be just due to nobody
  ever thinking about this before):

    typedef percent {
      type decimal {
        fraction-digits 16;
        range 0..100;
      }
    }

    typedef percent' {
      type percent { fraction-digits 4; }
    }

  An ideal solution would provide flexibility both on the range and
  the number of fraction digits but it seems this is impossible since
  these two properties (range and precision) interact.

So it seems we have to do something that is pragmatic and this likely
means fixing the fraction since subtyping the fractional part may not
be allowed by YANG or not be supported by implementations. The
question is then how we pick suitable fractions. I understand you want
4 digits.

/js

---

From: Per Hedeland <[email-masked]>
Date: Wed, 7 Nov 2018 09:56:53 +0100

>    ever thinking about this before):

I believe it is quite clear that this is *not* allowed:

   9.3.3.  Restrictions

      A decimal64 type can be restricted with the "range" statement
      (Section 9.2.4).

--Per

>> Ñöº: Juergen Schoenwaelder [[email-masked]]
>> Ñöô: 2018t116å 22:16
>> 6öº: Yemin (Amy)
>> : Qin Wu; Xufeng Liu; [email-masked]; NETMOD WG
>> ;: Re: [netmod] for a future rfc6991bis
>>
>>> Ñöº: netmod [[email-masked]] ãh Qin Wu [[email-masked]]
>>> Ñöô: 2018t116å 9:25
>>> 6öº: Xufeng Liu; [email-masked]
>>> : NETMOD WG
>>> ;: Re: [netmod] for a future rfc6991bis
>>>
>>>
>>> Another case would be :
>>>
>>>
>>> 
>>>
>>> typedef percentage {
>>>
>>>        type decimal64 {
>>>
>>>           fraction-digits 5;
>>>
>>>           range "0..100";
>>>
>>>       }
>>>
>>> Ñöº: netmod [mailto:[email-masked]] ãh Xufeng Liu
>>> Ñöô: 2018t116å 3:49
>>> 6öº: [email-masked]
>>> : NETMOD WG <[email-masked]>
>>> ;: Re: [netmod] for a future rfc6991bis
>>>

---

From: Balázs Lengyel <[email-masked]>
Date: Tue, 13 Nov 2018 13:33:01 +0000

Hello,

In some cases I want a percentage without fractions. This could be 
defined using range, by specifying the numbers 0 | 1 | 2 ... 99 | 100 in 
the range's argument.

     typedef percent-short {
       type percent { range 0 | 1 | 2 ... 99 | 100; }  // didn't type out all the 101 integer values :-)
     }

regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: [email-masked]

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 13 Nov 2018 15:07:09 +0100

On Tue, Nov 13, 2018 at 01:33:01PM +0000, Balázs Lengyel wrote:
> Hello,
> 
> In some cases I want a percentage without fractions. This could be defined
> using range, by specifying the numbers 0 | 1 | 2 ... 99 | 100 in the range's
> argument.
> 
>     typedef percent-short {

I guess we need to settle on a small number of percentage types that
people find useful and then module authors hopefully find what they
need. I am not sure that listing 101 numbers is a good pattern to use
(although it does achieve what you want). For percentages that have no
fraction, you likely want to derive from a base type that is efficient
to encode for binary encodings such as CBOR.

/js

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 13 Nov 2018 16:03:23 +0000

On 11/13/18, 9:07 AM, "netmod on behalf of Juergen Schoenwaelder" <[email-masked] on behalf of [email-masked]> wrote:

Or simply define a type with a base type of unit8 type and a range of 0-100. 

Acee 

    /js

---

From: Alex Campbell <[email-masked]>
Date: Tue, 13 Nov 2018 23:45:39 +0000

Does a percentage really need a single standard type in the first place? How about "units percent;"?

________________________________________
From: netmod <[email-masked]> on behalf of Acee Lindem (acee) <[email-masked]>
Sent: Wednesday, 14 November 2018 5:03 a.m.
To: Juergen Schoenwaelder; Balázs Lengyel
Cc: NETMOD WG
Subject: Re: [netmod] for a future rfc6991bis

Acee

    /js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 14 Nov 2018 09:10:24 +0100 (CET)

Hi,

> place? How about "units percent;"?

At this point, after hearing about how different modules have
differing requirement on this type, I tend to agree.

/martin

> On 11/13/18, 9:07 AM, "netmod on behalf of Juergen Schoenwaelder"
> <[email-masked] on behalf of
> [email-masked]> wrote:
> 
>     > defined

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 14 Nov 2018 09:16:08 +0100

> differing requirement on this type, I tend to agree.

+1

Or even "units %;"

Lada

> >     >       type percent { range 0 | 1 | 2 ... 99 | 100; } // didn't type
> > out
> >     >       all the 101 integer values :-)
> >     >     }
> >     >
> > 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67

---

From: Robert Wilton <[email-masked]>
Date: Thu, 29 Nov 2018 11:03:45 +0000

Hi Juergen,

YANG library currently defines the type "revision-identifer".  Is this a 
typedef that should logically migrate to rfc6991bis?

Thanks,
Rob

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 29 Nov 2018 17:34:57 +0100

Rob,

I have added this to my list of things to look at. Whether we do this
or not may also depend on how the final date solution will look like
and whether people feel it is worth to move this out of rfc6991bis,
i.e., such a YANG revision-identifer is useful for modules that do
not want to depend on rfc6991bis.

/js

---

From: Robert Wilton <[email-masked]>
Date: Thu, 29 Nov 2018 16:43:01 +0000

> not want to depend on rfc6991bis.

Thanks.  Sounds sensible to me.

Rob

---

From: Balázs Lengyel <[email-masked]>
Date: Fri, 30 Nov 2018 10:21:00 +0000

Hello,

In a similar manner we found multiple uses for the ietf-netconf-acm:node-instance-identifier.
We imported nacm just to reuse this type.

Anyone else interested?

regards Balazs

On 2018. 11. 29. 12:03, Robert Wilton
wrote:

Hi
Juergen,

YANG library currently defines the type "revision-identifer".  Is
this a typedef that should logically migrate to rfc6991bis?

Thanks,

Rob

On Wed, 2018-11-14 at 09:10 +0100, Martin
Bjorklund wrote:

Hi,

Does a percentage really need a single
standard type in the first

place? How about "units percent;"?

+1

Or even "units %;"

Lada

/martin

From: netmod <[email-masked]> on behalf of
Acee Lindem (acee)

<[email-masked]>

Cc: NETMOD WG

On 11/13/18, 9:07 AM, "netmod on behalf of Juergen
Schoenwaelder"

On Tue, Nov 13, 2018 at 01:33:01PM +0000, Balázs

> using range, by specifying the numbers 0 | 1 | 2
... 99 | 100 in the

> range's

out

I guess we need to settle on a small number of
percentage types that

people find useful and then module authors hopefully
find what they

need. I am not sure that listing 101 numbers is a good
pattern to use

(although it does achieve what you want). For
percentages that have no

fraction, you likely want to derive from a base type
that is efficient

Or simply define a type with a base type of unit8 type and a
range of

0-100.

Acee

/js

--

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/>

netmod mailing list

[email-masked]

netmod mailing list

[email-masked]

netmod mailing list

[email-masked]

netmod mailing list

[email-masked]

netmod mailing list

[email-masked]

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 30 Nov 2018 11:25:44 +0100 (CET)

Balázs Lengyel <[email-masked]> wrote:
> Hello,
> 
> In a similar manner we found multiple uses for the
> ietf-netconf-acm:node-instance-identifier. We
> imported nacm just to reuse this type.
> Anyone else interested?

Yes, this is a useful type that is not just NACM-specific.  We also
use in various places.

/martin

> 
> regards Balazs
> 
> On 2018. 11. 29. 12:03, Robert Wilton wrote:
> 
>  Hi Juergen,
> 
>  YANG library currently defines the type "revision-identifer". Is this a typedef that should
>  logically migrate to rfc6991bis?
> 
>  Thanks,
>  Rob
>

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 30 Nov 2018 12:56:48 +0100

This is already on my list (was already proposed by Balázs).

/js