Re: [netmod] for a future rfc6991bis

[Juergen Schoenwaelder <[e-mail]>]

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.

/js

> BR,
> Amy
> ________________________________________
> 发件人: Juergen Schoenwaelder [[e-mail]]
> 发送时间: 2018年11月6日 22:16
> 收件人: 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]] 代表 Qin Wu [[e-mail]]
> > 发送时间: 2018年11月6日 9:25
> > 收件人: 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]] 代表 Xufeng Liu
> > 发送时间: 2018年11月6日 3:49
> > 收件人: [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:[e-mail]>>
> > 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/>

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
Fax:   [phone]         <https://www.jacobs-university.de/>