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