On 2018-11-07 16:56, Qin Wu wrote:
> -----®öö-----
> Ñöº: netmod [mailto:netmod-boun...@ietf.org] ãh Per Hedeland
> Ñöô: 2018t117å 15:57
> 6öº: Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de>
> : NETMOD WG <netmod@ietf.org>
> ;: 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.
No, it's the example *below* - that Juergen was referring to above with
the "it is not clear whether YANG 1.1 really allows this" that I replied
to - that does. I.e. restricting a decimal64 type with a fraction-digits
statement is not allowed.
--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 [j.schoenwael...@jacobs-university.de]
>>> Ñöô: 2018t116å 22:16
>>> 6öº: Yemin (Amy)
>>> : Qin Wu; Xufeng Liu; balazs.leng...@ericsson.com; 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 [netmod-boun...@ietf.org] ãh Qin Wu [bill...@huawei.com]
>>>> Ñöô: 2018t116å 9:25
>>>> 6öº: Xufeng Liu; balazs.leng...@ericsson.com
>>>> : 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:netmod-boun...@ietf.org] ãh Xufeng Liu
>>>> Ñöô: 2018t116å 3:49
>>>> 6öº: balazs.leng...@ericsson.com
>>>> : NETMOD WG <netmod@ietf.org>
>>>> ;: 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
>>>> <balazs.leng...@ericsson.com<mailto:balazs.leng...@ericsson.com>> 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
>>>> <ie...@btconnect.com<mailto:ie...@btconnect.com>> wrote:
>>>> ---- Original Message -----
>>>> From: "Juergen Schoenwaelder"
>>>> <j.schoenwael...@jacobs-university.de<mailto:j.schoenwaelder@jacobs-
>>>> university.de>>
>>>> To: "Kent Watsen" <kwat...@juniper.net<mailto:kwat...@juniper..net>>
>>>> Cc: <netmod@ietf.org<mailto:netmod@ietf.org>>
>>>> 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
>>>>> netmod@ietf.org<mailto:netmod@ietf.org>
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org<mailto:netmod@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> netmod mailing list
>>>>
>>>> netmod@ietf.org<mailto:netmod@ietf.org>
>>>>
>>>> https://www.ietf.org/mailman/listinfo/netmod<UrlBlockedError.aspx>
>>>>
>>>> --
>>>>
>>>> Balazs Lengyel Ericsson Hungary Ltd.
>>>>
>>>> Senior Specialist
>>>>
>>>> Mobile: +36-70-330-7909 email:
>>>> balazs.leng...@ericsson.com<mailto:balazs.leng...@ericsson.com>
>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>>
>>> --
>>> 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
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
