Re: [netconf] Augmenting rpc-reply

[Martin Björklund <[e-mail]>]

"Jan Lindblad (jlindbla)" <[e-mail]> wrote:
> 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?

This is not correct.  See for example how namespace="##other" is used
in errorInfoType to explicitly allow elements from other namespaces.

> 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?

I think in general we expect well-behaved clients to ignore elements
from other namespaces.  But this is a special case since the XSD
explicitly does not allow elements from other namespaces together with
<ok/>  (I think that this is very unfortunate).

> 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?

There is no formal way to specify how a server would react to a
client's advertised capabilities in <hello>.


> 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
> 



/martin