Re: [netmod] [netconf] RE: pls clarify get operation

[Rohit R Ranade]

If IETF modules do not define a ‘-state’ subtree, for example the 
“ietf-module-tags”, each vendor who wants to support Non-NMDA clients may have 
to augment such modules with a “-state” subtree of their own.


From: netconf [mailto:netconf-boun...@ietf.org] On Behalf Of Qin Wu
Sent: 18 July 2019 08:13
To: Kent Watsen 
Cc: netc...@ietf.org; netmod@ietf.org
Subject: Re: [netconf] [netmod] RE: pls clarify get operation

发件人: Kent Watsen [mailto:k...@watsen.net]
发送时间: 2019年7月10日 2:31
收件人: Qin Wu mailto:bill...@huawei.com>>
抄送: netc...@ietf.org; 
netmod@ietf.org
主题: Re: [netconf] [netmod] RE: pls clarify get operation

[Just back from a 4th of July thing]

Hi Qin,
It provides guideline how to create temporary non-NMDA module from NMDA module, 
but temporary non-NMDA module is not standard module. So everybody will create 
the same temporary non-NMDA module?
I also feel this second paragraph is not very clear, especially the last 
sentence,  is nested config false data nodes part of NMDA module or temporary 
non-NMDA
Module? Looks like  nested config false data node part of NMDA module?
True, but as I wrote Frank on the 28th:

"Some drafts already publish a "state" module in their Appendix and, when they 
do, there is a completely standard non-NMDA IETF solution.  I don't know if 
this strategy is being followed universally but, if not, then I don't believe 
the IETF would object at all to the publication of drafts for missing state 
models in drafts that only assumed NMDA."

Are you facing this situation currently?   If so, with which modules?  Have you 
considered submitting an I-D to define the missing state tree module?

[Qin]: Yes, we are looking for completely standard non-NMDA IETF solution in 
this NMDA transition time period, since we assume many NETCONF clients in the 
existing deployment don’t support NMDA. We are not sure state module in the 
appendix is standard non-NMDA model or not? How many operators and implementer 
will use them as standard model.
Yeah, for some of other model may not define such state module in the appendix.
Can non-NMDA client consume NMDA module?

Sort of.  The config-true nodes will appear in the  as usual, and the 
config-false nodes can be accessed via the standard operations.  But there will 
be issues as, for instance, the config-false nodes will only appear for 
configured items and the operational value for config-true nodes will be 
missing, the latter of which may be important as an NMDA-optimized data model 
is unlikely to define config-false nodes for any config-true nodes, and hence 
the config-false that are defined may be far and few between, leading to an 
unacceptably incomplete upstate view.

[Qin]:That is exactly the issue we are facing. How do we as Non-NMDA client use 
NDMA module to get system generated configuration. I assume config false nodes 
for config-true nodes are referred to system generated configuration. These 
system generated configuration can not be obtained through get operation.

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

Re: [netmod] [netconf] RE: pls clarify get operation

[Qin Wu]

发件人: Kent Watsen [mailto:k...@watsen.net]
发送时间: 2019年7月10日 2:31
收件人: Qin Wu 
抄送: netc...@ietf.org; netmod@ietf.org
主题: Re: [netconf] [netmod] RE: pls clarify get operation

[Just back from a 4th of July thing]

Hi Qin,
It provides guideline how to create temporary non-NMDA module from NMDA module, 
but temporary non-NMDA module is not standard module. So everybody will create 
the same temporary non-NMDA module?
I also feel this second paragraph is not very clear, especially the last 
sentence,  is nested config false data nodes part of NMDA module or temporary 
non-NMDA
Module? Looks like  nested config false data node part of NMDA module?
True, but as I wrote Frank on the 28th:

"Some drafts already publish a "state" module in their Appendix and, when they 
do, there is a completely standard non-NMDA IETF solution.  I don't know if 
this strategy is being followed universally but, if not, then I don't believe 
the IETF would object at all to the publication of drafts for missing state 
models in drafts that only assumed NMDA."

Are you facing this situation currently?   If so, with which modules?  Have you 
considered submitting an I-D to define the missing state tree module?

[Qin]: Yes, we are looking for completely standard non-NMDA IETF solution in 
this NMDA transition time period, since we assume many NETCONF clients in the 
existing deployment don’t support NMDA. We are not sure state module in the 
appendix is standard non-NMDA model or not? How many operators and implementer 
will use them as standard model.
Yeah, for some of other model may not define such state module in the appendix.
Can non-NMDA client consume NMDA module?

Sort of.  The config-true nodes will appear in the  as usual, and the 
config-false nodes can be accessed via the standard operations.  But there will 
be issues as, for instance, the config-false nodes will only appear for 
configured items and the operational value for config-true nodes will be 
missing, the latter of which may be important as an NMDA-optimized data model 
is unlikely to define config-false nodes for any config-true nodes, and hence 
the config-false that are defined may be far and few between, leading to an 
unacceptably incomplete upstate view.

[Qin]:That is exactly the issue we are facing. How do we as Non-NMDA client use 
NDMA module to get system generated configuration. I assume config false nodes 
for config-true nodes are referred to system generated configuration. These 
system generated configuration can not be obtained through get operation.


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

Re: [netmod] [Technical Errata Reported] RFC7950 (5784)

[Qin Wu]

Per, thank for your clarification, you address my comment.:-)

-Qin
-邮件原件-
发件人: Per Hedeland [mailto:p...@hedeland.org] 
发送时间: 2019年7月17日 21:29
收件人: Qin Wu 
抄送: Rob Wilton (rwilton) ; ibagd...@gmail.com; 
war...@kumari.net; netmod@ietf.org; RFC Errata System 

主题: Re: [netmod] [Technical Errata Reported] RFC7950 (5784)

On 2019-07-17 14:34, Juergen Schoenwaelder wrote:
> Its the first half of the sentence in my copy of RFC 7950.

It believe that there is a problem with English language both in Qin's 
understanding of the original text (which is correct also in my
opinion) and in his explanation of his (mis)understanding...

> I propose to reject this errata.

I agree, in particular since the suggested change is IMHO no actual 
improvement. It seems the problem is in understanding the "subject to"
construct, which is perhaps not obvious to *all* non-native English readers, 
but I can't think of a replacement that wouldn't result in an unecessarily 
complex text.

> /js
> 
> On Wed, Jul 17, 2019 at 12:02:21PM +, Qin Wu wrote:
>> Hi, Juergen and Rob:
>> The condition to apply " Leading and trailing zeros are prohibited ",is the 
>> second half sentence, i.e.,"there MUST be at least one digit before and 
>> after the decimal point".

It seems that you have it almost backwards... "The rule is A subject to the 
rule B" means that rule A should be applied, except when it will violate rule B.

>> One digit before the decimal point and one digit after the decimal point at 
>> the same time cover 0.500?, I still don't get it.

It's a very good example. With unconditional application of "Leading and 
trailing zeros are prohibited", we end up with .5 - but then we violate "there 
MUST be at least one digit before and after the decimal point", so we need to 
back out the removal of the leading zero, and end up with 0.5.

>> Maybe I am wrong, but this is not a big deal.

Hopefully the above helps...

--Per

