----- Original Message ----- From: "Susan Hares" <[email protected]> To: "'t.petch'" <[email protected]>; "'Edward Crabbe'" <[email protected]>; <[email protected]> Sent: Wednesday, April 23, 2014 5:21 PM > Tom: > > 100% agree with your comments. I2RS cares whether it is read-only or > read-write. My work toward the revision found: > > - RBNF RBNF did not even allow you a place to r/w or r-only or permissions > (needed for security, but that's my next draft). > - The yang tree I wrote was r-w for config, but did not express the ro-only > tree. I wanted some feedback to figure out why I had 2 write 2 trees. > (your telling me it is a yang short-coming).
Sue That is a feature of YANG. Spend half a day on the netmod WG archives for 1H2013, particularly May and June and for interfaces-cfg, and all will be clear. As Ladislav said on 2May13, "In the current model, the operational state data are not present unless the corresponding entry in the "interface" list is *configured*. So, what I have in mind is a data tree like this: ..." That is, 'config false' nodes under a 'config true' node do not get instantiated in the data model unless and until the 'config true' node is configured. So if you have the one routing table, you will be unable to see the routes learnt via BGP - 'config false' - unless and until you configure the table by creating a static route - 'config true'. It is a tenet of YANG so fundamental, so basic, that I know of nowhere where it is written down:-( Tom Petch > - UML seems to be able to handle read/write variants, and I'm looking to see > if graphical tools will help the developer. > > Not shown in the reduction: > ... And I started working on BGP, ISIS, RIP.. only to find some of these > issues you mention. DCHP and NTP. Any suggestions or help would be > gratefully accepted. > > I will continue to try to get more details on Yang++ and ForCES to see how > many wheels fall off. > > Sue > > -----Original Message----- > From: i2rs [mailto:[email protected]] On Behalf Of t.petch > Sent: Wednesday, April 23, 2014 12:08 PM > To: Edward Crabbe; [email protected]> > YANG (with NETCONF) is designed for writing configuration and reading > everything else, and does an excellent job at it. Trouble is, for me, that > configuration doesn't mean what I think of it as; it means, in the YANG > context, what you might put in through the CLI and it excludes everything > else, such as data learnt via a protocol. > > Take routing. A static route is configuration; anything learnt, via BGP, > IS-IS, RIP etc, is not configuration (and is read only). > > An interface configured automatically on a hot-plugged card is not > configuration; adding 'ospf passive' is. > > And so on, for DHCP, NTP, ..... > > In practice, this means that the YANG model comes in twin sets, one of > read-write configuration and one of read-only not-configuration (as can be > seen in the current I-Ds that the netmod WG is producing) with no formal way > in YANG of relating the one to the other. So if you want e.g. the routing > table, the host software has to know where to look and how to combine the > pieces to produce a coherent picture (and then you cannot edit most of it). > > So if I2RS never wants to write anything to a router, YANG is fine; if I2RS > is only producing a Information Model (and ignoring whether or not data is > read-only or read-write), and not moving on to an implementation, then YANG > is fine. > > Rather, as Andy Bierman said at IETF89, likely I2RS would need an extension > to YANG, a new sub-statement for all data objects, semantics not too clear > but designed to separate out the not-configuration, learnt via a protocol, > 'editable-state' (and in doing so, making it read-write - but still 'config > false'). > > Yes, YANG allows for such extensions but it seems to me that I2RS would then > be getting YANG++ (and NETCONF++), once the necessary work has been done. > > Tom Petch > > > ----- Original Message ----- > From: "Edward Crabbe" <[email protected]> > To: <[email protected]> > Sent: Friday, April 11, 2014 6:50 PM > Subject: [i2rs] consensus on I2RS protocol and model > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
