Dean: Thank you for the prompt input. This really helps me! I'm going through the informational models this weekend to try to create a common platform.
If you have time to comment over the next few days on the RIB-info models, it would help. I think the RBNF is causing rather than helping with issues. I've switched over to the UML focus because it helps me find the issues with the relationships to simplify the models. Sue -----Original Message----- From: Dean Bogdanovic [mailto:[email protected]] Sent: Saturday, April 19, 2014 10:12 AM To: Susan Hares Cc: Jamal Hadi Salim; <[email protected]>; Edward Crabbe Subject: Re: [i2rs] consensus on I2RS protocol and model Susan, For YANG following is necessary: publish current model in YANG and YANG compiler We are looking at creating some additional tools to make easier for developers to work with YANG and Junos, but the above two are main conditions. I usually start with informational model and try to see how will it work with data model. And then tweak certain things here and there. For very few things I went directly to data models, but the info model was already very well defined in my head :-) Dean On Apr 18, 2014, at 7:27 PM, Susan Hares <[email protected]> wrote: > Dean: > > Could you let me know what tool chains you consider necessary for > RESTCONF/Yang? > > Do you start with informational models in the Yang/RESTCONF world? > > Sue > > -----Original Message----- > From: i2rs [mailto:[email protected]] On Behalf Of Dean Bogdanovic > Sent: Friday, April 18, 2014 9:18 AM > To: Jamal Hadi Salim > Cc: [email protected]; Edward Crabbe > Subject: Re: [i2rs] consensus on I2RS protocol and model > > Jamal, > > Here are two criteria to be considered: > 1. technical > 2. commercial/business > > We can discuss pros and cons for both, but have to state that from > business perspective for Juniper going with RESTCONF/YANG make more > sense. We already built the Junos model in YANG and have or are in > process of building needed tools. Same goes for RESTCONF. We have > NETCONF implemented in Junos and are working on RESTCONF implementation. > Many carriers adopted or are adopting NETCONF/YANG, are looking into > RESTCONF as well, so this looks like a low hanging fruit from business > perspective. > > Looking at technical aspect, unless there is a very compelling reason > (and there might be, but I'm not aware of it), don't see reason to > switch from RESTCONF and YANG. > We can find out down the line that RESTCONF/YANG was the wrong way to > go, but that can be always changed. From my perspective it looks right today. > > Just to be clear, I vote for RESTCONF/YANG adoption for i2rs. > > Dean > > On Apr 18, 2014, at 7:27 AM, Jamal Hadi Salim <[email protected]> wrote: > >> Ok, since nobody is saying anything i'll bite. >> How would you like for this discussion to proceed? >> >> On Fri, Apr 11, 2014 at 1:50 PM, Edward Crabbe <[email protected]> wrote: >>> 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). >>> >> >> And i believe the view, as correctly presented by you, is for folks >> to go back and make educated decisions by actually getting >> knowledgeable about the different views presented. "Consensus" that >> you described above to me looked like a pageant popularity contest >> not based on anything technical ("who likes contestant in the blue >> shirt? please cheer > for them"). >> >> In my opinion i dont think the requirements are clear. >> >> Will that get the crickets stop chirping? >> >> cheers, >> jamal >> >>> 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
