Alia, You make reasonable arguement and i would agree there are requirements scattered all over the place not totally missing. I didnt think that my arguements were "heard and considered" as you describe. My main of arguement was to use a requirements matrix. I dont think that was considered (Andy says he heard). I understand the desire to move fast - thats why i am not disagreeing on moving forward.
On your points, I empathize with #c. I am pretty sure that is the main driver. I didnt quiet get #b - is sharing a requirement or a good-to-have at all? On #d: My challenge is accepting something without seeing a gap analysis first. To me this overrides the economics of #c. So i am going to wait to see how the selections actually meet the requirements and how much refactoring is going to be needed for the protocols before i am convinced. cheers, jamal On Thu, May 22, 2014 at 2:21 PM, Alia Atlas <[email protected]> wrote: > 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
