Hi Jamal, On Thu, May 22, 2014 at 2:46 PM, Jamal Hadi Salim <[email protected]> wrote: > 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.
[Alia] If your arguments hadn't been being listened to and considered, the decision would have happened many months ago. At the end of the day, despite a year of discussion and suggestion for ForCES, others who are planning on implementing were not persuaded nor was there a technical reason that precluded a different choice. > 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? [Alia] Given that either technology is possible, #b is a good to have that will simplify learning, implementation, work to be done on many models, and probably operations. > 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. [Alia] There was some discussion of gap analysis earlier to give concepts to the WG. I would like to see it written down cleanly with reasons in either the wiki or a draft. I don't think that waiting for completion on each step before any progress is made on the others is a good idea. It is clear from the list discussion that there are many interested people waiting for the WG to get on to the solutions step. Regards, Alia > 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
