Re: [netconf] Augmenting rpc-reply

> On Sep 10, 2020, at 12:52 PM, Martin Björklund <mbj+ietf@4668.se> wrote:
> 
> "Jan Lindblad \(jlindbla\)" <jlindbla=40cisco.com@dmarc.ietf.org <mailto:jlindbla=40cisco.com@dmarc.ietf.org>> 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:
>> 
>> 
>>     <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?
> 
> The answer should be yes, this is legal, and it looks like this:
> 
>  augment /nc:edit-config/nc:output {
>    leaf note {
>      type string;
>    }
>  }
> 
> And:
> 
>      <rpc-reply message-id="101"
>                 xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
>        <ok/>
>        <note xmlns="my-namespace">abc...</note>
>      </rpc-reply>
> 
> 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:
> 
>      <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.
> 
> 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.

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.

>> 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
>> 
> 
> 
> 
> /martin
> 
> _______________________________________________
> netconf mailing list
> netconf@ietf.org <mailto:netconf@ietf.org>
> https://www.ietf.org/mailman/listinfo/netconf <https://www.ietf.org/mailman/listinfo/netconf>