I believe its because OF-Config does not meet the requirements we set
forth.
--Tom
On Apr 18, 2014:11:31 AM, at 11:31 AM, Behcet Sarikaya <[email protected]>
wrote:
> Hi Dean,
>
> I attended i2rs session in London on this issue.
>
> My question is why ONF Management and Configuration protocol (OF-Config 1.2)
> was not on the table.
>
> Regards,
>
> Behcet
>
>
> On Fri, Apr 18, 2014 at 8: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
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ i2rs mailing list [email protected] https://www.ietf.org/mailman/listinfo/i2rs
