Jamal, I really appreciate your participating in the discussion and trying to pull the requirements out of the architecture draft. Here are a few of my observations of the full discussion, though.
a) Technically, both NetConf/RestConf/YANG and ForCES could work with some modifications. b) Where there is overlap between I2RS and network configuration, using YANG will allow shared model groups that should decrease the work needed. c) Active contributors from three different companies that are planning or working on implementing I2RS said that they'd prefer to start from NetConf/RestConf/YANG for I2RS. d) There are several existing tool-chains to facilitate YANG model development. There are multiple implementations of NetConf and planned of RestConf that can be used as a starting point for I2RS. Some of these happen to be open source; those planning implementations have ready access to a choice of tool-chains. Unfortunately, sometimes rough consensus means that arguments for one thing are heard, considered, and still do not change the outcome. It is critical to ensure that those arguments are heard and fairly discussed. There is a difference between X could do this and only X could do this. Personally, I do not think that there are unwritten requirements for I2RS; I think the basics are clearly articulated in the architecture draft. I do think that the gap analysis for YANG and for RestConf/NetConf will be quite interesting and needs to be done quickly to be timed with the work on-going in NetMod and NetConf. Regards, Alia On Thu, May 22, 2014 at 11: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
