Re: [netconf] Augmenting rpc-reply

["Jan Lindblad (jlindbla)" <[e-mail]>]

Dear NETCONF WG,

Thank you all for contributing viewpoints. Actually, these answers were a surprisingly faithful reflection of the internal discussion we had, which prompted us to to take the question to the list.

Since there was clearly no rough consensus on the matter, let me voice the counter arguments we had in our internal discussion for those arguments that were also mentioned here on the list, in order to see if we can distill at least some order in this.

Martin suggested that:

However, RFC 7950 says in section 7.14.4:

   If the RPC operation invocation succeeded and no output parameters
   are returned, the <rpc-reply> contains a single <ok/> element defined
   in [RFC6241].

Is it reasonable to interpret this 7950 language to exclude any and all extensions? One could argue that this prescribes a single <ok/> as far as 7950 and 6241 are concerned, but not ruling out extensions.

Which seems to say that if a note is returned, you would get:

      <rpc-reply message-id="101"
                 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
        <note xmlns="my-namespace">abc...</note>
      </rpc-reply>

This is also consistent with the XSD in RFC 6241.

XSDs always speak about what they require in their targetNamespace, and have no "jurisdiction" over other namespaces. Thus XSDs have no way of precluding extensions. Is it reasonable therefore to conclude then that the NETCONF XSDs cannot be taken as evidence either for or against extensions?

The problem with this though is that clients probably check for the
presence of "ok" to verify that an edit-config succeeds, hence I think
it should be allowed to reply with both <ok/> and additional elements,
as examplified above.

It seems reasonable to assume most or all NETCONF servers would send, and most clients would look for <ok/> in the rpc-reply. If anyone has a counter example (i.e. can name an implementation that does not), please speak up.

Andy suggested that:

I think this change is not backward-compatible because a conformant implementation
might follow the XSD, which clearly shows "ok" as a choice, not mixed with the other
responses.

If XSDs have no way of expressing the absence of tags in foreign namespaces, and properly written XML parsing applications generally are made to skip over tags and attributes in unknown namespaces, would it be reasonable to say that extensions are backwards compatible? This is the theoretical part of the question.

The other part is more practical: Assuming the theory is true, would the NETCONF WG have the courage to call any implementation that does not follow these XML/XSD principles incorrect?

Kent suggested that:

I don’t think this would be enough, as client-validate of the response might fail unless they know about the “my-namespace” schema.  For interoperability, it would be best for the clients to send something in the request (or have something in their profile) indicating that they’re able to process the extended response.

The discussion about well behaved clients is already captured above, but the angle about the client side sending capability strings in hello is new. In what situations would such a client side capability declaration be required? What YANG augments would only be sent to clients that have declared knowledge of them, and which augments would always be sent?

For a longterm solution, please consider adding to the NETCONF-next tracker: https://github.com/netconf-wg/netconf-next/issues.  We might also want to consider the feasibility of doing the same for RESTCONF, as currently RFC 8040 states that 204 (No Content) “is returned” for PUT and DELETE requests.

Good point. Is it reasonable to believe many RESTCONF clients would fail if a server returned a different 2xx code and a body rather than 204? And if so, would such a RESTCONF client be considered well behaved?

Borislav also commented, but I believe the topics are already covered in the above.

Best Regards,
/jan