Mr. Ed, our wonderful and delightful co-chair:
This thread is address to the basic assumptions I've of the Yang/Netconf decision is based on, and not a yes or no on the draft. However, your insights will help me cast my vote as an engineer without emotional sway. My sources: I have been working under an assumption of I2rs informational models and I2RS data models that I would like to confirm in this discussion. My assumption comes from discussion with Benoit Claise (OPS/NM area AD) whose wisdom on NM guides the yang/netmod/netconf/ipfix world. I have been equally listening to Andy Beirman. and Jamal Salim. I recommend buying liquid libations to these fonts of wisdom. The assumption: I am assuming that the information models are not a waste of time. Jeff Haas' comment was isn't having information models and data models a duplication of effort. First of all, RBNF and ABNF seem to be causing redundant issues in the draft-ietf-i2rs-rib-info-model-02 draft. The ABNF the delightful work in <http://datatracker.ietf.org/doc/draft-clarke-i2rs-traceability/> draft-clarke-i2rs-traceability-01 really difficult to follow. My assumption had been the following train would occur: UML graphic (readable) || VV (someday via tool) UML text (readable) || (via tools - I've already found some) || VV Yang/Forces Data Model (Yang readable/Forces:Readable) || || (tools to create) XML syntax (yang/forces) / binary syntax (forces) | | | | (tools to create) V V Code inserted For validation of the code in the router Code || (tools creates) XML || (tool creates) Yang/Forces Data model || (tool creates) UML syntax || (tool creates) UML diagrams Why is this chain of events important to me? Validation of Code and structures. Is this any different that the tool chains for Yang/netmod/netconf or Forces/binary/binary? Nope. That's why I hope we can automate it. The goal behind picking a data model is to provide readability as we create these tool chains or to debug it. So.. font of wisdom from on high, can you let me know if I have misunderstood the point for information models and data models. Sue Hares From: i2rs [mailto:[email protected]] On Behalf Of Edward Crabbe Sent: Friday, April 11, 2014 1:51 PM To: [email protected] 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
