Thanks to Alia for the review, and Rob for the comments. We will update the model soon.
As for the vrrp-global container, I think that we will move it to a different location, since if:interfaces-state is deprecated in the NMDA compatible model. Thanks, - Xufeng From: Jeff Tantsura [mailto:[email protected]] Sent: Thursday, September 21, 2017 8:00 PM To: Robert Wilton <[email protected]>; Alia Atlas <[email protected]>; [email protected]; [email protected]; Martin Bjorklund <[email protected]> Subject: Re: AD review of draft-ietf-rtgwg-yang-vrrp-04 Thanks Rob! Dear authors, please publish the updated draft ASAP. Thanks! Jeff From: rtgwg <[email protected]<mailto:[email protected]>> on behalf of Robert Wilton <[email protected]<mailto:[email protected]>> Date: Thursday, September 21, 2017 at 07:23 To: Alia Atlas <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, <[email protected]<mailto:[email protected]>>, Martin Bjorklund <[email protected]<mailto:[email protected]>> Subject: Re: AD review of draft-ietf-rtgwg-yang-vrrp-04 Hi Alia, authors, Separately when doing the NMDA conversion on the VRRP module, I noted that it is directly augmenting the "/interfaces-state" container (rather than "/interfaces-state/interface" directly with "VRRP-global" container, which looked a bit odd to me (and broke my conversion tool ;-). E.g. augment /if:interfaces-state: +--ro vrrp-global +--ro virtual-routers? uint32 +--ro interfaces? uint32 +--ro statistics +--ro discontinuity-datetime? yang:date-and-time +--ro checksum-errors? yang:counter64 +--ro version-errors? yang:counter64 +--ro vrid-errors? yang:counter64 +--ro ip-ttl-errors? yang:counter64 This naively seems like the wrong place to me, and I think that it would be better to place this either as a top level "vrrp" container, or perhaps put under the routing tree (e.g. /routing/control-plane-protocols/vrrp). I would have thought that putting this directly under the /interfaces-state container would mean that the /interfaces-state container could hold an interleaved mix of interface list entries and the vrrp-global container!?! E.g. I think that with the model the existing design then this following XML would be allowed - cc Martin in case I am wrong :-) <interfaces-state xmlns="urn:ietf:params:xml:ns:yang:ietf-interfaces" xmlns:ianaift="urn:ietf:params:xml:ns:yang:iana-if-type"> <interface> <name>eth0</name> <type>ianaift:ethernetCsmacd</type> <admin-status>down</admin-status> <oper-status>down</oper-status> ... </interface> <vrrp-global> .... </vrrp-global> <interface> <name>eth1</name> <type>ianaift:ethernetCsmacd</type> <admin-status>up</admin-status> <oper-status>up</oper-status> .... </interface> <interface> <name>eth1.10</name> <type>ianaift:l2vlan</type> <admin-status>up</admin-status> <oper-status>up</oper-status> .... </interface> </interfaces-state> Thanks, Rob On 20/09/2017 17:35, Alia Atlas wrote: As is customary, I have done my AD review of draft-ietf-rtgwg-yang-vrrp-04. First, I would like to thank the authors, Xufeng, Athanasios, Ravi, Acee,and Mingui, as well as the WG for their work on this draft. It is clear and well-written. My one issue is that it does not conform to the NMDA guidelines. I know that the transformation can be done largely programmatically - and Acee & Xufeng are quite familiar with the details. I've also cc'd Rob Wilton who has some tooling to potentially help. From the shepherd's report, I understand that there is an implementation. That implies that the existing model should be in the appendix. I would be delighted to forward this draft to IETF Last Call (and my apologies for the long delay in review) after it has been updated. Thanks, Alia _______________________________________________ rtgwg mailing list [email protected]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/rtgwg
_______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
