Re: [netmod] Eric Rescorla's No Objection on draft-ietf-netmod-schema-mount-12: (with COMMENT)

[Adrian Farrel]

Thanks!

Was a useful Discuss, and good to be moving the cluster forward.

Adrian

> -Original Message-
> From: netmod [mailto:netmod-boun...@ietf.org] On Behalf Of Eric Rescorla
> Sent: 08 November 2018 04:28
> To: The IESG
> Cc: netmod-cha...@ietf.org; netmod@ietf.org; joe...@gmail.com; draft-ietf-
> netmod-schema-mo...@ietf.org
> Subject: [netmod] Eric Rescorla's No Objection on draft-ietf-netmod-schema-
> mount-12: (with COMMENT)
> 
> Eric Rescorla has entered the following ballot position for
> draft-ietf-netmod-schema-mount-12: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thank you for addressing my DISCUSS
> 
> 
> ___
> 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

Re: [netmod] Eric Rescorla's No Objection on draft-ietf-netmod-schema-mount-12: (with COMMENT)

[joel jaeggli]

Thanks all

Glad that was acceptable.

Joel 


> On Nov 8, 2018, at 11:27, Eric Rescorla  wrote:
> 
> Eric Rescorla has entered the following ballot position for
> draft-ietf-netmod-schema-mount-12: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thank you for addressing my DISCUSS
> 
> 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

[netmod] Eric Rescorla's No Objection on draft-ietf-netmod-schema-mount-12: (with COMMENT)

[Eric Rescorla]

Eric Rescorla has entered the following ballot position for
draft-ietf-netmod-schema-mount-12: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-netmod-schema-mount/



--
COMMENT:
--

Thank you for addressing my DISCUSS


___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] New Version Notification for draft-verdt-netmod-yang-versioning-reqs-01.txt

[Andy Bierman]

On Sun, Nov 4, 2018 at 4:39 AM, Balázs Lengyel 
wrote:

> Implementing 3.2 will be very costly. IMHO Ericsson will not implement it..
> We will do our utmost to avoid NBC changes, but if they do happen, I don't
> believe we would support multiple versions.
>
> If the data models are sufficiently NBC e.g. changing a boolean to an
> integer 3.2 may not even be possible. The underlying data that drives the
> device may be an integer or a boolean, but not both. (Strange mapping may
> be possible to imagine, but they will not always work.)
>


IMO the requirements and solutions drafts are both too abstract.
It would help if the authors could point to existing RFCs or I-Ds where a
published module needs specific NBC changes.

The intended usage of the status-stmt in YANG 1.1 seems to be for NBC
changes
to be made by introducing a replacement (maybe sibling) node and changing
the replaced
node status to deprecated.

The requirements draft is not clear at all when this practice should be
followed
and when it is OK to simply change the data node and not deprecate it at
all.
IMO the latter is only OK if the change is truly a bugfix and implementation
of the previous version SHOULD NOT be done.

Even though this means a server MAY implement the old bugfixed version,
that does not
mean an operator gets to choose both versions active at once in a given
server.
It is reasonable to let the operator configure which version to use.

The solution proposal does not indicate how a protocol would support REQ.
3.2.
E.g., how to say "I mean foo the integer not foo the boolean"

regards Balazs
>
>
>
Andy