>> -Qin
>> -®öŸö-
>> Ñöº: Juergen Schoenwaelder 
>> [mailto:j.schoenwael...@jacobs-university.de]
>> Ñ
öô: 2019t717å 18:29
>> 6öº: Qin Wu 
>> „
: Rob Wilton (rwilton) ; ibagd...@gmail.com; 
>> war...@kumari.net; netmod@ietf.org; RFC Errata System 
>> 
>> ;˜: Re: [netmod] RE: [Technical Errata Reported] RFC7950 (5784)
>>
>> The text starts with the general case and says "Leading and trailing zeros 
>> are prohibited", which seems to cover 0.5000 (which must be represented 
>> as 0.5.
>>
>> /js
>>
>> On Wed, Jul 17, 2019 at 09:42:38AM +, Qin Wu wrote:
>>> I realized my proposed changes also have some flaw and may need to be 
>>> tweaked.
>>>
>>> My question is should trailing zeros in 0.5 be allowed? I didnt see 
>>> the original text prohibit this.
>>> Yes, the original text is correct, but it excludes some exception cases, 
>>> such as 0.5, if my understanding is correct.
>>> Ñöº: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
>>> Ñ
öô: 2019t717å 17:20
>>> 6öº: Qin Wu ; Juergen Schoenwaelder 
>>> 
>>> „
: ibagd...@gmail.com; war...@kumari.net; netmod@ietf.org; RFC 
>>> Errata System 
>>> ;˜: RE: [netmod] T
: [Technical Errata Reported] RFC7950 (5784)
>>>
>>> Hi Qin,
>>>
>>> I also find the current RFC text quite understandable and correct.
>>>
>>> The and is required to disallow .0 and 0. as valid canonical forms.  
>>> I.e. in the canonical form there MUST always be at least one digit (which 
>>> could be 0) before the decimal point and then must be at least one digit 
>>> (which could be 0) after the decimal point.  Otherwise, there must be no 
>>> leading or trailing 0s.  So, none of  .0, 0., 00.0, 0.00 and 
>>> 00.00 are in the canonical form, and should be represented as 0.0 
>>> instead; similarly none of .1, 1., 01.0, 1.00 and 01.00 are in 
>>> the canonical form and should be represented as 1.0 instead.
>>>
>>> Thanks,
>>> Rob
>>>
>>>
>>> From: netmod 
>>> mailto:netmod-boun...@ietf.org>>
>>> On Behalf Of Qin Wu
>>> Sent: 17 July 2019 09:59
>>> To: Juergen Schoenwaelder
>>> mailto:j.schoenwaelder@jacobs-
>>> un
>>> iversity.de>>
>>> Cc: ibagd...@gmail.com;
>>> war...@kumari.net;
>>> netmod@ietf.org; RFC Errata System 
>>> mailto:rfc-edi...@rfc-editor.org>>
>>> Subject: [netmod] T
: [Technical Errata Reported] RFC7950 (5784)
>>>
>>>
>>> Understand, the problem lies at "and" that is used in " one digit before 
>>> and after the decimal point ", that is to say it only focus on the case 
>>> that has two digits, one is before decimal point, the other digit is after 
>>> decimal such as "5.06", but doesn't cover the case where "one digit before 
>>> or after the decimal point ", thats why I think the case 0.50 is not 
>>> covered. We should prohibit trailing zeros in 0.500.
>>>
>>> -®öŸö-
>>> Ñöº: Juergen Schoenwaelder
>>> [mailto:j.schoenwael...@jacobs-university.de]
>>> Ñ
öô: 2019t717å 16:46
>>> 6öº: Qin Wu mailto:bill...@huawei.com>>

Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07

[Rob Wilton (rwilton)]

Hi Acee,

Thanks for the review, and apologies for the delayed reply.

Regarding your stats question, there was some effort to handle this as part of 
defining the Ethernet interface YANG (IEEE 802.3.2-2019) 
(https://github.com/YangModels/yang/tree/master/standard/ieee/published/802.3) 
that I was involved in the earlier parts of.  Please see the attached XLS that 
was my earlier effort to rationalize the different ethernet interfaces counters 
between RFC 7223, Ethernet YANG, Etherlike MIB, RMON MIBs, and the counters 
exposed in the 802.3 clause 30 management API.

For physical Ethernet interfaces (and anything that looks very similar to a 
physical Ethernet interface) then I think that we should be well covered by the 
combination of what is in ietf-interfaces, and IEEE 802.3.2.

There are also some counters that apply to all Ethernet-like interfaces (really 
anything using Ethernet framing, but not an Ethernet physical layer).  The only 
counter currently defined in this category is in-drop-unknown-dest-mac-pkts in 
ietf-interfaces-ethernet-like.  Arguably we could also add a drop counter for 
frames that could not be demuxed to a sub-interface because it didn't match any 
of the sub-interface match expressions.

There was one set of counters that 802.3.2 didn't want to include in their YANG 
module which related to the histogram frame statistics.  E.g. counters like the 
following (taken from IOS XR):

Input pkts 65-127 bytes = 0
Input pkts 128-255 bytes= 0
Input pkts 256-511 bytes= 0
Input pkts 512-1023 bytes   = 0
Input pkts 1024-1518 bytes  = 0
Input pkts 1519-Max bytes   = 0

Output pkts 65-127 bytes= 0
Output pkts 128-255 bytes   = 0
Output pkts 256-511 bytes   = 0
Output pkts 512-1023 bytes  = 0
Output pkts 1024-1518 bytes = 0
Output pkts 1519-Max bytes  = 0

The 802.3 YANG WG had two issues with including counters like these:
(1) They didn't really want to define histogram counter values for MTUs that 
are above the officially sanctioned MTU of 1514/1518 in the Ethernet 
specification, even though a lot of hardware supports up to 9K+.
(2) The bucket ranges, at least once you get past the "512-1023" bucket, seem 
to somewhat vary by ASIC vendor.
(3) IEEE 802.3 has a well defined internal management API (802.3 clause 30), 
and these histogram counters are not currently defined as part of that internal 
management API.  Extending the internal 802.3 management API seems tricky due 
to point (1) and (2) above.

There was a suggestion in the 802.3 discussions that these counters could be 
defined in an IETF YANG module (skirting the IEEE concerns about maximum MTUs). 
 The proposal was to allow the operational data to return a list of bucket 
entries, where each entry defines the inclusive range of the bucket, and a 
count of the pkts that matched the bucket range (in either the ingress or 
egress direction).  This list would sit alongside a RECOMMENDATION of what 
bucket sizes to use, basically doubling each time up to the MTU, with some 
consideration around the 1514/1518/1522 boundary, but allowing freedom for a 
device to accurately return the histogram ranges actually supported by the 
hardware.

However, I'm not sure it is worth delaying these drafts to add these counters 
in now, particularly because there are dependencies on them.  Possibly best 
done as future work?  Do you, or anyone else in the WG have an opinion on this?

Thanks,
Rob



-Original Message-
From: netmod  On Behalf Of Acee Lindem (acee)
Sent: 10 July 2019 14:09
To: Kent Watsen ; netmod@ietf.org
Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-intf-ext-yang-07

I have reviewed the subject document and support publication. I have the 
following comment:

  Perhaps ietf-interface-ethernet-like module 
ethlike:ethernet-like/ethlike:statistics could include a subset of the counters 
from RFC 3635. I say a subset since some of these counters are a bit archaic 
given the state of the technology and judgement should be applied on which to 
include.

  Thanks,
Acee 

On 7/9/19, 8:16 PM, "netmod on behalf of Kent Watsen"  wrote:

All,

This starts a twelve-day working group last call for 
draft-ietf-netmod-intf-ext-yang-07

The working group last call ends on July 21 (the day before the NETMOD 105 
sessions).  Please send your comments to the working group mailing list.

Positive comments, e.g., "I've reviewed this document and believe it is 
ready for publication", are welcome!  This is useful and important, even from 
authors.

Thank you,
NETMOD Chairs
___
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


802.3_YANG_Relationships.xlsx
Description: 802.3_YANG_Relationships.xlsx

Re: [netmod] definition of "fully expanded YANG"

[Robert Varga]

On 17/07/2019 15:54, Juergen Schoenwaelder wrote:
> On Wed, Jul 17, 2019 at 01:18:57PM +, Michael Rehder wrote:
>> Yes, inlining of everything, including augments. What you'd see in the tree 
>> representation.
>> For example augments makes it particularly impossible for a consumer of the 
>> YANG schema to process the schema since the final result.
>>
>> Some use cases:
>> - translating to another schema language
>> - translating to a UI dialog for data entry
>> - an accurate diff on versions
>>
>> Model-driven-design means using the "computable specification" for all sorts 
>> of things, increasing the ROI of the schema definition.
> 
> It sounds to me like you are interested in what compiler people call
> the abstract syntax tree, which is quite a different thing than the
> YANG module you start with. The easiest and most robust way to do
> translations is likely to simply expand pyang (or any other compiler
> of choice).

Depends on how you define the AST (and how many different ASTs are in
your compiler), as .yang file has an AST itself, which you then
cross-reference between modules/submodules, and you arrive at some IR,
from which you derive the effective model with whatever indices/details
your use case requires.

This is certainly possible with OpenDaylight tooling, i.e. arrive at
https://github.com/opendaylight/yangtools/blob/master/yang/yang-model-api/src/main/java/org/opendaylight/yangtools/yang/model/api/EffectiveModelContext.java,
which gives you a per-module tree of statements with all RFC7950
semantic processing applied. It also contains some generally-useful
indices (like schema tree/data tree traversal) as well as references to
original statement declaration (i.e. as it appeared in .yang file, if
applicable).

Regards,
Robert



signature.asc
Description: OpenPGP digital signature
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] definition of "fully expanded YANG"

