Susan, I'm currently busy with few other things, but wanted to see how some of my work aligns with rib-info models, so planned to read the rib-info models by mid week anyway.
Dean On Apr 19, 2014, at 10:22 AM, Susan Hares <[email protected]> wrote: > 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