> On 2018. 10. 27. 1:15, Robert Wilton wrote:
>
>
>
> On 26/10/2018 17:35, Andy Bierman wrote:
>
>
>
> On Fri, Oct 26, 2018 at 2:33 AM, Juergen Schoenwaelder <
> j.schoenwael...@jacobs-university.de> wrote:
>
>> Let me add that there was large disagreement what a bug fix is in the
>> design team. Hence, any text that talks about 'bug fixes' is ambiguous
>> and of limited value to achieve consensus. (Or we may find consensus
>> but then not agree on what we have found consensus on.)
>>
>> To be more concrete, I learned that Rob's notion of a bug fix is very
>> different from my notion of a bug fix. I think it is important for
>> having a productive discussion to be aware of this.
>>
>> For me, a bug fix is rather limited, i.e., fixing something where the
>> correct intention was clear but the model did not properly capture the
>> intention correctly, i.e., roughly what we can do with errata in the
>> IETF. I think Rob understands bug fixes in a much broader sense,
>> including fixes to what essentially are in my view module design
>> errors.
>>
>> With my narrow definition of bug fixes, bug fixes are essentially
>> backwards compatible (even if they may violate RFC 7950 rules - but as
>> long as the original intention was clear, we can be flexible).
>>
>> With Rob's notion of bug fixes, we have to handle them as part of the
>> versioning system since they may be non-backwards compatible.
>>
>>
>
> IMO requirements 3.1 and 3.2 are the most  important and have the most
> impact
> on the solution space. I do not agree with either of these requirements.
>
> OK.
>
> For 3.1, I think that just means that the solution has to be backwards
> compatible with existing clients (e.g. don't change the protocols in a non
> backwards compatible way).
>
>
> Implementing multiple non-compatible revisions of a module on a server
> sounds hard,
> not to mention that it breaks RFC 7950 rules.
>
> Completely agree that it will be hard.  I envisage that it will optional
> for servers to implement this.
>
> The current protocols do not support the
> ability to specify different versions of the same QName. This change makes
> YANG validation
> much to difficult to specify and implement (as that has to be rewritten as
> well).
>
> The way that I think of one solution for this problem is using datastore
> schema (as per the NMDA definition):
>
> Say for release X, the server natively supports Module A@ver1.0.0 and
> ModuleB@ver1.0.0, call this schema X.
> For release Y, the server natively supports Module A@ver1.1.0 and
> ModuleB@ver2.0.0, call this schema Y.
>
> When a client connects it chooses which schema it wants to use, X, Y, or
> latest.  If it doesn't specify then perhaps it uses the earliest schema (to
> handle requirement 3.1).
>
> If the client wants to use X, then the server has to translate the request
> into the equivalent request using schema Y instead.  Perhaps the server has
> to validate the config both in the context of X and Y.
>
> If the clients wants to use Y then it just talks to the server normally,
> i.e. as it does today.
>
> I think that this is logically the equivalent model mapping that clients
> would have to do to support multiple server revisions.  Yes, I think that
> it is complex.  No, I'm not sure how many vendors will decide to implement
> this, but I think that it is OK to require the solution to specify how this
> is 

Re: [netmod] some comments on netmod-base-notification-nmda (validation after commit response, etc)

[Juergen Schoenwaelder]

RFC 8342 says:

   However,
MUST always be a valid configuration data tree, as defined
   in Section 8.1 of [RFC7950].

is tightly coupled to .  Whenever data is written
   to , the server MUST also immediately update and validate
   .

MAY also be updated independently of  if the
   effect of a configuration transformation changes, but  MUST
   always be a valid configuration data tree, as defined in Section 8.1
   of [RFC7950].

   For simple implementations,  and  are identical.

/js

On Wed, Nov 07, 2018 at 03:37:57PM +, Qin Wu wrote:
> 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Sterne, Jason (Nokia - 
> CA/Ottawa)
> 发送时间: 2018年11月6日 10:56
> 收件人: netmod@ietf.org
> 主题: [netmod] some comments on netmod-base-notification-nmda (validation after 
> commit response, etc)
> 
> Hello,
> 
> The draft mentions that "It is possible that some configuration could not be 
> applied to  due to either validation issues, or missing resource 
> etc."
> 
> But wouldn't validation errors cause an error response to the commit RPC? I'm 
> not clear why there would be validation later in the commit/apply process 
> that wasn't part of the decision to reply OK/NOK to the commit.
> 
> 
> [Qin]:The configuration is written into running via commit operation, but 
> commit operation doesn’t equal to validate operation. Validate operation is 
> defined in RFC6241 to validate, e.g., candidate datastore or the  
> element containing the complete configuration in the edit config. But RFC6241 
> doesn’t discuss how validate operation can be applied to intended or other 
> NMDA datastore since NMDA is introduced after RFC6241 gets published.
> 
> 
> 
> As described in RFC8342 and figure 2 of RFC8342
> 
> “Whenever data is written
> 
>to , the server MUST also immediately update and validate
> 
>.
> 
> “
> 
> So validate  takes place after commit operation. It involves in 
> configuration transformations to  before intended validation 
> operation.
> 
> The draft also implies that the process of moving config from running -> 
> intended -> operational is decoupled from the application of a candidate -> 
> running.
> - Do systems reply OK/NOK to a commit before config is moved from 
> running->intended->operational ?
> [Qin]: reply OK/NOK indicates whether configuration is written into running 
> but doesn’t tell us whether validation performed on intended is success or 
> failure, validate operation defined in RFC6241 on candidate datastore may be 
> different from Validation operation on intended since it clearly happens at 
> different stage, sure validate operation can be applied to intended, but no 
> standards explicitly specify whether validate operation can be applied to 
> intended.
> This is something we can update in this document.
> 
> - If so, then maybe it isn't correct to have a username in the notifications. 
> A specific user/session did the commit, but then if the commit process ends 
> after candidate->running (i.e. the reply happens at that point), then isn't 
> it really the system moving the config from running->intended->operational?
> [Qin]: See above.
> Jason

