On Thu, Apr 24, 2014 at 7:27 AM, Ladislav Lhotka <[email protected]> wrote:
> "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. > > So to be clear -- it is a property of the data model, not the language. YANG allows top-level config=true or false nodes. The data model authors need to pick the design patterns that are most appropriate. (just like code ;-) Generally, the correlation is embodied in the list keys -- the data naming. For example in the interfaces module, the keys are the same. typedef interface-ref { type leafref { path "/if:interfaces/if:interface/if:name"; } description "This type is used by data models that need to reference configured interfaces."; } typedef interface-state-ref { type leafref { path "/if:interfaces-state/if:interface/if:name"; } description "This type is used by data models that need to reference the operationally present interfaces."; } A weakness of YANG (perhaps Tom's point?) is that the correlation between the 2 'name' leafs is defined in the description statements, (elsewhere in the module) not any machine-readable statements. In general, this correlation is very model-specific, and it might be too hard to formalize into machine-readable statements. > 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 > > Andy > > > > 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 >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
