"t.petch" <[email protected]> writes: > ----- 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
This issue only affects 'config false' data appearing in the subtree of a 'config true' node. In my opinion, such a data organisation should be generally avoided, and that's why we now have configuration and state data in separate trees. > to see the routes learnt via BGP - 'config false' - unless and until you > configure the table by creating a static route - 'config true'. Note this has never been the case in the ietf-routing module. Routing tables (later renamed to ribs) were always "pure" state data and the default rib for every address family is supposed to be present independently of any configuration. > > It is a tenet of YANG so fundamental, so basic, that I know of nowhere > where it is written down:-( Please see the definitions of system-controlled versus user-controlled list entries in sec. 4.1 of draft-ietf-netmod-routing-cfg-13. I also think think is no idiosyncrasy of YANG, just the way how most systems and their CLIs work. Lada > > 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