[Juergen Schoenwaelder]

On Wed, Jul 17, 2019 at 01:18:57PM +, Michael Rehder wrote:
> Yes, inlining of everything, including augments. What you'd see in the tree 
> representation.
> For example augments makes it particularly impossible for a consumer of the 
> YANG schema to process the schema since the final result.
> 
> Some use cases:
> - translating to another schema language
> - translating to a UI dialog for data entry
> - an accurate diff on versions
> 
> Model-driven-design means using the "computable specification" for all sorts 
> of things, increasing the ROI of the schema definition.

It sounds to me like you are interested in what compiler people call
the abstract syntax tree, which is quite a different thing than the
YANG module you start with. The easiest and most robust way to do
translations is likely to simply expand pyang (or any other compiler
of choice).

> The diff is a significant issue. As a schema author, I must reliably document 
> all changes.
> Without a full expansion, it's easy to not notice that a particular module 
> has changes in its final form.
> I don't see how you could verify a semantic version number in a package 
> without this.

Well, this sounds a bit like a tooling issue. You are likely better
off with a tool that can do a semantic comparison for you instead of
working with "fully expanded YANG" modules and generic diff tools.

/js

-- 
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] definition of "fully expanded YANG"

[Michael Rehder]

Yes, that is interesting and is exactly from my experience.

I'm sure that each translator will either not support much "replacement" (maybe 
none at all) or will re-create full-expansion again.

Mik
> -Original Message-
> From: Carsten Bormann [mailto:c...@tzi.org]
> Sent: Wednesday, July 17, 2019 9:37 AM
> To: Michael Rehder 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] definition of "fully expanded YANG"
> 
> On Jul 17, 2019, at 15:18, Michael Rehder 
> wrote:
> >
> > - translating to another schema language
> 
> Hi Michael,
> 
> If that is interesting to you:
> We will spend the weekend on translating between data modeling languages
> during the IETF105 hackathon as part of the WISHI activity inside T2TRG (sorry
> for the abbrev overload).  YANG will be among the languages we are looking
> at.  This is all in the context of the data model convergence activities 
> going on
> in IoT space, but of course the resulting model translation engines will be 
> useful
> beyond that.
> 
> More info:
> 
> https://eur01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwishi.spac
> e%2Fdata=02%7C01%7CMichael.Rehder%40Amdocs.com%7C15271d0a7
> 3d348c798a308d70abbe4ae%7Cc8eca3ca127646d59d9da0f2a028920f%7C0%7
> C0%7C636989674421882779sdata=RpTY8zuzTfa1nOa8sAyBwsZgYpivjvIO
> VKxIRg2CCJM%3Dreserved=0
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
> m%2Ft2trg%2Fwishi%2Fwiki%2FPreparation%3A-Hackathon-
> Planning%23planned-hacking-
> topicsdata=02%7C01%7CMichael.Rehder%40Amdocs.com%7C15271d0a
> 73d348c798a308d70abbe4ae%7Cc8eca3ca127646d59d9da0f2a028920f%7C0%
> 7C0%7C636989674421892775sdata=oIJx%2FpX%2B9n5kwB7%2BU5F%2F
> H%2FIrQPj9vCsVDUEQ4IJCDE0%3Dreserved=0
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co
> m%2Ft2trg%2Fwishi%2Fwiki%2FIETF-105-
> Hackathondata=02%7C01%7CMichael.Rehder%40Amdocs.com%7C1527
> 1d0a73d348c798a308d70abbe4ae%7Cc8eca3ca127646d59d9da0f2a028920f%7
> C0%7C0%7C636989674421892775sdata=bBuZzX9gnlEwsw5PbMZt7puGQ
> GflOEkJiiLtzpnyNag%3Dreserved=0
> 
> Discussion is on the T2TRG mailing list,
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.
> org%2Fmailman%2Flistinfo%2Ft2trgdata=02%7C01%7CMichael.Rehder%
> 40Amdocs.com%7C15271d0a73d348c798a308d70abbe4ae%7Cc8eca3ca127646
> d59d9da0f2a028920f%7C0%7C0%7C636989674421892775sdata=GsnU%
> 2BiTgIdVzbKXcXjRhWJO0nWfjBSakknw4tLL7qRY%3Dreserved=0
> 
> Grüße, Carsten

This email and the information contained herein is proprietary and confidential 
and subject to the Amdocs Email Terms of Service, which you may review at 
https://www.amdocs.com/about/email-terms-of-service 

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

Re: [netmod] definition of "fully expanded YANG"

[Carsten Bormann]

On Jul 17, 2019, at 15:18, Michael Rehder  wrote:
> 
> - translating to another schema language

Hi Michael,

If that is interesting to you:
We will spend the weekend on translating between data modeling languages during 
the IETF105 hackathon as part of the WISHI activity inside T2TRG (sorry for the 
abbrev overload).  YANG will be among the languages we are looking at.  This is 
all in the context of the data model convergence activities going on in IoT 
space, but of course the resulting model translation engines will be useful 
beyond that.

More info:

http://wishi.space/
https://github.com/t2trg/wishi/wiki/Preparation:-Hackathon-Planning#planned-hacking-topics
https://github.com/t2trg/wishi/wiki/IETF-105-Hackathon

Discussion is on the T2TRG mailing list,
https://www.ietf.org/mailman/listinfo/t2trg

Grüße, Carsten

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

Re: [netmod] [Technical Errata Reported] RFC7950 (5784)

[Per Hedeland]

On 2019-07-17 14:34, Juergen Schoenwaelder wrote:

Its the first half of the sentence in my copy of RFC 7950.


It believe that there is a problem with English language both in Qin's
understanding of the original text (which is correct also in my
opinion) and in his explanation of his (mis)understanding...


I propose to reject this errata.


I agree, in particular since the suggested change is IMHO no actual
improvement. It seems the problem is in understanding the "subject to"
construct, which is perhaps not obvious to *all* non-native English
readers, but I can't think of a replacement that wouldn't result in an
unecessarily complex text.


/js

On Wed, Jul 17, 2019 at 12:02:21PM +, Qin Wu wrote:

Hi, Juergen and Rob:
The condition to apply " Leading and trailing zeros are prohibited ",is the second half 
sentence, i.e.,"there MUST be at least one digit before and after the decimal point".


It seems that you have it almost backwards... "The rule is A subject
to the rule B" means that rule A should be applied, except when it
will violate rule B.


