Re: [netmod] for a future rfc6991bis
Per Hedeland <per@hedeland.org> Wed, 07 November 2018 16:08 UTC
Return-Path: <per@hedeland.org>
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 8DAD11274D0 for <netmod@ietfa.amsl.com>; Wed, 7 Nov 2018 08:08:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=outbound.mailhop.org
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 8WahLD5iBeoB for <netmod@ietfa.amsl.com>; Wed, 7 Nov 2018 08:08:53 -0800 (PST)
Received: from outbound2m.ore.mailhop.org (outbound2m.ore.mailhop.org [54.149.155.156]) (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 C6C42130DC8 for <netmod@ietf.org>; Wed, 7 Nov 2018 08:08:53 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; t=1541606933; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=c7hKNB+aF2cS06aTKb8JSzjTp/oKPd1MHOiSaaP2W+SKCT1iJggeUX9Qo8sTlmJFJ3Yswjc7pL5sK +TBYUnXbTvazG9R4covKiVim0p3MTGf553GUspKaHciBnz12BHmTZo8i/2EjDY64tROe7fObDfNH7S FqMUXfb2EAfODEoEyXjiNBI2reMympkC8U1R4Nv5jGSVCiJce6nWL+zVjs1OUePs7UL7n9/HJe6Ybc n1vx6rxUUegmaVvXRXq8tCF+fz50IO8h9MqgAtLl5G9W91x2BPJsQPmQqhg26ySiAw4+UCXFgyGeQ8 nECpa5X+dYtf5qRw7/qKnpdFKCYxrWg==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:cc:to:subject:dkim-signature:from; bh=YtmeCK/l3hmSWTFVhTuHTHYmnvZMF27SHt+7PzLxnm8=; b=nBKHjHm7FTtLuYBvLD9/cgroYmOAmTcT1bD3Xo9W4D415D71FD33EbTqijWJ4x6YmIWlFdAJh8Yj1 wrlwYBERcRTOgZV+ZY5KtsCx0kNcalnJff1mjOHfexhtuy/Ian5BVwSmw8+2pLuwIZgDuk6eIk0jw+ tAG9S8DvMeBTqcO6MhOOQucs+dwc446IyjXMRMMW2hyf8VqJkpaxEQcQUYLyJIuicM1r11ccPb1mlF gZNCOoWRvoPUbqFogGoX1tDx1LScLh30fX1WSG6GgvKQzyXBCuqcQYIlkRPQF/8dsOPpPre3iW0IOI sfTnTy2UTS7jOrlelKNrwB/y64Mgkqg==
ARC-Authentication-Results: i=1; outbound2.ore.mailhop.org; spf=none smtp.mailfrom=hedeland.org smtp.remote-ip=81.228.152.101; dmarc=none header.from=hedeland.org; arc=none header.oldest-pass=0;
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:content-type:in-reply-to:mime-version:date: message-id:from:references:cc:to:subject:from; bh=YtmeCK/l3hmSWTFVhTuHTHYmnvZMF27SHt+7PzLxnm8=; b=GCiJx2jB9Xi8l4uHPx46pWea0yU9bNYhVzULbXUIrQVDtrDg2w074rALoihLW28paRHnpRZuakaQ8 9bPQUrFHK0v0f33AizAhxjHilFvHRjn8tGE965WQmwnefLxwL58FVU6gZHXKBm2hnQXjrYTRzHEy81 Fwch+9PH6wuKByacBrGEeOugpXvDn5rTZmH9Oq/rCN7r9PKPXXvPdIwb+rpbsV/RIHBanRQstTbz7J 0leqW4ysMAIKZYUXqTwtZm0MWp6SKtITyDcY+LahzCjrxCdqfWtZHE/0CYcqr2xQ4bCtWMyRPWMGAG uFnihTu1RjpTI+fUFZgj7gGzu1uQE6w==
X-MHO-RoutePath: cGVyaGVkZWxhbmQ=
X-MHO-User: 68f5eb88-e2a7-11e8-a630-335f030b21f2
X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information
X-Originating-IP: 81.228.152.101
X-Mail-Handler: DuoCircle Outbound SMTP
Received: from hedeland.org (unknown [81.228.152.101]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 68f5eb88-e2a7-11e8-a630-335f030b21f2; Wed, 07 Nov 2018 16:08:51 +0000 (UTC)
Received: from mars.tail-f.com ([173.38.220.34]) (authenticated bits=0) by tellus.hedeland.org (8.15.2/8.15.2) with ESMTPSA id wA7G8kaO071446 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Wed, 7 Nov 2018 17:08:47 +0100 (CET) (envelope-from per@hedeland.org)
X-Authentication-Warning: tellus.hedeland.org: Host [173.38.220.34] claimed to be mars.tail-f.com
To: Qin Wu <bill.wu@huawei.com>
Cc: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de>, NETMOD WG <netmod@ietf.org>
References: <B8F9A780D330094D99AF023C5877DABA9B1009BD@nkgeml513-mbs.china.huawei.com>
From: Per Hedeland <per@hedeland.org>
Message-ID: <99242f6c-5886-dd48-e42f-3f478665058e@hedeland.org>
Date: Wed, 07 Nov 2018 17:08:41 +0100
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <B8F9A780D330094D99AF023C5877DABA9B1009BD@nkgeml513-mbs.china.huawei.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/FDakjQE91ReHWgMvIixk_ZRkNsA>
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 16:08:57 -0000
On 2018-11-07 16:56, Qin Wu wrote: > -----®öö----- > Ñöº: netmod [mailto:netmod-bounces@ietf.org] ãh Per Hedeland > Ñöô: 2018t117å 15:57 > 6öº: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> > : NETMOD WG <netmod@ietf.org> > ;: Re: [netmod] for a future rfc6991bis > > On 2018-11-07 09: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): > > I believe it is quite clear that this is *not* allowed: > > 9.3.3. Restrictions > > A decimal64 type can be restricted with the "range" statement > (Section 9.2.4). > > --Per > > [Qin]: Section 9.2.4 said: > " > If a range restriction is applied to a type that is > already range-restricted, the new restriction MUST be equally > limiting or more limiting, i.e., raising the lower bounds, reducing > the upper bounds, removing explicit values or ranges, or splitting > ranges into multiple ranges with intermediate gaps. > " > I am not sure the above example really violates the rule described above. No, it's the example *below* - that Juergen was referring to above with the "it is not clear whether YANG 1.1 really allows this" that I replied to - that does. I.e. restricting a decimal64 type with a fraction-digits statement is not allowed. --Per >> 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 [j.schoenwaelder@jacobs-university.de] >>> Ñöô: 2018t116å 22:16 >>> 6öº: 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] ãh Qin Wu [bill.wu@huawei.com] >>>> Ñöô: 2018t116å 9:25 >>>> 6öº: 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] ãh Xufeng Liu >>>> Ñöô: 2018t116å 3:49 >>>> 6öº: 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/> >> > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod >
- [netmod] for a future rfc6991bis Kent Watsen
- Re: [netmod] for a future rfc6991bis Juergen Schoenwaelder
- Re: [netmod] for a future rfc6991bis Kent Watsen
- Re: [netmod] for a future rfc6991bis Juergen Schoenwaelder
- Re: [netmod] for a future rfc6991bis Joel Jaeggli
- Re: [netmod] for a future rfc6991bis Ladislav Lhotka
- Re: [netmod] for a future rfc6991bis Juergen Schoenwaelder
- Re: [netmod] for a future rfc6991bis Balázs Lengyel
- Re: [netmod] for a future rfc6991bis Qin Wu
- Re: [netmod] for a future rfc6991bis Juergen Schoenwaelder
- Re: [netmod] for a future rfc6991bis Acee Lindem (acee)
- Re: [netmod] for a future rfc6991bis Qin Wu
- Re: [netmod] for a future rfc6991bis Acee Lindem (acee)
- Re: [netmod] for a future rfc6991bis Qin Wu
- Re: [netmod] for a future rfc6991bis Juergen Schoenwaelder
- Re: [netmod] for a future rfc6991bis Qin Wu
- Re: [netmod] for a future rfc6991bis Juergen Schoenwaelder
- Re: [netmod] for a future rfc6991bis Robert Wilton
- Re: [netmod] for a future rfc6991bis Qin Wu
- Re: [netmod] for a future rfc6991bis Acee Lindem (acee)
- Re: [netmod] for a future rfc6991bis tom petch
- Re: [netmod] for a future rfc6991bis Xufeng Liu
- Re: [netmod] for a future rfc6991bis Juergen Schoenwaelder
- Re: [netmod] for a future rfc6991bis Balázs Lengyel
- Re: [netmod] for a future rfc6991bis Xufeng Liu
- Re: [netmod] for a future rfc6991bis Juergen Schoenwaelder
- Re: [netmod] for a future rfc6991bis Qin Wu
- Re: [netmod] for a future rfc6991bis Yemin (Amy)
- Re: [netmod] for a future rfc6991bis Juergen Schoenwaelder
- Re: [netmod] for a future rfc6991bis Yemin (Amy)
- Re: [netmod] for a future rfc6991bis Juergen Schoenwaelder
- Re: [netmod] for a future rfc6991bis Per Hedeland
- Re: [netmod] for a future rfc6991bis Qin Wu
- Re: [netmod] for a future rfc6991bis Per Hedeland
- Re: [netmod] for a future rfc6991bis Balázs Lengyel
- Re: [netmod] for a future rfc6991bis Juergen Schoenwaelder
- Re: [netmod] for a future rfc6991bis Acee Lindem (acee)
- Re: [netmod] for a future rfc6991bis Alex Campbell
- Re: [netmod] for a future rfc6991bis Martin Bjorklund
- Re: [netmod] for a future rfc6991bis Ladislav Lhotka
- Re: [netmod] for a future rfc6991bis Robert Wilton
- Re: [netmod] for a future rfc6991bis Juergen Schoenwaelder
- Re: [netmod] for a future rfc6991bis Robert Wilton
- Re: [netmod] for a future rfc6991bis Balázs Lengyel
- Re: [netmod] for a future rfc6991bis Martin Bjorklund
- Re: [netmod] for a future rfc6991bis Juergen Schoenwaelder
- Re: [netmod] for a future rfc6991bis tom petch
- Re: [netmod] for a future rfc6991bis Juergen Schoenwaelder
- Re: [netmod] for a future rfc6991bis Acee Lindem (acee)