Re: [netconf] Augmenting rpc-reply

[Andy Bierman <[e-mail]>]

Hi,

I do not understand why this issue is causing confusion.
RFC 6241 specifies the NETCONF protocol messages.
RFC 7950 defines the data model that would be considered
data returned from the operation.

Note that the <ok/> element is not defined in YANG at all.
Note also that sec 4.4 is quite clear about not adding the <ok/>
element if data is returned:

   The <ok> element is sent in <rpc-reply> messages if no errors or
   warnings occurred during the processing of an <rpc> request, *and no
   data was returned from the operation.*


>From the protocol POV it does not matter if the data comes from the
rpc-stmt or
from an augment-stmt.

In the provided example, <note> would be sent and not <ok/>.
Any NETCONF client that claims to support YANG must expect and accept the
augment.


Andy


On Fri, Sep 11, 2020 at 5:59 AM Martin Björklund <[e-mail]> wrote:

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