On Thu, May 22, 2014 at 12:13 PM, John E Drake <[email protected]> wrote: > The other possibility is that FORCES is simply NQR. >
Use something better than an Iphone if you want to make a meaningful comment. Nothing is QR for I2RS. I am talking about process here not a specific protocol. cheers, jamal > 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
