Why is that not useful? Because I didn't say I was in favor of forces?
*) It IS useful to say that my company's products implement Yang/Netconf and
will support RestConf, and therefore a derivative of those technologies used
for i2rs is preferred. We have no plans to support any of the other discussed
options in i2rs such as Forces at this time. The reasons are simple: our
customers asked for Netconf/Yang models and as far as I can tell, have no
interest in Forces.
From my perspective, continuing to debate which protocol is derived to
become i2rs is a waste of everyone's time. Its clear what people want from the
meeting, and if you poll interested implementations you'll likely get the same
answer: yang/netconf/restconf. Lets please stop delaying i2rs and get some
work done here.
--Tom
On Apr 18, 2014:12:02 PM, at 12:02 PM, Jamal Hadi Salim <[email protected]>
wrote:
> I dont think a post like this is useful.
> State your reasons please - just cheering on is not helpful.
>
> cheers,
> jamal
>
> On Fri, Apr 18, 2014 at 11:26 AM, Thomas Nadeau <[email protected]>
> wrote:
>>
>> Sorry for the top post, but I wanted to inject that for the record,
>> Brocade is in favor of using RestConf/Yang (or variations of those) for
>> I2RS. We have no interest in using FORCES as the basis for this.
>>
>> --Tom
>>
>>
>> On Apr 18, 2014:10:20 AM, at 10:20 AM, Jamal Hadi Salim <[email protected]>
>> wrote:
>>
>>> On Fri, Apr 18, 2014 at 9: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.
>>>>
>>>
>>> Thanks for being sincere Dean.
>>> First, I will say I empathize with your view above (I understand such
>>> a view is motivation
>>> for many unfortunately often disguised as technical opinion). While i
>>> empathize, I would like
>>> to point that we need to have these discussions which are technical
>>> otherwise there is
>>> no point in having a standard.
>>> In any case I get where you are coming from.
>>>
>>>> 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.
>>>
>>> Maybe we'll bring up the topics sequentially as the thread proceeds -
>>> I'll start with
>>> 1 or 2 of what i think are requirements against protocol/model so we
>>> dont have to
>>> respond to long emails. If you have issues with ForCES please bring
>>> them up as well
>>> and we can discuss (I brought up a few in my presentation).
>>>
>>> One of the issues was throughput and latency.
>>> You stated in London that you want to be able to do a large amount of
>>> updates/sec.
>>> Other than you - I cant get anyone else to say this is a requirement.
>>> I do believe it is.
>>> It will be useful for example to come up with some hand waving numbers
>>> against
>>> some agreed-to info model (eg the rib) and see how this requirement is
>>> met by the
>>> different protocols.
>>>
>>> As for the model, I'd like to quote from the minutes what Tom Petch
>>> (who i consider to
>>> be a sage in this space):
>>> "If I was writing an info model I'd use YANG every time. But if I was
>>> writing a data
>>> model I'd go for ForCES."
>>> And this is rooted in the nature of Yang being intended for Config.
>>>
>>> There is also the issue of i2rs ability to describe instances which is
>>> lacking in Yang;
>>> but maybe leave that out to a different email..
>>>
>>> cheers,
>>> jamal
>>>
>>>> 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.
>>>>
>>>
>>> _______________________________________________
>>> 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
