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
