Jamal: Were you looking for details on OF-Config? I've enjoyed our discussions of the OF-Config protocol - so this would be fun. However, my understanding is that any proposal for i2rs data model language/protocol needs to at least have one person who is willing to stand up and support it.
Without someone to propose it, I suspect we are just delaying Mr. Ed's I2rs deadlines. Sue -----Original Message----- From: i2rs [mailto:[email protected]] On Behalf Of Jamal Hadi Salim Sent: Friday, April 18, 2014 12:04 PM To: Thomas Nadeau Cc: [email protected]; [email protected]; Crabbe Edward; Dean Bogdanovic Subject: Re: [i2rs] consensus on I2RS protocol and model And what are those mysterious requirements it doesnt meet Thomas? cheers, jamal On Fri, Apr 18, 2014 at 11:47 AM, Thomas Nadeau <[email protected]> wrote: > > I believe its because OF-Config does not meet the requirements we set forth. > > --Tom > > On Apr 18, 2014:11:31 AM, at 11:31 AM, Behcet Sarikaya > <[email protected]> wrote: > > Hi Dean, > > I attended i2rs session in London on this issue. > > My question is why ONF Management and Configuration protocol > (OF-Config 1.2) was not on the table. > > Regards, > > Behcet > > > On Fri, Apr 18, 2014 at 8:17 AM, Dean Bogdanovic <[email protected]> wrote: >> >> 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 > > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
