On Fri, Apr 18, 2014 at 4:59 PM, Jan Medved (jmedved) <[email protected]> wrote: > 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. >
This has nothing to do with meeting requirements for I2RS. > 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. Again - I am not hearing requirements against I2RS. Have you implemented I2RS with netconf/restconf/yang? > 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). > I dont think this sounds rational at all. HTTP has a bigger ecosystem than you. Why not build around that and then refactor as needed? Why is it so hard to get requirements around here? What is the point to a standard again? cheers, jamal > 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