One digit before the decimal point and one digit after the decimal point at the 
same time cover 0.500?, I still don't get it.


It's a very good example. With unconditional application of "Leading
and trailing zeros are prohibited", we end up with .5 - but then we
violate "there MUST be at least one digit before and after the decimal
point", so we need to back out the removal of the leading zero, and
end up with 0.5.


Maybe I am wrong, but this is not a big deal.


Hopefully the above helps...

--Per


-Qin
-®öŸö-
Ñöº: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
Ñ
öô: 2019t717å 18:29
6öº: Qin Wu 
„
: Rob Wilton (rwilton) ; ibagd...@gmail.com; war...@kumari.net; 
netmod@ietf.org; RFC Errata System 
;˜: Re: [netmod] RE: [Technical Errata Reported] RFC7950 (5784)

The text starts with the general case and says "Leading and trailing zeros are 
prohibited", which seems to cover 0.5000 (which must be represented as 0.5.

/js

On Wed, Jul 17, 2019 at 09:42:38AM +, Qin Wu wrote:

I realized my proposed changes also have some flaw and may need to be tweaked.

My question is should trailing zeros in 0.5 be allowed? I didnt see the 
original text prohibit this.
Yes, the original text is correct, but it excludes some exception cases, such 
as 0.5, if my understanding is correct.
Ñöº: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
Ñ
öô: 2019t717å 17:20
6öº: Qin Wu ; Juergen Schoenwaelder

„
: ibagd...@gmail.com; war...@kumari.net; netmod@ietf.org; RFC Errata
System 
;˜: RE: [netmod] T

: [Technical Errata Reported] RFC7950 (5784)


Hi Qin,

I also find the current RFC text quite understandable and correct.

The and is required to disallow .0 and 0. as valid canonical forms.  I.e. 
in the canonical form there MUST always be at least one digit (which could be 
0) before the decimal point and then must be at least one digit (which could be 
0) after the decimal point.  Otherwise, there must be no leading or trailing 
0s.  So, none of  .0, 0., 00.0, 0.00 and 00.00 are in the canonical 
form, and should be represented as 0.0 instead; similarly none of .1, 1., 
01.0, 1.00 and 01.00 are in the canonical form and should be represented 
as 1.0 instead.

Thanks,
Rob


From: netmod mailto:netmod-boun...@ietf.org>>
On Behalf Of Qin Wu
Sent: 17 July 2019 09:59
To: Juergen Schoenwaelder
mailto:j.schoenwaelder@jacobs-un
iversity.de>>
Cc: ibagd...@gmail.com;
war...@kumari.net;
netmod@ietf.org; RFC Errata System
mailto:rfc-edi...@rfc-editor.org>>
Subject: [netmod] T

: [Technical Errata Reported] RFC7950 (5784)



Understand, the problem lies at "and" that is used in " one digit before and after the decimal point 
", that is to say it only focus on the case that has two digits, one is before decimal point, the other digit is 
after decimal such as "5.06", but doesn't cover the case where "one digit before or after the decimal 
point ", thats why I think the case 0.50 is not covered. We should prohibit trailing zeros in 0.500.

-®öŸö-
Ñöº: Juergen Schoenwaelder
[mailto:j.schoenwael...@jacobs-university.de]
Ñ
öô: 2019t717å 16:46
6öº: Qin Wu mailto:bill...@huawei.com>>
„
: RFC Errata System
mailto:rfc-edi...@rfc-editor.org>>;
ibagd...@gmail.com;
netmod@ietf.org;
war...@kumari.net
;˜: Re: [netmod] [Technical Errata Reported] RFC7950 (5784)



The text starts with the general case and says "Leading and trailing zeros are 
prohibited", which seems to cover 0.5000. The text then handles the special rule 
that there needs to be at least one digit before and after the decimal point. I think all 
is fine.



/js



On Wed, Jul 17, 2019 at 08:11:41AM +, Qin Wu wrote:


What about "0.5000"? based on original text, is 

Re: [netmod] definition of "fully expanded YANG"

[Michael Rehder]

Yes, inlining of everything, including augments. What you'd see in the tree 
representation.
For example augments makes it particularly impossible for a consumer of the 
YANG schema to process the schema since the final result.

Some use cases:
- translating to another schema language
- translating to a UI dialog for data entry
- an accurate diff on versions

Model-driven-design means using the "computable specification" for all sorts of 
things, increasing the ROI of the schema definition.

The diff is a significant issue. As a schema author, I must reliably document 
all changes.
Without a full expansion, it's easy to not notice that a particular module has 
changes in its final form.
I don't see how you could verify a semantic version number in a package without 
this.

> -Original Message-
> From: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
> Sent: Wednesday, July 17, 2019 9:11 AM
> To: Michael Rehder 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] definition of "fully expanded YANG"
> 
> On Wed, Jul 17, 2019 at 01:03:03PM +, Michael Rehder wrote:
> 
> > Has there ever been discussion about defining “fully expanded YANG”,
> > that is a YANG module with all internal and external imports resolved?
> 
> I wonder what "all internal and external imports resolved" means here
> - you mean included inline? I doubt this will be tremendously useful nor do I
> know what that will work with augments and the fact that definitions live in
> different namespaces and that for example must and when expressions are
> namespace qualified.
> 
> I believe there are tools that do semantic diffs based on comparing schema
> trees internal to a compiler and that sounds to me more robust than producing
> "fully expanded YANG".
> 
> /js
> 
> --
> Juergen Schoenwaelder   Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103
>  obs-
> university.de%2Fdata=02%7C01%7CMichael.Rehder%40Amdocs.com%7
> Ce64f1bc5d532478ded2808d70ab844b5%7Cc8eca3ca127646d59d9da0f2a0289
> 20f%7C0%7C0%7C636989658871253899sdata=US1sJn0ZqC77kiIlqdyzLEtz
> BZdfoo0MCLtG8jqw5w0%3Dreserved=0>
This email and the information contained herein is proprietary and confidential 
and subject to the Amdocs Email Terms of Service, which you may review at 
https://www.amdocs.com/about/email-terms-of-service 

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

Re: [netmod] definition of "fully expanded YANG"

[Juergen Schoenwaelder]

On Wed, Jul 17, 2019 at 01:03:03PM +, Michael Rehder wrote:

> Has there ever been discussion about defining “fully expanded YANG”,
> that is a YANG module with all internal and external imports
> resolved?

I wonder what "all internal and external imports resolved" means here
- you mean included inline? I doubt this will be tremendously useful
nor do I know what that will work with augments and the fact that
definitions live in different namespaces and that for example must and
when expressions are namespace qualified.

I believe there are tools that do semantic diffs based on comparing
schema trees internal to a compiler and that sounds to me more robust
than producing "fully expanded YANG".

/js

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

[netmod] definition of "fully expanded YANG"

[Michael Rehder]

Has there ever been discussion about defining “fully expanded YANG”, that is a 
YANG module with all internal and external imports resolved?
This has several uses:
- Base for workable DIFF between versions so one can see all impacts of changes
   I see this as a pretty important part of semantic version management – if 
you can’t see the net result of changes in a properly modular YANG package, how 
can you be sure of the version meaning?
- Base for translation/processing of the schema
  There are all sorts other materials one can generate from a YANG (or a fully 
expanded YIN). If not expanded then this processing is very difficult.

Thanks
Mike
This email and the information contained herein is proprietary and confidential 
and subject to the Amdocs Email Terms of Service, which you may review at 
https://www.amdocs.com/about/email-terms-of-service 

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

Re: [netmod] [Technical Errata Reported] RFC7950 (5784)

[Qin Wu]

Hi, Juergen and Rob:
The condition to apply " Leading and trailing zeros are prohibited ",is the 
second half sentence, i.e.,"there MUST be at least one digit before and after 
the decimal point".
One digit before the decimal point and one digit after the decimal point at the 
same time cover 0.500?, I still don't get it.
Maybe I am wrong, but this is not a big deal.

