Re: [netconf] Augmenting rpc-reply

[BL <[e-mail]>]

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

"Jan Lindblad \(jlindbla\)" <jlindbla=[e-mail]> 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.

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

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


/Borislav

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
[e-mail]
https://www.ietf.org/mailman/listinfo/netconf" rel="nofollow">https://www.ietf.org/mailman/listinfo/netconf