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>
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> wrote:
>
>> ---- Original Message -----
>> From: "Juergen Schoenwaelder" <j.schoenwael...@jacobs-university.de>
>> To: "Kent Watsen" <kwat...@juniper.net>
>> Cc: <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
>> > https://www.ietf.org/mailman/listinfo/netmod
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
> _______________________________________________
> netmod mailing listnetmod@ietf.orghttps://www.ietf.org/mailman/listinfo/netmod
>
> --
> Balazs Lengyel Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909 email: balazs.leng...@ericsson.com
>
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