-Qin
-邮件原件-
发件人: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de] 
发送时间: 2019年7月17日 18:29
收件人: Qin Wu 
抄送: Rob Wilton (rwilton) ; ibagd...@gmail.com; 
war...@kumari.net; netmod@ietf.org; RFC Errata System 

主题: Re: [netmod] RE: [Technical Errata Reported] RFC7950 (5784)

The text starts with the general case and says "Leading and trailing zeros are 
prohibited", which seems to cover 0.5000 (which must be represented as 0.5.

/js

On Wed, Jul 17, 2019 at 09:42:38AM +, Qin Wu wrote:
> I realized my proposed changes also have some flaw and may need to be tweaked.
> 
> My question is should trailing zeros in “0.5” be allowed? I didn’t see 
> the original text prohibit this.
> Yes, the original text is correct, but it excludes some exception cases, such 
> as “0.5”, if my understanding is correct.
> 发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> 发送时间: 2019年7月17日 17:20
> 收件人: Qin Wu ; Juergen Schoenwaelder 
> 
> 抄送: ibagd...@gmail.com; war...@kumari.net; netmod@ietf.org; RFC Errata 
> System 
> 主题: RE: [netmod] 答复: [Technical Errata Reported] RFC7950 (5784)
> 
> Hi Qin,
> 
> I also find the current RFC text quite understandable and correct.
> 
> The “and” is required to disallow “.0” and “0.” as valid canonical forms.  
> I.e. in the canonical form there MUST always be at least one digit (which 
> could be 0) before the decimal point and then must be at least one digit 
> (which could be 0) after the decimal point.  Otherwise, there must be no 
> leading or trailing 0’s.  So, none of  “.0”, “0.”, “00.0”, “0.00” and “00.00” 
> are in the canonical form, and should be represented as “0.0” instead; 
> similarly none of “.1”, “1.”, “01.0”, “1.00” and “01.00” are in the canonical 
> form and should be represented as “1.0” instead.
> 
> Thanks,
> Rob
> 
> 
> From: netmod mailto:netmod-boun...@ietf.org>> 
> On Behalf Of Qin Wu
> Sent: 17 July 2019 09:59
> To: Juergen Schoenwaelder 
> mailto:j.schoenwaelder@jacobs-un
> iversity.de>>
> Cc: ibagd...@gmail.com; 
> war...@kumari.net; 
> netmod@ietf.org; RFC Errata System 
> mailto:rfc-edi...@rfc-editor.org>>
> Subject: [netmod] 答复: [Technical Errata Reported] RFC7950 (5784)
> 
> 
> Understand, the problem lies at "and" that is used in " one digit before and 
> after the decimal point ", that is to say it only focus on the case that has 
> two digits, one is before decimal point, the other digit is after decimal 
> such as "5.06", but doesn't cover the case where "one digit before or after 
> the decimal point ", that’s why I think the case 0.50 is not covered. We 
> should prohibit trailing zeros in “0.500”.
> 
> -邮件原件-
> 发件人: Juergen Schoenwaelder 
> [mailto:j.schoenwael...@jacobs-university.de]
> 发送时间: 2019年7月17日 16:46
> 收件人: Qin Wu mailto:bill...@huawei.com>>
> 抄送: RFC Errata System 
> mailto:rfc-edi...@rfc-editor.org>>; 
> ibagd...@gmail.com; 
> netmod@ietf.org; 
> war...@kumari.net
> 主题: Re: [netmod] [Technical Errata Reported] RFC7950 (5784)
> 
> 
> 
> The text starts with the general case and says "Leading and trailing zeros 
> are prohibited", which seems to cover 0.5000. The text then handles the 
> special rule that there needs to be at least one digit before and after the 
> decimal point. I think all is fine.
> 
> 
> 
> /js
> 
> 
> 
> On Wed, Jul 17, 2019 at 08:11:41AM +, Qin Wu wrote:
> 
> > What about "0.5000"? based on original text, is it legal or illegal?
> 
> > It seem original text exclude the case where one digit before or after the 
> > decimal point?
> 
> >
> 
> > -Qin
> 
> > -邮件原件-
> 
> > 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Juergen 
> > Schoenwaelder
> 
> > 发送时间: 2019年7月17日 15:50
> 
> > 收件人: RFC Errata System 
> > mailto:rfc-edi...@rfc-editor.org>>
> 
> > 抄送: ibagd...@gmail.com; 
> > netmod@ietf.org; 
> > war...@kumari.net
> 
> > 主题: Re: [netmod] [Technical Errata Reported] RFC7950 (5784)
> 
> >
> 
> > I do not see why the original text makes 0.5 or 0.0 illegal.
> 
> >
> 
> > /js
> 
> >
> 
> > On Tue, Jul 16, 2019 at 08:52:52PM -0700, RFC Errata System wrote:
> 
> > > The following errata report has been submitted for RFC7950, "The
> 
> > > YANG
> 
> > > 1.1 Data Modeling Language".
> 
> > >
> 
> > > --
> 
> > > You may review the report below and at:
> 
> > > https://www.rfc-editor.org/errata/eid5784
> 
> > >
> 
> > > 

Re: [netmod] [Technical Errata Reported] RFC7950 (5784)

[Rob Wilton (rwilton)]

Hi Qin,

If it is input to the server then “0.5” is allowed.  But the canonical 
format for this value (i.e., that would be returned in get-config, get, or 
get-data) is “0.5”.


The value “0.5” is not allowed as a canonical form because of “Leading and 
trailing zeros are prohibited“.  The leading 0 is retained to satisfy the rule 
“there MUST be at least one digit before and after the decimal point”.


Thanks,
Rob


From: Qin Wu 
Sent: 17 July 2019 10:43
To: Rob Wilton (rwilton) ; Juergen Schoenwaelder 

Cc: ibagd...@gmail.com; war...@kumari.net; netmod@ietf.org; RFC Errata System 

Subject: RE: [netmod] RE: [Technical Errata Reported] RFC7950 (5784)

I realized my proposed changes also have some flaw and may need to be tweaked.

My question is should trailing zeros in “0.5” be allowed? I didn’t see the 
original text prohibit this.
Yes, the original text is correct, but it excludes some exception cases, such 
as “0.5”, if my understanding is correct.
发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
发送时间: 2019年7月17日 17:20
收件人: Qin Wu mailto:bill...@huawei.com>>; Juergen 
Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de>>
抄送: ibagd...@gmail.com; 
war...@kumari.net; 
netmod@ietf.org; RFC Errata System 
mailto:rfc-edi...@rfc-editor.org>>
主题: RE: [netmod] 答复: [Technical Errata Reported] RFC7950 (5784)

Hi Qin,

I also find the current RFC text quite understandable and correct.

The “and” is required to disallow “.0” and “0.” as valid canonical forms.  I.e. 
in the canonical form there MUST always be at least one digit (which could be 
0) before the decimal point and then must be at least one digit (which could be 
0) after the decimal point.  Otherwise, there must be no leading or trailing 
0’s.  So, none of  “.0”, “0.”, “00.0”, “0.00” and “00.00” are in the canonical 
form, and should be represented as “0.0” instead; similarly none of “.1”, “1.”, 
“01.0”, “1.00” and “01.00” are in the canonical form and should be represented 
as “1.0” instead.

Thanks,
Rob


From: netmod mailto:netmod-boun...@ietf.org>> On 
Behalf Of Qin Wu
Sent: 17 July 2019 09:59
To: Juergen Schoenwaelder 
mailto:j.schoenwael...@jacobs-university.de>>
Cc: ibagd...@gmail.com; 
war...@kumari.net; 
netmod@ietf.org; RFC Errata System 
mailto:rfc-edi...@rfc-editor.org>>
Subject: [netmod] 答复: [Technical Errata Reported] RFC7950 (5784)


