The other possibility is that FORCES is simply NQR. Sent from my iPhone
> On May 22, 2014, at 11:24 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
