On 12/13/2017 04:26 PM, Vladimir Vassilev wrote:
Hi,
On 12/13/2017 03:47 PM, Martin Bjorklund wrote:
Hi,
Thanks for reporting this. I'll add the missing origin. But why did
you think forwarding and mtu should be removed?
1. IMO since <mtu> is not present in the <ipv4> container in the
Appendix A (<get-config>) example and does not have default value in
the model I still think it should be removed.
Alternatively the ipv4/mtu node can be a good example of a
origin="or:system" configuration.
In fact, I think I
missed <enabled>,
2. IMO both fixes adding <enabled> or removing <forwarding> should be
OK depending on the RFC6243 defined with-defaults capability
'basic-mode' parameter advertised by the server. I was running the
example with basic-mode=explicit
Vladimir
so here's my diff:
--- ex-get-data-reply.xml
+++ ex-get-data-reply.xml
@@ -13,6 +13,7 @@
<!-- other parameters from ietf-interfaces omitted -->
<ipv4 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
+ <enabled>true</enabled>
<forwarding>false</forwarding>
<mtu>1500</mtu>
<address>
@@ -20,12 +21,13 @@
<prefix-length>24</prefix-length>
<origin>static</origin>
</address>
- <neighbor>
+ <neighbor or:origin="or:learned">
<ip>192.0.2.2</ip>
<link-layer-address><!-- PPL
-->00:01:02:03:04:05</link-layer-address>
</neighbor>
</ipv4>
<ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
+ <enabled>true</enabled>
<forwarding>false</forwarding>
<mtu>1280</mtu>
<address>
/martin
Vladimir Vassilev <vladi...@transpacket.com> wrote:
Hello,
The previous post was intended for the rfc7223bis Last Call (wrong
subject line).
I just completed similar validation through a testcase for the
examples in rfc7277bis ("Appendix A. Example: NETCONF <get-config>
reply" and "Appendix B. Example: NETCONF <get-data> Reply")
Here there are some inconsistencies between the <get-config> output
and the expected <get-data> output. A missing origin bug is probably
more significant then the rest. The following patch fixes the
inconsistencies and the testcase passes:
--- before.txt 2017-12-12 20:39:09.037576425 +0100
+++ after.txt 2017-12-12 20:37:46.425656680 +0100
@@ -7,14 +7,12 @@
<type>ianaift:ethernetCsmacd</type>
<!-- other parameters from ietf-interfaces omitted -->
<ipv4 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
- <forwarding>false</forwarding>
- <mtu>1500</mtu>
<address>
<ip>192.0.2.1</ip>
<prefix-length>24</prefix-length>
<origin>static</origin>
</address>
- <neighbor>
+ <neighbor or:origin="or:learned">
<ip>192.0.2.2</ip>
<link-layer-address>
00:01:02:03:04:05
@@ -22,7 +20,6 @@
</neighbor>
</ipv4>
<ipv6 xmlns="urn:ietf:params:xml:ns:yang:ietf-ip">
- <forwarding>false</forwarding>
<mtu>1280</mtu>
<address>
<ip>2001:db8::10</ip>
In contrast to rfc7223bis-00 I have not reviewed rfc7277bis-00 and
this is only a report of a detected issue.
Vladimir
On 12/11/2017 05:35 PM, Vladimir Vassilev wrote:
Hello,
I've reviewed this document and believe it is ready for publication.
The focus of my review this time was on validating the module and the
example modules and example data through running code. I implemented
NMDA for the open source tools we use and added a testcase that
reproduces the result specified in "Appendix E. Example: NETCONF
<get-data> Reply" after loading the configuration specified in
"Appendix D. Example: NETCONF <get-config> Reply" and providing the
config false; data and system originated configuration as needed. I
can confirm the implementation validated the example modules and the
example data producing identical output.
IMO the examples are demonstrating well the concept of NMDA and its
application for the ietf-interfaces module.
I had an issue with a bug in ietf-netconf-datasto...@2017-08-24.yang I
had to fix in order to use the <get-data> RPC. The bug is already
reported on the mailing-list.
diff ietf-patched/ietf-netconf-datasto...@2017-08-24.yang
ietf-draft/ietf-netconf-datasto...@2017-08-24.yang
140c140
< when 'derived-from-or-self(../datastore, "ds:operational")';
---
when 'derived-from-or-self(../datastore, "or:operational")';
Vladimir
On 11/28/2017 08:29 PM, Kent Watsen wrote:
All,
This starts a two-week working group last call on
draft-ietf-netmod-rfc7277bis-00.
Please recall that this update's intention is to
modify the YANG module to be in line with the NMDA
guidelines [1]. Reviewing the diff between the two
drafts [2] should reveal just this.
The working group last call ends on December 12.
Please send your comments to the netmod 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.
[1] https://tools.ietf.org/html/draft-dsdt-nmda-guidelines-01
[2]
https://tools.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc7277bis-00.txt
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
_______________________________________________
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
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
