Andy,
On Fri, Dec 18, 2015 at 12:02 PM, Kent Watsen <kwat...@juniper.net
<mailto:kwat...@juniper.net>> wrote:
Hi Robert,
I agree that -01 doesn’t add much on top of -00. This is expected
as we’re in the fit and finish phase. If you want to help finish
the draft, then please consider responding to one of these threads:
http://www.ietf.org/mail-archive/web/netmod/current/msg14587.html
(re: rollback-on-error)
http://www.ietf.org/mail-archive/web/netmod/current/msg14641.html
(re: model-structure)
As for this thread:
1. Regarding adding an explicit backwards-compatibility
requirement, please note that what was written here is still in
effect:
http://www.ietf.org/mail-archive/web/netmod/current/msg14629.html.
Note that no objections have been raised yet, so this will likely
happen.
2. Regarding adding an applicability statement, there is currently
only one voice asking for it, which isn’t enough to warrant a change.
I did not ask to add an AS to the charter.
I don't think the WG agrees enough on the problem to write such a
document.
I hope that nobody disagrees that the operational state design and how
to structure the models are the two blocking factors to publish YANG
models. If you disagree or don't see this, let me know, I should
communicate better.
I hope that nobody disagrees that there is a problem to be solved (a
problem statement extracted from
https://datatracker.ietf.org/doc/draft-openconfig-netmod-opstate/). We
havea bunch of operators <http://www.openconfig.net/participants>,
coming to the IETF, telling us they have a problem. So there is a problem.
I hope that nobody really believes that because some people in IETF (or
in any other SDOs) thinks that what those operators want is a bad idea,
those operators will not get what they request/pay for from their suppliers.
Regards, Benoit (OPS AD)
Thanks,
Kent
Andy
On 12/18/15, 6:33 AM, "netmod on behalf of Robert Wilton"
<netmod-boun...@ietf.org <mailto:netmod-boun...@ietf.org> on
behalf of rwil...@cisco.com <mailto:rwil...@cisco.com>> wrote:
>Hi,
>
>On 17/12/2015 23:45, Randy Presuhn wrote:
>> Hi -
>>
>>> From: Robert Wilton
>>> Sent: Dec 17, 2015 1:12 PM
>>> To: Andy Bierman
>>> Cc: "netmod@ietf.org <mailto:netmod@ietf.org>"
>>> Subject: Re: [netmod] NETMOD WG LC:
draft-ietf-netmod-opstate-reqs-01
>> ...
>>> Your requirement is a bit too strong for my liking.
>>>
>>> To paraphrase your requirement text, it is forcing that all
>>> compliant NETCONF/RESTCONF servers MUST support any
clients that do
>>> not want to differentiate between intended config and applied
>>> config.
>> Do do otherwise sound to me like an interoperability disaster,
>> and would encourage the "siloization" of toolsets.
>>
>>> However, this requires all opstate aware servers:
>>>
>>> - To handle a mix of clients, some of which are opstate
aware, and
>>> some that are not.
>> This seems perfectly reasonable. To do otherwise torpedoes the
very
>> notion of interoperability.
>>
>>> - To potentially handle a mix of requests, some of which are
>>> opstate aware requests, and some are not.
>> Ditto.
>>
>>> It also prevents:
>>>
>>> - Having a server that is implemented to only support
opstate aware
>>> clients.
>> Avoiding the creation of such servers sounds like a *good*
thing to me.
>>
>>> - Having a server side configuration knob to control the
behaviour
>>> (since it would affect the semantics for all clients).
>> This also sounds like something which it would be desireable to
prevent.
>>
>> I think I'm squarely with Andy on this one.
>
>Taking a step back ...
>
>I am probably way off the mark, but my perception is that some
(perhaps
>many) of the folks in the WG still perceive that the opstate
>requirements are niche requirements for some unusual scenarios,
and that
>everyone else is happy with the status quo and don't want/need them.
>
>Alas, I don't share that view. For me, the opstate requirements
can be
>summarized as saying that the operators just want to know what
>configuration the device is actually running in a format that is
>convenient for them to use. This really doesn't appear to be
>unreasonable request to me, and if I was writing to a network
>manageability API then I would choose to use opstate because I
perceive
>that it is a more robust and easier to use API. The counter
arguments
>appear to be that it is too hard for devices to provide this
>information, and that the operators have historically managed
without it.
>
>However, I think that several things have changed, and hence negate
>these counter arguments: (i) the operators want to have much more
>automation and management over their devices, (ii) they have
found a way
>to group together and have a more vocal voice about what they
need and
>want, (iii) the operators have realized that they don't need to
wait for
>the SDOs and can create defacto standard models on their own if they
>have to.
>
>Personally, I would like us to stop spending time churning on the
>requirements and actually get on to discussing the solutions. To be
>honest, there has been relatively little change in my
understanding of
>the requirements from reading draft-openconfig-netmod-opstate-01
back in
>July, and I was expecting to discuss the solution drafts back in
>September. Here we are in December, and I'm not convinced that
we have
>truly made significant progress.
>
>The only reason that I submitted a solution draft to this problem was
>because I thought it unlikely that OpenConfig would support a
multiple
>datastore solution, and I could see strong resistance amongst the
IETF
>engineers to the proposed OpenConfig solution. I was hoping that my
>proposed solution might be seen for the compromise that it is between
>the two opposing positions. But I care less on what the solution is,
>and more whether we can agree on one and move forward.
>
>As someone that is quite new to SDO processes, my main concern is
that
>IETF (and other standards bodies) are moving too slowly here, and
that
>by the time that IETF have produced a sufficiently complete set
of YANG
>models to manage network devices it will be too late because the
>industry will already have converged on the OpenConfig models, which
>although not perfect, are close to being usable now, and are being
>evolved at a much quicker pace ...
>
>So my hope for the early new year is that we can reach common ground
>with OpenConfig and converge on a single set of YANG modules for
>managing network devices, and that includes having a solution to the
>Opstate problem.
>
>Finally, if my acquiescing to Andy's requirement is helpful to
move this
>process forward then that is fine with me. As I have previously
>indicated, I don't really think that it helps with framing or
discussing
>the solutions, but equally I can live with it since I suspect
that the
>solutions are likely to comply with it anyway.
>
>Apologies for the long email, and given I may not be actively reading
>the WG emails over the next couple of weeks, I'll wish you all happy
>holidays!
>
>Thanks,
>Rob
>
>>
>> Randy
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org <mailto:netmod@ietf.org>
>> https://www.ietf.org/mailman/listinfo/netmod
>> .
>>
>
>_______________________________________________
>netmod mailing list
>netmod@ietf.org <mailto:netmod@ietf.org>
>https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org <mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
