Re: [netconf] Augmenting rpc-reply

[Martin Björklund <[e-mail]>]

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


> 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