Understand, the problem lies at "and" that is used in " one digit before and 
after the decimal point ", that is to say it only focus on the case that has 
two digits, one is before decimal point, the other digit is after decimal such 
as "5.06", but doesn't cover the case where "one digit before or after the 
decimal point ", that’s why I think the case 0.50 is not covered. We should 
prohibit trailing zeros in “0.500”.

-邮件原件-
发件人: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
发送时间: 2019年7月17日 16:46
收件人: Qin Wu mailto:bill...@huawei.com>>
抄送: RFC Errata System 
mailto:rfc-edi...@rfc-editor.org>>; 
ibagd...@gmail.com; 
netmod@ietf.org; 
war...@kumari.net
主题: Re: [netmod] [Technical Errata Reported] RFC7950 (5784)



The text starts with the general case and says "Leading and trailing zeros are 
prohibited", which seems to cover 0.5000. The text then handles the special 
rule that there needs to be at least one digit before and after the decimal 
point. I think all is fine.



/js



On Wed, Jul 17, 2019 at 08:11:41AM +, Qin Wu wrote:

> What about "0.5000"? based on original text, is it legal or illegal?

> It seem original text exclude the case where one digit before or after the 
> decimal point?

>

> -Qin

> -邮件原件-

> 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Juergen Schoenwaelder

> 发送时间: 2019年7月17日 15:50

> 收件人: RFC Errata System 
> mailto:rfc-edi...@rfc-editor.org>>

> 抄送: ibagd...@gmail.com; 
> netmod@ietf.org; 
> war...@kumari.net

> 主题: Re: [netmod] [Technical Errata Reported] RFC7950 (5784)

>

> I do not see why the original text makes 0.5 or 0.0 illegal.

>

> /js

>

> On Tue, Jul 16, 2019 at 08:52:52PM -0700, RFC Errata System wrote:

> > The following errata report has been submitted for RFC7950, "The

> > YANG

> > 1.1 Data Modeling Language".

> >

> > --

> > You may review the report below and at:

> > https://www.rfc-editor.org/errata/eid5784

> >

> > --

> > Type: Technical

> > Reported by: Qin WU mailto:bill...@huawei.com>>

> >

> > Section: 9.3.2

> >

> > Original Text

> > -

> > Leading and trailing zeros are prohibited, subject to the rule that

> > there MUST be at least one digit before and after 

Re: [netmod] [Technical Errata Reported] RFC7950 (5784)

[Juergen Schoenwaelder]

The text starts with the general case and says "Leading and trailing
zeros are prohibited", which seems to cover 0.5000 (which must be
represented as 0.5.

/js

On Wed, Jul 17, 2019 at 09:42:38AM +, Qin Wu wrote:
> I realized my proposed changes also have some flaw and may need to be tweaked.
> 
> My question is should trailing zeros in “0.5” be allowed? I didn’t see 
> the original text prohibit this.
> Yes, the original text is correct, but it excludes some exception cases, such 
> as “0.5”, if my understanding is correct.
> 发件人: Rob Wilton (rwilton) [mailto:rwil...@cisco.com]
> 发送时间: 2019年7月17日 17:20
> 收件人: Qin Wu ; Juergen Schoenwaelder 
> 
> 抄送: ibagd...@gmail.com; war...@kumari.net; netmod@ietf.org; RFC Errata System 
> 
> 主题: RE: [netmod] 答复: [Technical Errata Reported] RFC7950 (5784)
> 
> Hi Qin,
> 
> I also find the current RFC text quite understandable and correct.
> 
> The “and” is required to disallow “.0” and “0.” as valid canonical forms.  
> I.e. in the canonical form there MUST always be at least one digit (which 
> could be 0) before the decimal point and then must be at least one digit 
> (which could be 0) after the decimal point.  Otherwise, there must be no 
> leading or trailing 0’s.  So, none of  “.0”, “0.”, “00.0”, “0.00” and “00.00” 
> are in the canonical form, and should be represented as “0.0” instead; 
> similarly none of “.1”, “1.”, “01.0”, “1.00” and “01.00” are in the canonical 
> form and should be represented as “1.0” instead.
> 
> Thanks,
> Rob
> 
> 
> From: netmod mailto:netmod-boun...@ietf.org>> On 
> Behalf Of Qin Wu
> Sent: 17 July 2019 09:59
> To: Juergen Schoenwaelder 
> mailto:j.schoenwael...@jacobs-university.de>>
> Cc: ibagd...@gmail.com; 
> war...@kumari.net; 
> netmod@ietf.org; RFC Errata System 
> mailto:rfc-edi...@rfc-editor.org>>
> Subject: [netmod] 答复: [Technical Errata Reported] RFC7950 (5784)
> 
> 
> Understand, the problem lies at "and" that is used in " one digit before and 
> after the decimal point ", that is to say it only focus on the case that has 
> two digits, one is before decimal point, the other digit is after decimal 
> such as "5.06", but doesn't cover the case where "one digit before or after 
> the decimal point ", that’s why I think the case 0.50 is not covered. We 
> should prohibit trailing zeros in “0.500”.
> 
> -邮件原件-
> 发件人: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
> 发送时间: 2019年7月17日 16:46
> 收件人: Qin Wu mailto:bill...@huawei.com>>
> 抄送: RFC Errata System 
> mailto:rfc-edi...@rfc-editor.org>>; 
> ibagd...@gmail.com; 
> netmod@ietf.org; 
> war...@kumari.net
> 主题: Re: [netmod] [Technical Errata Reported] RFC7950 (5784)
> 
> 
> 
> The text starts with the general case and says "Leading and trailing zeros 
> are prohibited", which seems to cover 0.5000. The text then handles the 
> special rule that there needs to be at least one digit before and after the 
> decimal point. I think all is fine.
> 
> 
> 
> /js
> 
> 
> 
> On Wed, Jul 17, 2019 at 08:11:41AM +, Qin Wu wrote:
> 
> > What about "0.5000"? based on original text, is it legal or illegal?
> 
> > It seem original text exclude the case where one digit before or after the 
> > decimal point?
> 
> >
> 
> > -Qin
> 
> > -邮件原件-
> 
> > 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Juergen Schoenwaelder
> 
> > 发送时间: 2019年7月17日 15:50
> 
> > 收件人: RFC Errata System 
> > mailto:rfc-edi...@rfc-editor.org>>
> 
> > 抄送: ibagd...@gmail.com; 
> > netmod@ietf.org; 
> > war...@kumari.net
> 
> > 主题: Re: [netmod] [Technical Errata Reported] RFC7950 (5784)
> 
> >
> 
> > I do not see why the original text makes 0.5 or 0.0 illegal.
> 
> >
> 
> > /js
> 
> >
> 
> > On Tue, Jul 16, 2019 at 08:52:52PM -0700, RFC Errata System wrote:
> 
> > > The following errata report has been submitted for RFC7950, "The
> 
> > > YANG
> 
> > > 1.1 Data Modeling Language".
> 
> > >
> 
> > > --
> 
> > > You may review the report below and at:
> 
> > > https://www.rfc-editor.org/errata/eid5784
> 
> > >
> 
> > > --
> 
> > > Type: Technical
> 
> > > Reported by: Qin WU mailto:bill...@huawei.com>>
> 
> > >
> 
> > > Section: 9.3.2
> 
> > >
> 
> > > Original Text
> 
> > > -
> 
> > > Leading and trailing zeros are prohibited, subject to the rule that
> 
> > > there MUST be at least one digit before and after the decimal point.
> 
> > > The value zero is represented as "0.0".
> 
> > >
> 
> > >
> 
> > >
> 
> > >
> 
> > > Corrected Text
> 
> > > --
> 
> > > Leading zeros before the first digit and trailing zeros after the
> 
> > > last digit are prohibited, subject to the rule that there MUST be at
> 
> > > least one digit before and 

