Re: [netmod] for a future rfc6991bis

[Per Hedeland <[e-mail]>]

On 2018-11-07 09:34, Juergen Schoenwaelder wrote:
> 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):

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

>      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
> 
>> BR,
>> Amy
>> ________________________________________
>> Ñöº: Juergen Schoenwaelder [[e-mail]]
>> Ñ
öô: 2018t116å 22:16
>> 6öº: Yemin (Amy)
>> „
: Qin Wu; Xufeng Liu; [e-mail]; NETMOD WG
>> ;˜: Re: [netmod] for a future rfc6991bis
>>
>> 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
>>
>> On Tue, Nov 06, 2018 at 02:21:33AM +0000, Yemin (Amy) wrote:
>>> 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 [[e-mail]] ãh Qin Wu [[e-mail]]
>>> Ñ
öô: 2018t116å 9:25
>>> 6öº: Xufeng Liu; [e-mail]
>>> „
: NETMOD WG
>>> ;˜: Re: [netmod] for a future rfc6991bis
>>>
>>>
>>> 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:[e-mail]] ãh Xufeng Liu
>>> Ñ
öô: 2018t116å 3:49
>>> 6öº: [e-mail]
>>> „
: NETMOD WG <[e-mail]>
>>> ;˜: 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 <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>> wrote:
>>> ---- Original Message -----
>>> From: "Juergen Schoenwaelder" <[e-mail]<mailto:[e-mail]>>
>>> To: "Kent Watsen" <[e-mail]<mailto:kwatsen@juniper..net>>
>>> Cc: <[e-mail]<mailto:[e-mail]>>
>>> 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: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>>>> Fax:   [phone]         <https://www.jacobs-university.de/>
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> [e-mail]<mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> [e-mail]<mailto:[e-mail]>
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>>
>>> _______________________________________________
>>>
>>> netmod mailing list
>>>
>>> [e-mail]<mailto:[e-mail]>
>>>
>>> https://www.ietf.org/mailman/listinfo/netmod<UrlBlockedError.aspx>
>>>
>>> --
>>>
>>> Balazs Lengyel                       Ericsson Hungary Ltd.
>>>
>>> Senior Specialist
>>>
>>> Mobile: [phone]              email: [e-mail]<mailto:[e-mail]>
>>
>>> _______________________________________________
>>> netmod mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>
>> --
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   [phone]         <https://www.jacobs-university.de/>
>