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.
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).
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.
Thanks,
Rob
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
