Re: [netmod] for a future rfc6991bis

[Qin Wu <[e-mail]>]

-----邮件原件-----
发件人: netmod [mailto:[e-mail]] 代表 Per Hedeland
发送时间: 2018年11月7日 15:57
收件人: Juergen Schoenwaelder <[e-mail]>
抄送: NETMOD WG <[e-mail]>
主题: Re: [netmod] for a future rfc6991bis

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

[Qin]: Section 9.2.4 said:
"
If a range restriction is applied to a type that is
   already range-restricted, the new restriction MUST be equally
   limiting or more limiting, i.e., raising the lower bounds, reducing
   the upper bounds, removing explicit values or ranges, or splitting
   ranges into multiple ranges with intermediate gaps.
"
I am not sure the above example really violates the rule described above.

>      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:j.schoenwaelder@jacobs-
>>> university.de>>
>>> 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/>
> 

_______________________________________________
netmod mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/netmod