Re: [netmod] for a future rfc6991bis

"Yemin (Amy)" <amy.yemin@huawei.com> Wed, 07 November 2018 07:50 UTC

Return-Path: <amy.yemin@huawei.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5ACD0129619 for <netmod@ietfa.amsl.com>; Tue, 6 Nov 2018 23:50:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXeRXCqV51w3 for <netmod@ietfa.amsl.com>; Tue, 6 Nov 2018 23:50:06 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [185.176.76.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F033F127333 for <netmod@ietf.org>; Tue, 6 Nov 2018 23:50:05 -0800 (PST)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id A0C5B5D8B79FD; Wed, 7 Nov 2018 07:50:02 +0000 (GMT)
Received: from DGGEMM421-HUB.china.huawei.com (10.1.198.38) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.408.0; Wed, 7 Nov 2018 07:50:02 +0000
Received: from DGGEMM528-MBX.china.huawei.com ([169.254.8.232]) by dggemm421-hub.china.huawei.com ([10.1.198.38]) with mapi id 14.03.0415.000; Wed, 7 Nov 2018 15:49:54 +0800
From: "Yemin (Amy)" <amy.yemin@huawei.com>
To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>
CC: Qin Wu <bill.wu@huawei.com>, Xufeng Liu <xufeng.liu.ietf@gmail.com>, "balazs.lengyel@ericsson.com" <balazs.lengyel@ericsson.com>, NETMOD WG <netmod@ietf.org>
Thread-Topic: [netmod] for a future rfc6991bis
Thread-Index: AdR1b1B75pZToCjlLEK5aT+9YAPiFwAB1JzUAAhlL4AANTEPSw==
Date: Wed, 7 Nov 2018 07:49:54 +0000
Message-ID: <9C5FD3EFA72E1740A3D41BADDE0B461FCFA78BFA@DGGEMM528-MBX.china.huawei.com>
References: <B8F9A780D330094D99AF023C5877DABA9B0FC256@nkgeml513-mbs.china.huawei.com> <9C5FD3EFA72E1740A3D41BADDE0B461FCFA7803B@DGGEMM528-MBX.china.huawei.com>, <20181106141613.zqy5xmq7qvahzzpz@anna.jacobs.jacobs-university.de>
In-Reply-To: <20181106141613.zqy5xmq7qvahzzpz@anna.jacobs.jacobs-university.de>
Accept-Language: zh-CN, en-US
Content-Language: zh-CN
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.126.173.20]
Content-Type: text/plain; charset="gb2312"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/-QgTZerBIW7qOO5ssJF29pVTW0c>
Subject: Re: [netmod] for a future rfc6991bis
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 07 Nov 2018 07:50:13 -0000

Hi Juergen,

What we don't like in current RFC6991 is the type is uint8 which doesn't allow fraction. 
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?

BR,
Amy
________________________________________
发件人: Juergen Schoenwaelder [j.schoenwaelder@jacobs-university.de]
发送时间: 2018年11月6日 22:16
收件人: Yemin (Amy)
抄送: Qin Wu; Xufeng Liu; balazs.lengyel@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-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/>