Hi Andy,
On 17/12/2015 22:14, Andy Bierman wrote:
On Thu, Dec 17, 2015 at 1:52 PM, Andy Bierman <[email protected]
<mailto:[email protected]>> wrote:
Hi,
I think the current operations need to continue to work.
With the current <edit-config> or <commit> the client does
not know if the server applied the config or just accepted the
request.
With the new solution, I expect that a client that does not
explicitly ask
for "wait until applied" will get the old (unspecified) behavior.
Andy
On Thu, Dec 17, 2015 at 1:12 PM, Robert Wilton <[email protected]
<mailto:[email protected]>> wrote:
Hi Andy,
Thanks for resending and apologies for missing it earlier.
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.
However, this requires all opstate aware servers:
- To handle a mix of clients, some of which are opstate
aware, and some that are not.
- To potentially handle a mix of requests, some of which are
opstate aware requests, and some are not.
This is simple to achieve by adding optional parameters that a new
client will set
and an old client will not know about.
My point is really that it may be harder for servers to support clients
using a mix of semantics.
It still feels to me that at this stage of just considering/comparing
solutions we shouldn't rule out a server potentially being able to
declare that it only supports/implements opstate-aware semantics, which
I think that your requirement would. For some devices, if all customers
are only asking for opstate-aware semantics, then do we really also have
to support the non opstate-aware semantics as well?
It also prevents:
- Having a server that is implemented to only support opstate
aware clients.
- Having a server side configuration knob to control the
behaviour (since it would affect the semantics for all clients).
Not true, since the current RFC behavior is undefined.
A server vendor can choose right now to only return <rpc-reply> after
all intended is applied.
The new feature will be that a client can explicitly request this behavior
and a compliant server will support it. If the client does not
request it, then
there is a chance that operations will time out that did not use to
time out.
This will be very visible and disruptive to operators, and perceived
as a bug.
Technically the bug would be in the client rather than the server here,
but I don't deny that the client operator would necessarily perceive it
the same way. But shouldn't this be up to the implementer to weight up
the benefits of a potentially simpler server solution vs the impacts to
existing clients?
Personally, I think that the best solutions will likely meet
your proposed requirement below, but I don't agree that it
should be mandated, even though I agree that it is something
that the solution should aim for.
Changing the MUST to SHOULD would make the requirement fine
with me ...
Finally, regarding your example below, I didn't think that the
existing NETCONF protocol semantics specify exactly when the
server is required to respond to the client, and hence
blocking the client until the configuration has been applied
would be a valid edit-config implementation under the existing
NETCONF specification.
Yes it would be valid, but it might generate unhappy customers with broken
client applications just the same.
It still doesn't feel like a good requirement that states that an
opstate-aware server must preserve support for some existing, but
unspecified, behaviour. If the new more tightly defined behaviour is
compliant with the existing unspecified behaviour then it feels like
that should be a valid implementation choice to treat both of them the
same way.
Thanks,
Rob
Thanks,
Rob
Andy
On 17/12/2015 18:26, Andy Bierman wrote:
Hi,
I already did that:
All existing protocol
functionality for NETCONF and RESTCONF MUST continue to
work
for clients which do not choose to examine the
differences between
intended config and applied config.
Another way to put it:
The client MUST choose to participate (opt-in).
An example of a solution that meets this requirement
- The client adds a <wait-until-applied /> flag to an
edit-config request
which causes the server to wait until the edit is applied
before returning <rpc-reply>.
This requires the server to opt-in for the wait, and it is
not forced on the client.
Andy
On Thu, Dec 17, 2015 at 10:18 AM, Robert Wilton
<[email protected] <mailto:[email protected]>> wrote:
Hi Andy,
Please can you state the specific text that is being
proposed to be added as a new requirement?
Thanks,
Rob
On 17/12/2015 17:33, Andy Bierman wrote:
Hi,
I am not commenting on the solution proposals.
The document being discussed is the requirements document.
I agree with Juergen that backward compatibility needs
to be an
explicit requirement. Are you objecting to such a
requirement?
Andy
On Thu, Dec 17, 2015 at 9:29 AM, Robert Wilton
<[email protected] <mailto:[email protected]>> wrote:
Hi Andy,
Please can you let me know whether you think that
any of the three proposed solutions wouldn't meet
this backwards compatibility requirement?
draft-kwatsen-netmod-opstate-00 has some features
that might be generally useful to NETCONF, like
adding <get-state> support as defined in section
5.1, that I would expect could just be added to a
future version of NETCONF. Would a requirement that
the solution is backwards compatible with existing
implementations require that support for <get-state>
must always be optional? Or could a new version of
the NETCONF protocol require that support for
<get-state> is required?
Thanks,
Rob
On 17/12/2015 16:06, Andy Bierman wrote:
Hi,
I agree with Juergen that this should be clear.
It was discussed several times. All existing protocol
functionality for NETCONF and RESTCONF MUST
continue to work
for clients which do not choose to examine the
differences between
intended config and applied config.
Andy
On Thu, Dec 17, 2015 at 6:36 AM, Kent Watsen
<[email protected] <mailto:[email protected]>>
wrote:
>>>I’m struggling a bit to understand what is
motivating you to ask this question. That
is, as a tool vendor, I wouldn’t think that any
decision made here would affect you
immediately. My expectations are that any
impact to YANG/NETCONF/RESTCONF would be
backwards compatible, such that implementations
would only opt-in when needed - a pay as you
grow strategy. But herein perhaps lies an
unstated requirement, that the impact to
YANG/NETCONF/RESTCONF needs to be backwards
compatible with respect to existing
deployments. Did we miss it or is it too obvious?
>>>
>>
>> It may be obvious for many of us but for the
sake of completeness I
>> prefer to have this backwards compatibility
assumption explicitely
>> stated.
>
>+1
[as a chair]
As last call comment, there seems to be support
for adding a requirement to the opstate-reqs
draft to state that solutions supporting said
requirements MUST be backwards compatible with
respect to existing deployments. Do we have WG
consensus to add this as a requirement to this
draft? Are there any objections? Please voice
your opinion before the last call cutoff date
(Dec 30).
[as a contributor]
I’m unsure if it makes sense to call it out in
this draft, in that it seems universally
applicable, but I don’t see any harm in it
either and thus do not object.
Kent
_______________________________________________
netmod mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected] <mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/netmod
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
