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. > "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 >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
