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.
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. 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. 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
