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"
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
https://www.ietf.org/mailman/listinfo/netmod
.
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
