Comments inline. Yours Irrespectively,
John > -----Original Message----- > From: Jamal Hadi Salim [mailto:[email protected]] > Sent: Thursday, May 22, 2014 10:22 AM > To: John E Drake > Cc: Jeffrey Haas; [email protected] > Subject: Re: [i2rs] Consensus on I2RS data modeling language and protocol > > 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. [JD] Now that's a meaningful comment. > Nothing is QR for I2RS. > I am talking about process here not a specific protocol. [JD] Right, any process that does not select FORCES is by definition intrinsically flawed. > > 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
