I think we can introduce a new own protocol that is similar with NETCONF. For example, extensiable RPC mechanism, session control will be reserved, but capabilities and operations and datastores about configuration management(edit-config/get-config etc) will be not reserved, and introduce new datastore/capablities/operations about I2RS.
The data model what the new protocol operates will be open, but must be suitable for requirements of I2RS. The encoding of new protocol is open, xml, json, binary,etc are all acceptable. We can suggest YANG model language as preferred data model language of I2RS. YANG is a excellent data model language for configuration management, but it must be extend to adapt to the requirements of I2RS. 2014-04-24 0:07 GMT+08:00 t.petch <[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 > > > > 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 >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
