Subject: [netconf] Augmenting rpc-reply

From: "Jan Lindblad (jlindbla)" <[email-masked]>
Date: Thu, 10 Sep 2020 08:27:47 +0000

Dear NETCONF WG,

We have been discussing back and forth, and several interpretations of the relevant RFCs (4741/6241 and 6020/7950) have come up. We would very much like to hear the opinions on this list to settle the question.

When a client issues an <edit-config>, a server would respond with an <ok> or <rpc-error> like this:

     <rpc-reply message-id="101"
                xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <ok/>
     </rpc-reply>

or

     <rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
       <rpc-error>
         <error-type>rpc</error-type>
         <error-tag>missing-attribute</error-tag>
         <error-severity>error</error-severity>
         <error-info>
           <bad-attribute>message-id</bad-attribute>
           <bad-element>rpc</bad-element>
         </error-info>
       </rpc-error>
     </rpc-reply>

If the NETCONF server would like to augment additional information into the rpc-reply, is that legal? If so, what would that look like? For the sake of the example, let's say the server would like to add something like this to the operation result:

<note xmlns="my-namespace">abc...</note>

While this example was for edit-config and a <note> tag, we expect this discussion should be equally applicable to other NETCONF operations with other tags or attributes in both the success (<ok>) and failure (<rpc-error>) cases.

Best Regards,
/Jan Lindblad

---

From: BL <[email-masked]>
Date: Thu, 10 Sep 2020 10:45:46 -0400

RFC 6241: 4.3. <rpc-error>
Element

error-info: ...

An implementation MAY include

additional elements to provide extended and/or implementation
specific

debugging information.

Regards

Borislav Lukovic

On 9/10/2020 4:27 AM, Jan Lindblad (jlindbla) wrote:

Dear
NETCONF WG,

We have been
discussing back and forth, and several interpretations of the
relevant RFCs (4741/6241 and 6020/7950) have come up. We would
very much like to hear the opinions on this list to settle the
question.

When a
client issues an <edit-config>, a server would respond
with an <ok> or <rpc-error> like this:

or

If the NETCONF server would like to augment
additional information into the rpc-reply, is that legal? If
so, what would that look like? For the sake of the example,
let's say the server would like to add something like this to
the operation result:

<note
xmlns="my-namespace">abc...</note>

While this example was for edit-config and a
<note> tag, we expect this discussion should be equally
applicable to other NETCONF operations with other tags or
attributes in both the success (<ok>) and failure
(<rpc-error>) cases.

Best Regards,

/Jan Lindblad

_______________________________________________
netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Martin Björklund <[email-masked]>
Date: Thu, 10 Sep 2020 18:52:58 +0200 (CEST)

"Jan Lindblad \(jlindbla\)" <jlindbla=[email-masked]> wrote:
> Dear NETCONF WG,
> 
> We have been discussing back and forth, and several interpretations of
> the relevant RFCs (4741/6241 and 6020/7950) have come up. We would
> If the NETCONF server would like to augment additional information
> into the rpc-reply, is that legal? If so, what would that look like?

The answer should be yes, this is legal, and it looks like this:

  augment /nc:edit-config/nc:output {
    leaf note {
      type string;
    }
  }

And:

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

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

This is also consistent with the XSD in RFC 6241.

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.

> For the sake of the example, let's say the server would like to add
> something like this to the operation result:
> 
> While this example was for edit-config and a <note> tag, we expect
> this discussion should be equally applicable to other NETCONF
> operations with other tags or attributes in both the success (<ok>)
> and failure (<rpc-error>) cases.
> 
> Best Regards,
> /Jan Lindblad
> 

/martin

---

From: Kent Watsen <[email-masked]>
Date: Thu, 10 Sep 2020 18:47:59 +0000

> On Sep 10, 2020, at 12:52 PM, Martin Björklund <[email-masked]> wrote:
> 
> "Jan Lindblad \(jlindbla\)" <jlindbla=[email-masked] <mailto:jlindbla=[email-masked]>> wrote:
>> Dear NETCONF WG,
>> 

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.

For a longterm solution, please consider adding to the NETCONF-next tracker: https://github.com/netconf-wg/netconf-next/issues <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.

K.

> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>

---

From: Andy Bierman <[email-masked]>
Date: Thu, 10 Sep 2020 12:31:17 -0700

> it should be allowed to reply with both <ok/> and additional elements,
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.

 <!--
        <rpc-reply> element
       -->
     <xs:complexType name="rpcReplyType">
       <xs:choice>
         <xs:element name="ok"/>
         <xs:sequence>
           <xs:element ref="rpc-error"
                       minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="rpcResponse"
                       minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
       </xs:choice>
       <xs:attribute name="message-id" type="messageIdType"
                     use="optional"/>
       <!--
          Any attributes supplied with <rpc> element must be returned
          on <rpc-reply>.
         -->
       <xs:anyAttribute processContents="lax"/>
     </xs:complexType>
     <xs:element name="rpc-reply" type="rpcReplyType"/>

Also:

4.4 <https://tools.ietf.org/html/rfc6241#section-4.4>.  <ok> Element

   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.

Andy

---

From: BL <[email-masked]>
Date: Thu, 10 Sep 2020 16:02:36 -0400

On 9/10/2020 12:52 PM, Martin Björklund
wrote:

Dear NETCONF WG,

When a client issues an <edit-config>, a server would respond with an
<ok> or <rpc-error> like this:

or

And:

Returning both <ok> and <note>  is inconsistent with
rfc6241: Appendix B:

<xs:choice>

<xs:element name="ok"/>

<xs:sequence>

<xs:element ref="rpc-error" minOccurs="0"
maxOccurs="unbounded"/>

<xs:element ref="rpcResponse" minOccurs="0"
maxOccurs="unbounded"/>

</xs:sequence>

</xs:choice>

/Borislav

Best Regards,
/Jan Lindblad

/martin

---

From: "Jan Lindblad (jlindbla)" <[email-masked]>
Date: Fri, 11 Sep 2020 12:29:54 +0000

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:

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.

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?

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:

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 11 Sep 2020 14:56:23 +0200

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

This is how I would have read this statement.
 
> This is also consistent with the XSD in RFC 6241.

This behavior might be consistent with the XSD but I suspect that some
clients get pretty confused if instead of an <ok/> that get something
they did not expect.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>

---

From: Martin Björklund <[email-masked]>
Date: Fri, 11 Sep 2020 14:59:32 +0200 (CEST)

"Jan Lindblad (jlindbla)" <[email-masked]> 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:
> 
> 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.
> 
> 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.

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

/martin

---

From: Andy Bierman <[email-masked]>
Date: Fri, 11 Sep 2020 09:43:38 -0700

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