> ___
> 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 

___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] for a future rfc6991bis

[Per Hedeland]

On 2018-11-07 16:56, Qin Wu wrote:
> -®öŸö-
> Ñöº: netmod [mailto:netmod-boun...@ietf.org] ãh Per Hedeland
> Ñ
öô: 2018t117å 15:57
> 6öº: Juergen Schoenwaelder 
> „
: NETMOD WG 
> ;˜: Re: [netmod] for a future rfc6991bis
> 
> On 2018-11-07 09:34, Juergen Schoenwaelder wrote:
>> On Wed, Nov 07, 2018 at 07:49:54AM +, Yemin (Amy) wrote:
>>
>>> For the range, if the defintion can cover the our range(0..99.), 
>>> 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.schoenwael...@jacobs-university.de]
>>> Ñ
öô: 2018t116å 22:16
>>> 6öº: Yemin (Amy)
>>> „
: Qin Wu; Xufeng Liu; balazs.leng...@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 +, 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-boun...@ietf.org] ãh Qin Wu [bill...@huawei.com]
 Ñ
öô: 2018t116å 9:25
 6öº: Xufeng Liu; balazs.leng...@ericsson.com
 „
: NETMOD WG
 ;˜: Re: [netmod] for a future rfc6991bis


 Another case would be :


 

 typedef percentage {

Re: [netmod] for a future rfc6991bis

[Qin Wu]

-邮件原件-
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Per Hedeland
发送时间: 2018年11月7日 15:57
收件人: Juergen Schoenwaelder 
抄送: NETMOD WG 
主题: Re: [netmod] for a future rfc6991bis

On 2018-11-07 09:34, Juergen Schoenwaelder wrote:
> On Wed, Nov 07, 2018 at 07:49:54AM +, Yemin (Amy) wrote:
> 
>> For the range, if the defintion can cover the our range(0..99.), 
>> 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.

>  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.schoenwael...@jacobs-university.de]
>> Ñ
öô: 2018t116å 22:16
>> 6öº: Yemin (Amy)
>> „
: Qin Wu; Xufeng Liu; balazs.leng...@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 +, 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-boun...@ietf.org] ãh Qin Wu [bill...@huawei.com]
>>> Ñ
öô: 2018t116å 9:25
>>> 6öº: Xufeng Liu; balazs.leng...@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-boun...@ietf.org] ãh Xufeng Liu
>>> Ñ
öô: 2018t116å 3:49
>>> 6öº: balazs.leng...@ericsson.com
>>> „
: NETMOD WG 
>>> ;˜: Re: [netmod] for a future rfc6991bis
>>>
>>> The draft that asked for 

Re: [netmod] some comments on netmod-base-notification-nmda (validation after commit response, etc)

[Qin Wu]

发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Sterne, Jason (Nokia - 
CA/Ottawa)
发送时间: 2018年11月6日 10:56
收件人: netmod@ietf.org
主题: [netmod] some comments on netmod-base-notification-nmda (validation after 
commit response, etc)

Hello,

The draft mentions that "It is possible that some configuration could not be 
applied to  due to either validation issues, or missing resource 
etc."

But wouldn't validation errors cause an error response to the commit RPC? I'm 
not clear why there would be validation later in the commit/apply process that 
wasn't part of the decision to reply OK/NOK to the commit.


