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 > Dear I2RSers, > > > At the last I2RS WG meeting there was a great deal of conversation > regarding selection of both modeling language and underlying transport > protocol. Consensus at the time was to make use of Yang and (NetConf or > RestConf) (unclear). > > Before coming to a final consensus, we'd like to give people adequate > time to review source material, marshall arguments and discuss on the > mailing list. To this end, we're asking that interested parties do just > this over the course of the next ~two weeks. Following that period, on > 4/28, we'll be initiating a consensus call that will last an additional two > weeks, with the aim of converging modeling language / protocol by Friday, > 5/9. > > The consensus call should also generate proposals for any material changes > required to the underlying protocols. These proposals in turn will form > the basis for a later draft including gap analysis and said changes. Those > strongly in favor of one protocol over another should be prepared to > contribute to this analysis. > > > best, > > -ed > ------------------------------------------------------------------------ -------- > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
