Re: [netconf] Augmenting rpc-reply

[Andy Bierman <[e-mail]>]

On Thu, Sep 10, 2020 at 9:53 AM Martin Björklund <[e-mail]> 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.
>
>
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




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