[Qin]:The configuration is written into running via commit operation, but 
commit operation doesn’t equal to validate operation. Validate operation is 
defined in RFC6241 to validate, e.g., candidate datastore or the  
element containing the complete configuration in the edit config. But RFC6241 
doesn’t discuss how validate operation can be applied to intended or other NMDA 
datastore since NMDA is introduced after RFC6241 gets published.



As described in RFC8342 and figure 2 of RFC8342

“Whenever data is written

   to , the server MUST also immediately update and validate

   .

“

So validate  takes place after commit operation. It involves in 
configuration transformations to  before intended validation operation.

The draft also implies that the process of moving config from running -> 
intended -> operational is decoupled from the application of a candidate -> 
running.
- Do systems reply OK/NOK to a commit before config is moved from 
running->intended->operational ?
[Qin]: reply OK/NOK indicates whether configuration is written into running but 
doesn’t tell us whether validation performed on intended is success or failure, 
validate operation defined in RFC6241 on candidate datastore may be different 
from Validation operation on intended since it clearly happens at different 
stage, sure validate operation can be applied to intended, but no standards 
explicitly specify whether validate operation can be applied to intended.
This is something we can update in this document.

- If so, then maybe it isn't correct to have a username in the notifications. A 
specific user/session did the commit, but then if the commit process ends after 
candidate->running (i.e. the reply happens at that point), then isn't it really 
the system moving the config from running->intended->operational?
[Qin]: See above.
Jason
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] for a future rfc6991bis

[Per Hedeland]

On 2018-11-07 09:34, Juergen Schoenwaelder wrote:

On Wed, Nov 07, 2018 at 07:49:54AM +, Yemin (Amy) wrote:


For the range, if the defintion can cover the our range(0..99.),
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


 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.schoenwael...@jacobs-university.de]
Ñ
öô: 2018t116å 22:16
6öº: Yemin (Amy)
„
: Qin Wu; Xufeng Liu; balazs.leng...@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 +, 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-boun...@ietf.org] ãh Qin Wu [bill...@huawei.com]
Ñ
öô: 2018t116å 9:25
6öº: Xufeng Liu; balazs.leng...@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-boun...@ietf.org] ãh Xufeng Liu
Ñ
öô: 2018t116å 3:49
6öº: balazs.leng...@ericsson.com
„
: NETMOD WG 
;˜: 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.";
 }
 description "Availability level of the link";
   }

Thanks,
- Xufeng

On Sun, Nov 4, 2018 at 7:07 AM Balázs Lengyel 
mailto: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 
mailto:ie...@btconnect.com>> wrote:
 Original Message -
From: "Juergen Schoenwaelder" 
mailto:j.schoenwael...@jacobs-university.de>>
To: "Kent Watsen" mailto:kwat...@juniper..net>>
Cc: mailto:netmod@ietf.org>>
Sent: Tuesday, October 30, 

Re: [netmod] for a future rfc6991bis

[Juergen Schoenwaelder]

On Wed, Nov 07, 2018 at 07:49:54AM +, Yemin (Amy) wrote:

> For the range, if the defintion can cover the our range(0..99.),
> 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 [j.schoenwael...@jacobs-university.de]
> 发送时间: 2018年11月6日 22:16
> 收件人: Yemin (Amy)
> 抄送: Qin Wu; Xufeng Liu; balazs.leng...@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 +, 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-boun...@ietf.org] 代表 Qin Wu [bill...@huawei.com]
> > 发送时间: 2018年11月6日 9:25
> > 收件人: Xufeng Liu; balazs.leng...@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-boun...@ietf.org] 代表 Xufeng Liu
> > 发送时间: 2018年11月6日 3:49
> > 收件人: balazs.leng...@ericsson.com
> > 抄送: NETMOD WG 
> > 主题: 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.";
> > }
> > description "Availability level of the link";
> >   }
> >
> > Thanks,
> > - Xufeng
> >
> > On Sun, Nov 4, 2018 at 7:07 AM Balázs Lengyel 
> > mailto: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 
> > mailto:ie...@btconnect.com>> wrote:
> >  Original Message -
> > From: "Juergen Schoenwaelder" 
> > mailto:j.schoenwael...@jacobs-university.de>>
> > To: "Kent Watsen"