The Revised Datastore Draft (https://tools.ietf.org/html/draft-ietf-netmod-revised-datastores-01) is the latest approach to address this issue. Before the solution is finalized, NETCONF/RESTCONF protocols are updated, and implementations are available, we still have the field duplications meanwhile.
Thanks, - Xufeng > -----Original Message----- > From: t.petch [mailto:[email protected]] > Sent: Wednesday, May 3, 2017 1:30 PM > To: Henning Rogge <[email protected]>; Xufeng Liu <[email protected]> > Cc: Athanasios Kyparlis <[email protected]>; > [email protected]; Routing WG <[email protected]> > Subject: Re: Routing directorate QA review of draft-ietf-rtgwg-yang-vrrp > > ----- Original Message ----- > From: "Henning Rogge" <[email protected]> > Sent: Tuesday, May 02, 2017 7:49 AM > > > > yes I think the new changes improve the draft and make it easier to > understand. > > > > I wonder if there is a way in YANG to prevent the duplication of all > > the fields between "interface" and "interface-state"... putting the > > common fields into a section of their own and refer to them twice, > > once as "read only" and once "read-writeable". > > No:-( > > This has become a thorny and vexed question with lots of solutions whose > benefits depend on where you are coming from with no consensus among the > interested parties. NETCONF/YANG set out to support configuration which is > defined as something writeable. Read only, well it was not ignored but it did > take a back seat since SNMP was already handling that part of network > management. A requirement emerged to know what the results were of a > configuration change. I enable an interface; is it now enabled? I set an > interface card to auto; what speed is it running at? Clearly there are 'twin' > objects, sometimes triads or more. Rather late in the day it emerged that in > YANG read-only objects that are below a read-write object that has not been > written do not exist. This led to the twin trees approach that is widely > used, one > tree for read-only, one for read-write. > > Other dimensions of this problem are the need either for configuration to come > first and a hot-plugged card to pick up the configuration or for hot-plugging > to > come first and then the card be configured; and for the box to provide default > values to minimise the configuration needed and for the NMS to know what the > defaults are but not to have to read them all. > > Discussions on this go back to 2008 and continue; meanwhile the number of > YANG modules ever increases making changes ever more expensive. > > I like your idea but suspect that it will not gain traction. > > Tom Petch > > > Henning Rogge > > > > On Fri, Apr 28, 2017 at 10:41 PM, Xufeng Liu <[email protected]> > wrote: > > > Hi Henning, > > > > > > Please review if the attached change proposal is ok. > > > Thanks, > > > - Xufeng > > > > > >> -----Original Message----- > > >> From: Xufeng Liu > > >> Sent: Wednesday, April 26, 2017 9:18 AM > > >> To: 'Henning Rogge' <[email protected]> > > >> Cc: Jonathan Hardwick <[email protected]>; > Athanasios > > >> Kyparlis <[email protected]>; [email protected]; > > >> [email protected]; Routing WG <[email protected]> > > >> Subject: RE: Routing directorate QA review of > draft-ietf-rtgwg-yang-vrrp > > >> > > >> Hi Henning, > > >> > > >> Yes. We will add some explanations. > > >> Thanks, > > >> - Xufeng > > >> > > >> > -----Original Message----- > > >> > From: Henning Rogge [mailto:[email protected]] > > >> > Sent: Tuesday, April 25, 2017 9:50 AM > > >> > To: Xufeng Liu <[email protected]> > > >> > Cc: Jonathan Hardwick <[email protected]>; > Athanasios > > >> > Kyparlis <[email protected]>; [email protected]; > > >> > [email protected]; Routing WG <[email protected]> > > >> > Subject: Re: Routing directorate QA review of > > >> > draft-ietf-rtgwg-yang-vrrp > > >> > > > >> > On Tue, Apr 25, 2017 at 3:47 PM, Xufeng Liu > <[email protected]> wrote: > > >> > > > > >> > > Hi Henning, > > >> > > > > >> > > > > >> > > > > >> > > Thank you much for the review. > > >> > > > > >> > > > > >> > > > > >> > > You are right about the mapping for "address of the virtual > router". > > >> > > The > > >> > existing YANG data model for configuring and managing IP > addresses is > > >> > RFC7277, which augments the ietf-interfaces model specified by > > >> > RFC7223. This VRRP model follows the same paradigm. Such a > structure > > >> > is also VRRP protocols are usually implemented. > > >> > > > >> > Maybe the naming of the variables or the explanation of them > could be > > >> > improved to explicitly state this. > > >> > > > >> > Henning > > >> > > > >> > > > > >> > > > > >> > > > > >> > > We will fix the error in Appendix A. in the next revision. > > >> > > > > >> > > > > >> > > > > >> > > Regards, > > >> > > > > >> > > - Xufeng > > >> > > > > >> > > > > >> > > > > >> > > From: Henning Rogge [mailto:[email protected]] > > >> > > Sent: Monday, April 24, 2017 3:41 AM > > >> > > To: Jonathan Hardwick <[email protected]>; > Xufeng Liu > > >> > > <[email protected]>; Athanasios Kyparlis > > >> > > <[email protected]>; [email protected]; > > >> > > [email protected] > > >> > > Cc: Routing WG <[email protected]> > > >> > > Subject: Re: Routing directorate QA review of > > >> > > draft-ietf-rtgwg-yang-vrrp > > >> > > > > >> > > > > >> > > > > >> > > Hi, > > >> > > > > >> > > > > >> > > > > >> > > Jonathan Hardwick asked me to do an early review of the > > >> > > draft-ietf-rtgwg- > > >> > yang-vrrp document (currently revision 02) for the routing > directorate. > > >> > > > > >> > > > > >> > > > > >> > > The draft itself is pretty straight forward and compact, > especially > > >> > > when you > > >> > consider that a lot of text has to be repeated two or four times > > >> > (IPv4/IPv6, config vs. read-only state). > > >> > > > > >> > > > > >> > > > > >> > > But I had quite a bit of trouble mapping the phrases from the > new > > >> > > draft-ietf- > > >> > rtgwg-yang-vrrp-02 document to the existing VRRP documents (e.g. > RFC5798). > > >> > This might come from my unfamilarity with VRRP. > > >> > > > > >> > > > > >> > > > > >> > > The draft YANG model allows to read (if:interfaces-state) and > > >> > > configure > > >> > (if:interfaces) virtual IP addresses, but this does not seem to > be a > > >> > common phrase from the RFCs. Is it the same as "address of the > virtual > > >> > router" often mentioned in RFC5798? > > >> > > > > >> > > > > >> > > > > >> > > In addition to this, I found (I think) a typo or inconsistency > in Appendix A: > > >> > > > > >> > > the ascii art says "eth0" but tree says "eth1". > > >> > > > > >> > > > > >> > > > > >> > > Henning Rogge > > >> > > > > >> > > > > >> > > > > >> > > On Mon, Mar 27, 2017 at 5:43 PM, Jonathan Hardwick > > >> > <[email protected]> wrote: > > >> > > > > >> > > Hi Henning > > >> > > > > >> > > > > >> > > > > >> > > Please would you do a routing directorate early review of this > > >> > > draft? Would > > >> > you be able to do it in 2 to 3 weeks? > > >> > > > > >> > > > > >> > > > > >> > > Many thanks > > >> > > > > >> > > Jon > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > Please would you do a routing directorate QA review of this > draft? > > >> > > > > >> > > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-yang-vrrp/ > > >> > > > > >> > > > > >> > > > > >> > > The draft is still in the RTGWG and is ready for WG last call. > The > > >> > > WG chairs > > >> > have asked for a QA review from the directorate. The following > link > > >> > provides guidance on QA reviews. > > >> > > > > >> > > https://trac.ietf.org/trac/rtg/wiki/RtgDirDocQa > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > > > _______________________________________________ > > rtgwg mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/rtgwg _______________________________________________ rtgwg mailing list [email protected] https://www.ietf.org/mailman/listinfo/rtgwg
