Hello,In some cases I want a percentage without fractions. This could be defined using range, by specifying the numbers 0 | 1 | 2 ... 99 | 100 in the range's argument.
typedef percent-short {
type percent { range 0 | 1 | 2 ... 99 | 100; } // didn't type out all
the 101 integer values :-)
}
regards Balazs
On 2018. 11. 07. 9: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): 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. /jsBR, Amy ________________________________________ 发件人: Juergen Schoenwaelder [[email protected]] 发送时间: 2018年11月6日 22:16 收件人: Yemin (Amy) 抄送: Qin Wu; Xufeng Liu; [email protected]; 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 [[email protected]] 代表 Qin Wu [[email protected]] 发送时间: 2018年11月6日 9:25 收件人: Xufeng Liu; [email protected] 抄送: 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:[email protected]] 代表 Xufeng Liu 发送时间: 2018年11月6日 3:49 收件人: [email protected] 抄送: NETMOD WG <[email protected]> 主题: 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 <[email protected]<mailto:[email protected]>> 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 <[email protected]<mailto:[email protected]>> wrote: ---- Original Message ----- From: "Juergen Schoenwaelder" <[email protected]<mailto:[email protected]>> To: "Kent Watsen" <[email protected]<mailto:[email protected]>> Cc: <[email protected]<mailto:[email protected]>> Sent: Tuesday, October 30, 2018 10:14 AMOn Tue, Oct 30, 2018 at 12:05:17AM +0000, Kent Watsen wrote:In addition, it might be good to introduce [inet?] types for RFC5322(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 ona 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 PetchIt 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 [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod_______________________________________________ netmod mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod _______________________________________________ netmod mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/netmod<UrlBlockedError.aspx> -- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: [email protected]<mailto:[email protected]> _______________________________________________ netmod mailing list [email protected] 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/>
-- Balazs Lengyel Ericsson Hungary Ltd. Senior Specialist Mobile: +36-70-330-7909 email: [email protected]
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
