For comparison completion, ForCES data model does not need ANY changes. We do need to specify some new data types and models for the different objects as will always be the case for any new LFB but we dont need any changes to the model.
cheers, jamal On Wed, Apr 23, 2014 at 12:59 PM, Andy Bierman <[email protected]> wrote: > > > > On Wed, Apr 23, 2014 at 9:07 AM, t.petch <[email protected]> wrote: >> >> 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. > > > > So far, 2 extensions have been identified that are needed by I2RS. > > 1) identification of editable operational state. > The config=false property in YANG will cause NETCONF and RESTCONF > to (correctly) treat operational state as read-only. I2RS servers must > implement the extension: The I2RS protocol will use its own access > control > model on this data. NACM is not required. > > e.g. (not real data, just example!) > > extension edit-data { > description > "If this statement is present, and the parent statement represents > a non-configuration data node, then instances of this data node > can be modified by a client."; > } > > container rib { > config false; > i2rs:edit-data; > .... > } > > 2) identification of objects associated with event notifications > > This could also be done with a YANG extension, and there is a proposal > to change YANG 1.1 to support this feature: > > extension event-object { > description > "If this statement is present, and the parent statement is > a notification statement, then the 'path' argument represents > the resource associated with the notification."; > argument path; > } > > notification some-interface-event { > i2rs:event-object /if:interfaces/if:interface; > > leaf name { > type leafref { path /if:interfaces/if:interface/if:name; } > } > leaf some-data { type string; } > .... > } > > Nobody said YANG or ForCES could be used without any modifications > to support I2RS. YANG allows instant modifications that require no > changes to the language specification. > > > >> >> Tom Petch > > > Andy > > >> >> >> >> ----- 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 > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
