On Thu, May 22, 2014 at 12:43 PM, Andy Bierman <[email protected]> wrote: > Hi, > > Sorry I ran out of time to work on I2RS requirements. > I tried to get some others to work on the wiki, but no takers. >
Thanks for at least attempting that or even thinking about it. > I think if you ask an engineer whose job depends how well > they implement I2RS vs. an engineer who has no plans at all > to implement it, you might get different answers. The initial > and ongoing costs of the solution path really matter to vendors. > I think this is a reasonable requirement. This is why i said i empathized with whoever has already implemented. But i would have felt more satisfied if a reasonable process was followed. Maybe it will cost more to refactor netconf/yang and it is cheaper to create something new. > Even if tools are ignored, there is the problem of I2RS interaction > with the local config. That seems clearly more complicated > with separate solutions for each one. YANG extensions > are also significant because they allow the language to be customized > instantly, without waiting for NETMOD or FORCES WG to be > rechartered to change their data modeling language. > I never looked at config/data store to be a requirement for I2RS. That could be a separate independent service. cheers, jamal > > Andy > > > On Thu, May 22, 2014 at 8:22 AM, Jamal Hadi Salim <[email protected]> wrote: >> >> Jeff/Ed, >> >> First of all I want to thank you both; i think you both tried hard to >> provide the >> opportunity given the constraints. >> Second: I have no qualms with the WG moving forward - I understand >> progress MUST >> be made. Andy, no hard feelings I hope. >> >> Having said that, I would like to speak my mind. I am disappointed and >> I would like to address >> the two points described as cause for the decision. >> >> On the "more support" for netconf/yang: >> ================================ >> My view is this boils down to popularity contest as opposed to >> engineering requirements. >> I wouldnt call this a process breakdown in I2RS - just that in general >> the IETF allows the system >> to be very hackable. It is like money in politics. While I empathize with >> folks >> who have implemented netconf/yang and feel that is the path forward - >> i would argue the >> voting system is highly stacked. I know this is how the "game" has >> been played over the >> years - but for sometime now I feel like we need a new system for >> voting. Things should not be >> judged based on a simple +1 or a hum (I should have advertised >> somewhere for people to >> show up and "vote" for ForCES which would have been dishonest). >> Voting would have more more sense if there were clear requirements to >> begin with from which >> a clear checklist could be derived. >> There were no specific requirements. I am sure there was intent but >> assumptions were made >> that netconf/yang is the way to go from the get-go. >> There was not even effort to match against some requirements for >> netconf/restconf/yang >> when I put out a wiki update. There was not even an attempt to >> dis/credit what i listed as requirements. >> >From day one at the BOF, netconf and Yang were being presented as the >> answer. >> I remember standing up at the BOF mike and asking why solutions were >> being presented before >> requirements - IIRC the answer was i could present my own favorite >> protocol if i wanted to >> and that process would be followed. An engineering task requires >> explicit call out of requirements >> first. >> >> Note: I am not arguing for ForCES here - but it aint >> Netconf/restconf/Yang and neither do i think >> those will require a minor surgery to work (as per my view of the >> requirements). And from that >> perspective I am unhappy - I wish we actually used a matrix of some >> sort to prove me wrong >> but the answer seems like "we'll fix it". >> >> On "open source availability" >> ======================= >> The notion that because there is some open source implementation it >> qualifies >> some solution as legit is a red herring. 90% of IETF standards dont >> pass that smell test. >> There is no such requirement anywhere. >> There is *absolutely* no open source implementation of I2RS using >> netconf/restconf/yang. >> I *doubt* there is one in any organization anywhere on the globe. So >> this boils down to be >> a marketing gimmick in an engineering organization. Which is where my >> frustration comes in. >> Perhaps the starting point at IETF is to go back to the old days of >> implementing first as open >> source variant, get cohesion around it and then standardizing. >> >> I hope my views arent too harsh (I just wanted to feed that elephant >> in the room some peanuts). >> >> cheers, >> jamal >> >> On Wed, May 21, 2014 at 4:36 PM, Jeffrey Haas <[email protected]> wrote: >> > Working Group, >> > >> > We committed to spend the weeks following last session in London for >> > IETF 89 >> > to look at our proposed data modeling languages and protocols in more >> > detail. While that conversation on the mail list didn't yield an >> > explicit >> > set of requirements (but thanks to Jamal for taking the first formal try >> > at >> > it), significant discussion occurred comparing and contrasting the >> > benefits >> > of FORCES and Netconf/Yang. Part of that discussion helped clarify gaps >> > in >> > both proposals that would need to be addressed for use by I2RS. >> > >> > Each proposed mechanism had a few benefits in contrast to its >> > counterpart, >> > but none of these were overwhelming in scope. >> > >> > Our judgment of group consensus is that while both FORCES and >> > Netconf/Yang >> > could serve I2RS that there is substantially more support for the >> > Netconf/Yang proposal. Part of this consideration includes elements of >> > expediency such as existing open source tool chains and implementation >> > experience of I2RS-like mechanisms in other organizations and vendors. >> > >> > Our near-term goals are to formally document the observed gaps in >> > Netconf/Restconf and Yang with regard to I2RS uses and take them to >> > their >> > home working groups to be worked upon. After discussing this detail >> > with >> > our ADs, we can do so either in the form of documenting this upon the >> > wiki >> > or in the form of a requirements Internet-Draft. We welcome the chance >> > to >> > choose our form of agility for this effort. >> > >> > We will be forming a design team in the near future to work on the gap >> > analysis and try to bring the necessary work to closure in short order. >> > >> > -- Ed and Jeff >> > >> > _______________________________________________ >> > 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
