Jamal, Majority of the people are using today NC/RC/YA (because it is available) and it provides necessary functionality. Many people, including myself, didn't find any issues so far with it and we believe it is the right choice. If you remember, at the beginning I mentioned two criteria, technical and business. NC/RC/YA are satisfying both of them for lot of people in this group. You are trying to explain why ForCES is better then NC/RC/YA and I appreciate it, but it is not better for my case and why should I go ahead and implement ForCES on the company platform, when there is no request from the market and the existing tools are working satisfactory.
People do not have to explain their vote, they can just cast it, as it is their opinion. Dean On Apr 21, 2014, at 7:51 AM, Jamal Hadi Salim <h...@mojatatu.com> wrote: > On Mon, Apr 21, 2014 at 2:15 AM, Jan Medved (jmedved) <jmed...@cisco.com> > wrote: >> Russ, >> >> On 4/19/14, 11:06 AM, "Russ White" <ru...@riw.us> wrote: >> > >> What you are asking for would be a lot of work for no practical purpose. > > Sigh. I thought there was some process that we needed to follow. > > Here's a proposition: > How about we settle to just an information model to begin with? > This is what approaches like openstack do. > You can use Yang. We'll use ours. You can use netconf/restconf and > we'll use whatever modification we need on ForCES. We both publish > our results after real code exists. > > cheers, > jamal _______________________________________________ i2rs mailing list i2rs@ietf.org https://www.ietf.org/mailman/listinfo/i2rs
