On Apr 18, 2014:2:37 PM, at 2:37 PM, Andy Bierman <[email protected]> wrote:
> > > > 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. It would, and I think that is what the chairs are trying to assess so chime on in! --Tom > > > 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 > >
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