Re: [netmod] 答复: [Technical Errata Reported] RFC7950 (5784)

[Rob Wilton (rwilton)]

Hi Qin,

I also find the current RFC text quite understandable and correct.

The “and” is required to disallow “.0” and “0.” as valid canonical forms.  I.e. 
in the canonical form there MUST always be at least one digit (which could be 
0) before the decimal point and then must be at least one digit (which could be 
0) after the decimal point.  Otherwise, there must be no leading or trailing 
0’s.  So, none of  “.0”, “0.”, “00.0”, “0.00” and “00.00” are in the canonical 
form, and should be represented as “0.0” instead; similarly none of “.1”, “1.”, 
“01.0”, “1.00” and “01.00” are in the canonical form and should be represented 
as “1.0” instead.

Thanks,
Rob


From: netmod  On Behalf Of Qin Wu
Sent: 17 July 2019 09:59
To: Juergen Schoenwaelder 
Cc: ibagd...@gmail.com; war...@kumari.net; netmod@ietf.org; RFC Errata System 

Subject: [netmod] 答复: [Technical Errata Reported] RFC7950 (5784)


Understand, the problem lies at "and" that is used in " one digit before and 
after the decimal point ", that is to say it only focus on the case that has 
two digits, one is before decimal point, the other digit is after decimal such 
as "5.06", but doesn't cover the case where "one digit before or after the 
decimal point ", that’s why I think the case 0.50 is not covered. We should 
prohibit trailing zeros in “0.500”.

-邮件原件-
发件人: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
发送时间: 2019年7月17日 16:46
收件人: Qin Wu mailto:bill...@huawei.com>>
抄送: RFC Errata System 
mailto:rfc-edi...@rfc-editor.org>>; 
ibagd...@gmail.com; 
netmod@ietf.org; 
war...@kumari.net
主题: Re: [netmod] [Technical Errata Reported] RFC7950 (5784)



The text starts with the general case and says "Leading and trailing zeros are 
prohibited", which seems to cover 0.5000. The text then handles the special 
rule that there needs to be at least one digit before and after the decimal 
point. I think all is fine.



/js



On Wed, Jul 17, 2019 at 08:11:41AM +, Qin Wu wrote:

> What about "0.5000"? based on original text, is it legal or illegal?

> It seem original text exclude the case where one digit before or after the 
> decimal point?

>

> -Qin

> -邮件原件-

> 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Juergen Schoenwaelder

> 发送时间: 2019年7月17日 15:50

> 收件人: RFC Errata System 
> mailto:rfc-edi...@rfc-editor.org>>

> 抄送: ibagd...@gmail.com; 
> netmod@ietf.org; 
> war...@kumari.net

> 主题: Re: [netmod] [Technical Errata Reported] RFC7950 (5784)

>

> I do not see why the original text makes 0.5 or 0.0 illegal.

>

> /js

>

> On Tue, Jul 16, 2019 at 08:52:52PM -0700, RFC Errata System wrote:

> > The following errata report has been submitted for RFC7950, "The

> > YANG

> > 1.1 Data Modeling Language".

> >

> > --

> > You may review the report below and at:

> > https://www.rfc-editor.org/errata/eid5784

> >

> > --

> > Type: Technical

> > Reported by: Qin WU mailto:bill...@huawei.com>>

> >

> > Section: 9.3.2

> >

> > Original Text

> > -

> > Leading and trailing zeros are prohibited, subject to the rule that

> > there MUST be at least one digit before and after the decimal point.

> > The value zero is represented as "0.0".

> >

> >

> >

> >

> > Corrected Text

> > --

> > Leading zeros before the first digit and trailing zeros after the

> > last digit are prohibited, subject to the rule that there MUST be at

> > least one digit before and after the decimal point.  The value zero

> > is represented as "0.0".

> >

> > Notes

> > -

> > Based on the rule in the orginal text, the value such as "0.5","0.0" is 
> > illegal. So I think the intention of the original text is to make sure the 
> > leading zeros before the first digit and the trailing zero after the last 
> > digit are prohibited.

> >

> > Instructions:

> > -

> > This erratum is currently posted as "Reported". If necessary, please

> > use "Reply All" to discuss whether it should be verified or rejected.

> > When a decision is reached, the verifying party can log in to change

> > the status and edit the report, if necessary.

> >

> > --

> > RFC7950 (draft-ietf-netmod-rfc6020bis-14)

> > --

> > Title   : The YANG 1.1 Data Modeling Language

> > Publication Date: August 2016

> > Author(s)   : M. Bjorklund, Ed.

> > Category: PROPOSED STANDARD

> > Source  : Network Modeling

> > Area: Operations and Management

> > Stream  : IETF

> > Verifying Party : IESG

> >

> > ___

> > netmod mailing list

> > netmod@ietf.org

> > 

[netmod] 答复: [Technical Errata Reported] RFC7950 (5784)

[Qin Wu]

Understand, the problem lies at "and" that is used in " one digit before and 
after the decimal point ", that is to say it only focus on the case that has 
two digits, one is before decimal point, the other digit is after decimal such 
as "5.06", but doesn't cover the case where "one digit before or after the 
decimal point ", that’s why I think the case 0.50 is not covered. We should 
prohibit trailing zeros in “0.500”.

-邮件原件-
发件人: Juergen Schoenwaelder [mailto:j.schoenwael...@jacobs-university.de]
发送时间: 2019年7月17日 16:46
收件人: Qin Wu 
抄送: RFC Errata System ; ibagd...@gmail.com; 
netmod@ietf.org; war...@kumari.net
主题: Re: [netmod] [Technical Errata Reported] RFC7950 (5784)



The text starts with the general case and says "Leading and trailing zeros are 
prohibited", which seems to cover 0.5000. The text then handles the special 
rule that there needs to be at least one digit before and after the decimal 
point. I think all is fine.



/js



On Wed, Jul 17, 2019 at 08:11:41AM +, Qin Wu wrote:

> What about "0.5000"? based on original text, is it legal or illegal?

> It seem original text exclude the case where one digit before or after the 
> decimal point?

>

> -Qin

> -邮件原件-

> 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Juergen Schoenwaelder

> 发送时间: 2019年7月17日 15:50

> 收件人: RFC Errata System 
> mailto:rfc-edi...@rfc-editor.org>>

> 抄送: ibagd...@gmail.com; 
> netmod@ietf.org; 
> war...@kumari.net

> 主题: Re: [netmod] [Technical Errata Reported] RFC7950 (5784)

>

> I do not see why the original text makes 0.5 or 0.0 illegal.

>

> /js

>

> On Tue, Jul 16, 2019 at 08:52:52PM -0700, RFC Errata System wrote:

> > The following errata report has been submitted for RFC7950, "The

> > YANG

> > 1.1 Data Modeling Language".

> >

> > --

> > You may review the report below and at:

> > https://www.rfc-editor.org/errata/eid5784

> >

> > --

> > Type: Technical

> > Reported by: Qin WU mailto:bill...@huawei.com>>

> >

> > Section: 9.3.2

> >

> > Original Text

> > -

> > Leading and trailing zeros are prohibited, subject to the rule that

> > there MUST be at least one digit before and after the decimal point.

> > The value zero is represented as "0.0".

> >

> >

> >

> >

> > Corrected Text

> > --

> > Leading zeros before the first digit and trailing zeros after the

> > last digit are prohibited, subject to the rule that there MUST be at

> > least one digit before and after the decimal point.  The value zero

> > is represented as "0.0".

> >

> > Notes

> > -

