On Fri, Apr 18, 2014 at 11:30 AM, Thomas Nadeau <[email protected]>wrote:
> > On Apr 18, 2014:2:21 PM, at 2:21 PM, Jamal Hadi Salim <[email protected]> > wrote: > > > On Fri, Apr 18, 2014 at 1:39 PM, Thomas Nadeau <[email protected]> > wrote: > >> > >> Why is that not useful? Because I didn't say I was in favor of > forces? *) > > > > Not at all. Your statement was more like a high five. It is ok to > > raise your hand at > > the meeting - but i was hoping the list would have more useful > > technical discussion. > > > >> It IS useful to say that my company's products implement Yang/Netconf > and will support RestConf, >and therefore a derivative of those > technologies used for i2rs is preferred. We have no plans to >support any > of the other discussed options in i2rs such as Forces at this time. The > reasons are >simple: our customers asked for Netconf/Yang models and as far > as I can tell, have no interest in >Forces. > >> > > > > So again it boils down to "bussiness" reasons - am i wrong? > > Yes, but not in the way you imply. My company has implemented > Yang/Netconf because our customers have asked us to and because when we > did, they bought our equipment - not as you imply, because we think its > cool. There are a number of other major hardware vendors on this list that > have done the same. I think if you poll most of those vendors, you will > find that they generally don't engineering resources to things that people > don't buy. Also, Open Daylight has gone with Netconf/Yang/RestConf as one > of its primary interfaces - there are dozens of vendors working on that > project too. As far as I can tell, no one has done any programmable > interface based on Forces there. That seems to be an overwhelming number > of implementations that have gone with yang/netconf/restconf. > > It would be just as valid for people to chime in "We already use ForCES" or "we use already OF-Config", as a reason to use it for I2RS. Andy > "we have an implementation of Yang/netconf"; > > "we are going to make it work for I2RS". > > If thats the case - then lets just end the discussion. > > I am hoping to get the answer to: > > What are the technical requirements/arguements? > > Why do i have to struggle so much in a technical environment like IETF > for > > someone to come out and say what the requirements are? > > > > I can assure you that i have no religious conviction that say it has > > to be ForCES. > > Lets actually start with you showing me how netconf/yang meets the > requirements. > > Otherwise - please stop with the high fives. > > > >> From my perspective, continuing to debate which protocol is > derived to become i2rs is a waste >of everyone's time. > > > > Whats the point to having a circus show in pretending we are trying to > > get any consensus? > > I am not WG chair, so I will let Ed/Jeff comment on the circus. *) > > > Its clear what people want from the meeting, and if you poll interested > implementations you'll likely >get the same answer: yang/netconf/restconf. > Lets please stop delaying i2rs and get some work >done here. > >> > > > > When you go and ask people to raise their hands they will. You need to > > ask them why > > they are raising their hands. I am hoping this is not a staked > > popularity contest. > > Well, at some point it does come down to running code and real, > deployed implementations, right? As I said above, there are many real and > significant implementations of yang/netconf in the marketplace *today*. > Asking those things to be modified slightly isn't that big of a deal in > order to address the requirements. Implementing a completely new protocol > is. I am not totally against new protocols - its just that if we can > achieve the goals we have by hacking an existing implementation, that makes > better engineering and business sense. > > --Tom > > > > > > > > > cheers, > > jamal > > > > _______________________________________________ > > 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
