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-bounces@ietf.org] 代表 Qin Wu [bill.wu@huawei.com]
> 发送时间: 2018年11月6日 9:25
> 收件人: Xufeng Liu; balazs.lengyel@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-bounces@ietf.org] 代表 Xufeng Liu
> 发送时间: 2018年11月6日 3:49
> 收件人: balazs.lengyel@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.lengyel@ericsson.com<mailto:balazs.lengyel@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 <ietfc@btconnect.com<mailto:ietfc@btconnect.com>> wrote:
> ---- Original Message -----
> From: "Juergen Schoenwaelder" <j.schoenwaelder@jacobs-university.de<mailto:j.schoenwaelder@jacobs-university.de>>
> To: "Kent Watsen" <kwatsen@juniper.net<mailto:kwatsen@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.Lengyel@ericsson.com<mailto:Balazs.Lengyel@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/>