> > Based on the rule in the orginal text, the value such as "0.5","0.0" is 
> > illegal. So I think the intention of the original text is to make sure the 
> > leading zeros before the first digit and the trailing zero after the last 
> > digit are prohibited.

> >

> > Instructions:

> > -

> > This erratum is currently posted as "Reported". If necessary, please

> > use "Reply All" to discuss whether it should be verified or rejected.

> > When a decision is reached, the verifying party can log in to change

> > the status and edit the report, if necessary.

> >

> > --

> > RFC7950 (draft-ietf-netmod-rfc6020bis-14)

> > --

> > Title   : The YANG 1.1 Data Modeling Language

> > Publication Date: August 2016

> > Author(s)   : M. Bjorklund, Ed.

> > Category: PROPOSED STANDARD

> > Source  : Network Modeling

> > Area: Operations and Management

> > Stream  : IETF

> > Verifying Party : IESG

> >

> > ___

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



--

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] [Technical Errata Reported] RFC7950 (5784)

[Juergen Schoenwaelder]

The text starts with the general case and says "Leading and trailing
zeros are prohibited", which seems to cover 0.5000. The text then
handles the special rule that there needs to be at least one digit
before and after the decimal point. I think all is fine.

/js

On Wed, Jul 17, 2019 at 08:11:41AM +, Qin Wu wrote:
> What about "0.5000"? based on original text, is it legal or illegal?
> It seem original text exclude the case where one digit before or after the 
> decimal point?
> 
> -Qin
> -邮件原件-
> 发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Juergen Schoenwaelder
> 发送时间: 2019年7月17日 15:50
> 收件人: RFC Errata System 
> 抄送: ibagd...@gmail.com; netmod@ietf.org; war...@kumari.net
> 主题: Re: [netmod] [Technical Errata Reported] RFC7950 (5784)
> 
> I do not see why the original text makes 0.5 or 0.0 illegal.
> 
> /js
> 
> On Tue, Jul 16, 2019 at 08:52:52PM -0700, RFC Errata System wrote:
> > The following errata report has been submitted for RFC7950, "The YANG 
> > 1.1 Data Modeling Language".
> > 
> > --
> > You may review the report below and at:
> > https://www.rfc-editor.org/errata/eid5784
> > 
> > --
> > Type: Technical
> > Reported by: Qin WU 
> > 
> > Section: 9.3.2
> > 
> > Original Text
> > -
> > Leading and trailing zeros are prohibited, subject to the rule that 
> > there MUST be at least one digit before and after the decimal point.
> > The value zero is represented as "0.0".
> > 
> > 
> > 
> > 
> > Corrected Text
> > --
> > Leading zeros before the first digit and trailing zeros after the last 
> > digit are prohibited, subject to the rule that there MUST be at least 
> > one digit before and after the decimal point.  The value zero is 
> > represented as "0.0".
> > 
> > Notes
> > -
> > Based on the rule in the orginal text, the value such as "0.5","0.0" is 
> > illegal. So I think the intention of the original text is to make sure the 
> > leading zeros before the first digit and the trailing zero after the last 
> > digit are prohibited.
> > 
> > Instructions:
> > -
> > This erratum is currently posted as "Reported". If necessary, please 
> > use "Reply All" to discuss whether it should be verified or rejected. 
> > When a decision is reached, the verifying party can log in to change 
> > the status and edit the report, if necessary.
> > 
> > --
> > RFC7950 (draft-ietf-netmod-rfc6020bis-14)
> > --
> > Title   : The YANG 1.1 Data Modeling Language
> > Publication Date: August 2016
> > Author(s)   : M. Bjorklund, Ed.
> > Category: PROPOSED STANDARD
> > Source  : Network Modeling
> > Area: Operations and Management
> > Stream  : IETF
> > Verifying Party : IESG
> > 
> > ___
> > 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

-- 
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] [Technical Errata Reported] RFC7950 (5784)

[Qin Wu]

What about "0.5000"? based on original text, is it legal or illegal?
It seem original text exclude the case where one digit before or after the 
decimal point?

-Qin
-邮件原件-
发件人: netmod [mailto:netmod-boun...@ietf.org] 代表 Juergen Schoenwaelder
发送时间: 2019年7月17日 15:50
收件人: RFC Errata System 
抄送: ibagd...@gmail.com; netmod@ietf.org; war...@kumari.net
主题: Re: [netmod] [Technical Errata Reported] RFC7950 (5784)

I do not see why the original text makes 0.5 or 0.0 illegal.

/js

On Tue, Jul 16, 2019 at 08:52:52PM -0700, RFC Errata System wrote:
> The following errata report has been submitted for RFC7950, "The YANG 
> 1.1 Data Modeling Language".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid5784
> 
> --
> Type: Technical
> Reported by: Qin WU 
> 
> Section: 9.3.2
> 
> Original Text
> -
> Leading and trailing zeros are prohibited, subject to the rule that 
> there MUST be at least one digit before and after the decimal point.
> The value zero is represented as "0.0".
> 
> 
> 
> 
> Corrected Text
> --
> Leading zeros before the first digit and trailing zeros after the last 
> digit are prohibited, subject to the rule that there MUST be at least 
> one digit before and after the decimal point.  The value zero is 
> represented as "0.0".
> 
> Notes
> -
> Based on the rule in the orginal text, the value such as "0.5","0.0" is 
> illegal. So I think the intention of the original text is to make sure the 
> leading zeros before the first digit and the trailing zero after the last 
> digit are prohibited.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please 
> use "Reply All" to discuss whether it should be verified or rejected. 
> When a decision is reached, the verifying party can log in to change 
> the status and edit the report, if necessary.
> 
> --
> RFC7950 (draft-ietf-netmod-rfc6020bis-14)
> --
> Title   : The YANG 1.1 Data Modeling Language
> Publication Date: August 2016
> Author(s)   : M. Bjorklund, Ed.
> Category: PROPOSED STANDARD
> Source  : Network Modeling
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG
> 
> ___
> 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
___
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Re: [netmod] [Technical Errata Reported] RFC7950 (5784)

[Juergen Schoenwaelder]

I do not see why the original text makes 0.5 or 0.0 illegal.

/js

On Tue, Jul 16, 2019 at 08:52:52PM -0700, RFC Errata System wrote:
> The following errata report has been submitted for RFC7950,
> "The YANG 1.1 Data Modeling Language".
> 
> --
> You may review the report below and at:
> https://www.rfc-editor.org/errata/eid5784
> 
> --
> Type: Technical
> Reported by: Qin WU 
> 
> Section: 9.3.2
> 
> Original Text
> -
> Leading and trailing zeros are prohibited, subject to the rule that 
> there MUST be at least one digit before and after the decimal point.  
> The value zero is represented as "0.0".
> 
> 
> 
> 
> Corrected Text
> --
> Leading zeros before the first digit and trailing zeros after the 
> last digit are prohibited, subject to the rule that there MUST be 
> at least one digit before and after the decimal point.  The value 
> zero is represented as "0.0".
> 
> Notes
> -
> Based on the rule in the orginal text, the value such as "0.5","0.0" is 
> illegal. So I think the intention of the original text is to make sure the 
> leading zeros before the first digit and the trailing zero after the last 
> digit are prohibited.
> 
> Instructions:
> -
> This erratum is currently posted as "Reported". If necessary, please
> use "Reply All" to discuss whether it should be verified or
> rejected. When a decision is reached, the verifying party  
> can log in to change the status and edit the report, if necessary. 
> 
> --
> RFC7950 (draft-ietf-netmod-rfc6020bis-14)
> --
> Title   : The YANG 1.1 Data Modeling Language
> Publication Date: August 2016
> Author(s)   : M. Bjorklund, Ed.
> Category: PROPOSED STANDARD
> Source  : Network Modeling
> Area: Operations and Management
> Stream  : IETF
> Verifying Party : IESG
> 
> ___
> 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