Hi Jamal, I do agree on moving on. But, just to clarify, I didn't start I2RS thinking that NetConf/YANG were the right answer - though RestConf comes closer. I also know that ForCES has a lot of really good technology. I do and did know of the business considerations that were expressed during the discussion.
I was trying to not have a strong opinion and be sure that you were given time to articulate why ForCES was not only possible but might be better enough technically to be able to handle the business considerations. I apologize if that came across as having made up my mind; I was trying to listen to the others in the WG as well and those opinions were fairly uniform. Regards, Alia On Thu, May 22, 2014 at 4:19 PM, Jamal Hadi Salim <[email protected]> wrote: > Hi Alia, > > On Thu, May 22, 2014 at 3:15 PM, Alia Atlas <[email protected]> wrote: > > Hi Jamal, > > > > > [Alia] If your arguments hadn't been being listened to and > > considered, the decision would have happened many months ago. > > Sorry, I dont mean to be ungrateful but I was referring to the last 2 > months > or so process where i thought the real discussion was happening. Yes, you > could > have dismissed ForCES right off the bat - and we have come a long way; > thanks > for at least providing that opportunity. > > > At the end of the day, despite a year of > > discussion and suggestion for ForCES, others who are planning on > implementing > > were not persuaded nor was there a technical reason that precluded a > > different choice. > > > > Persuading people already vested in netconf/restconf/yang could only happen > if the starting point was requirements from which the proposed solutions > are > cross-checked. > Note: I recall the first time i brought it up, both yourself and Ed > made it clear > you were in favor of netconf/yang. I think i would have had a better chance > convincing people otherwise against a requirements list. > > > [Alia] Given that either technology is possible, #b is a good to have > > that will simplify > > learning, implementation, work to be done on many models, and probably > > operations. > > > > Ok. > > >> On #d: > >> My challenge is accepting something without seeing a gap analysis first. > >> To me this overrides the economics of #c. > >> So i am going to wait to see how the selections actually meet > >> the requirements and how much refactoring is going to be needed for the > >> protocols before i am convinced. > > > > [Alia] There was some discussion of gap analysis earlier to give > > concepts to the WG. > > I would like to see it written down cleanly with reasons in either the > > wiki or a draft. > > I don't think that waiting for completion on each step before any > > progress is made on > > the others is a good idea. It is clear from the list discussion that > > there are many > > interested people waiting for the WG to get on to the solutions step. > > > > Then lets please move on. Like i said i will be curiously observing. > > cheers, > jamal >
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
