Likewise: +1 for Netconf/YANG for the i2rs protocol and for YANG as the modeling language.
--dmm On Fri, Apr 18, 2014 at 3:14 PM, Palani Chinnakannan (pals) <[email protected]> wrote: > +1 > We have been saying this for a quite sometime :-) > > pals > > On 4/18/14 3:11 PM, "Geoffrey Mattson" <[email protected]> wrote: > >>+1 for Netconf for the I2RS protocol and YANG for the modeling language. >> >>On 4/18/14 3:04 PM, "Jeff Tantsura" <[email protected]> wrote: >> >>>+1 for Netconf/YANG for the i2rs protocol and for YANG as >>>the modeling language. >>> >>> >>>Cheers, >>>Jeff >>> >>> >>>-----Original Message----- >>>From: "Jan Medved (jmedved)" <[email protected]> >>>Date: Friday, April 18, 2014 1:59 PM >>>To: Dean Bogdanovic <[email protected]>, Jamal Hadi Salim >>><[email protected]> >>>Cc: "[email protected]" <[email protected]>, Edward Crabbe <[email protected]> >>>Subject: Re: [i2rs] consensus on I2RS protocol and model >>> >>>>Cisco is also implementing Netconf - it¹s available on XR today, and it >>>>will be available on other platforms as well. >>>> >>>>For OpenDaylight, we chose Yang as the IDL to describe internal and >>>>external APIs in the controller and so far it has served its purpose >>>>really well. >>>> >>>>Also, as Tom pointed out, Netconf and Restconf have also been >>>>implemented >>>>in ODL. I¹d like to stress that we not only have multiple >>>>Netconf/Restconf >>>>implementations from multiple vendors (Brocade, Juniper, Cisco, just to >>>>mention those on this thread), but have multiple open source >>>>implementations as well. In addition to ODL, there is libnetconfd and a >>>>few others. ODL / libnetconfd interop testing is done in the ODL >>>>regression test suite. Now, since there are multiple independent open >>>>source implementations, we¹ve got a good ecosystem for implementation of >>>>new Netconf/Restconf/Yang features that may be required to meet i2rs¹s >>>>needs (if the need to evolve the protocols/language arises). >>>> >>>>In short, +1 for Netconf/Restconf for the i2rs protocol and for Yang as >>>>the modeling language. >>>> >>>> >>>> >>>>Thanks, >>>>Jan >>>> >>>> >>>>On 4/18/14, 6:17 AM, "Dean Bogdanovic" <[email protected]> wrote: >>>> >>>>>Jamal, >>>>> >>>>>Here are two criteria to be considered: >>>>>1. technical >>>>>2. commercial/business >>>>> >>>>>We can discuss pros and cons for both, but have to state that from >>>>>business perspective for Juniper going with RESTCONF/YANG make more >>>>>sense. We already built the Junos model in YANG and >>>>>have or are in process of building needed tools. Same goes for >>>>>RESTCONF. >>>>>We have NETCONF implemented in Junos and are working on RESTCONF >>>>>implementation. >>>>>Many carriers adopted or are adopting NETCONF/YANG, are looking into >>>>>RESTCONF as well, so this looks like a low hanging fruit from business >>>>>perspective. >>>>> >>>>>Looking at technical aspect, unless there is a very compelling reason >>>>>(and there might be, but I'm not aware of it), don't see reason to >>>>>switch >>>>>from RESTCONF and YANG. >>>>>We can find out down the line that RESTCONF/YANG was the wrong way to >>>>>go, >>>>>but that can be always changed. From my perspective it looks right >>>>>today. >>>>> >>>>>Just to be clear, I vote for RESTCONF/YANG adoption for i2rs. >>>>> >>>>>Dean >>>>> >>>>>On Apr 18, 2014, at 7:27 AM, Jamal Hadi Salim <[email protected]> >>>>>wrote: >>>>> >>>>>> Ok, since nobody is saying anything i'll bite. >>>>>> How would you like for this discussion to proceed? >>>>>> >>>>>> On Fri, Apr 11, 2014 at 1:50 PM, Edward Crabbe <[email protected]> >>>>>>wrote: >>>>>>> Dear I2RSers, >>>>>>> >>>>>>> At the last I2RS WG meeting there was a great deal of conversation >>>>>>> regarding selection of both modeling language and underlying >>>>>>>transport >>>>>>> protocol. Consensus at the time was to make use of Yang and >>>>>>>(NetConf >>>>>>>or >>>>>>> RestConf) (unclear). >>>>>>> >>>>>> >>>>>> And i believe the view, as correctly presented by you, is for folks >>>>>>to >>>>>>go back >>>>>> and make educated decisions by actually getting knowledgeable about >>>>>> the different views presented. "Consensus" that you described above >>>>>> to me looked like a pageant popularity contest not based on anything >>>>>> technical ("who likes contestant in the blue shirt? please cheer for >>>>>>them"). >>>>>> >>>>>> In my opinion i dont think the requirements are clear. >>>>>> >>>>>> Will that get the crickets stop chirping? >>>>>> >>>>>> cheers, >>>>>> jamal >>>>>> >>>>>>> Before coming to a final consensus, we'd like to give people >>>>>>>adequate >>>>>>>time >>>>>>> to review source material, marshall arguments and discuss on the >>>>>>>mailing >>>>>>> list. To this end, we're asking that interested parties do just >>>>>>>this >>>>>>>over >>>>>>> the course of the next ~two weeks. Following that period, on 4/28, >>>>>>>we'll be >>>>>>> initiating a consensus call that will last an additional two weeks, >>>>>>>with the >>>>>>> aim of converging modeling language / protocol by Friday, 5/9. >>>>>>> >>>>>>> The consensus call should also generate proposals for any material >>>>>>>changes >>>>>>> required to the underlying protocols. These proposals in turn will >>>>>>>form the >>>>>>> basis for a later draft including gap analysis and said changes. >>>>>>>Those >>>>>>> strongly in favor of one protocol over another should be prepared to >>>>>>> contribute to this analysis. >>>>>>> >>>>>>> >>>>>>> best, >>>>>>> >>>>>>> -ed >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>>> >>>>_______________________________________________ >>>>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 > > _______________________________________________ > i2rs mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/i2rs _______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
