I dont think a post like this is useful. State your reasons please - just cheering on is not helpful.
cheers, jamal On Fri, Apr 18, 2014 at 11:26 AM, Thomas Nadeau <[email protected]> wrote: > > Sorry for the top post, but I wanted to inject that for the record, > Brocade is in favor of using RestConf/Yang (or variations of those) for I2RS. > We have no interest in using FORCES as the basis for this. > > --Tom > > > On Apr 18, 2014:10:20 AM, at 10:20 AM, Jamal Hadi Salim <[email protected]> > wrote: > >> On Fri, Apr 18, 2014 at 9: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. >>> >> >> Thanks for being sincere Dean. >> First, I will say I empathize with your view above (I understand such >> a view is motivation >> for many unfortunately often disguised as technical opinion). While i >> empathize, I would like >> to point that we need to have these discussions which are technical >> otherwise there is >> no point in having a standard. >> In any case I get where you are coming from. >> >>> 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. >> >> Maybe we'll bring up the topics sequentially as the thread proceeds - >> I'll start with >> 1 or 2 of what i think are requirements against protocol/model so we >> dont have to >> respond to long emails. If you have issues with ForCES please bring >> them up as well >> and we can discuss (I brought up a few in my presentation). >> >> One of the issues was throughput and latency. >> You stated in London that you want to be able to do a large amount of >> updates/sec. >> Other than you - I cant get anyone else to say this is a requirement. >> I do believe it is. >> It will be useful for example to come up with some hand waving numbers >> against >> some agreed-to info model (eg the rib) and see how this requirement is >> met by the >> different protocols. >> >> As for the model, I'd like to quote from the minutes what Tom Petch >> (who i consider to >> be a sage in this space): >> "If I was writing an info model I'd use YANG every time. But if I was >> writing a data >> model I'd go for ForCES." >> And this is rooted in the nature of Yang being intended for Config. >> >> There is also the issue of i2rs ability to describe instances which is >> lacking in Yang; >> but maybe leave that out to a different email.. >> >> cheers, >> jamal >> >>> 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. >>> >> >> _______________________________________________ >> i2rs mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/i2rs >> > _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
