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
