Re: [netconf] Augmenting rpc-reply

Kent Watsen <kent@watsen.net> Thu, 10 September 2020 18:48 UTC

Return-Path: <01000174795889dc-006f122c-3f97-4738-a065-7f514ec544a6-000000@amazonses.watsen.net>
X-Original-To: netconf@ietfa.amsl.com
Delivered-To: netconf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 02F733A0F67 for <netconf@ietfa.amsl.com>; Thu, 10 Sep 2020 11:48:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=amazonses.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZGolWGsoC-8l for <netconf@ietfa.amsl.com>; Thu, 10 Sep 2020 11:48:01 -0700 (PDT)
Received: from a8-33.smtp-out.amazonses.com (a8-33.smtp-out.amazonses.com [54.240.8.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19E413A0F69 for <netconf@ietf.org>; Thu, 10 Sep 2020 11:48:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1599763679; h=From:Message-Id:Content-Type:Mime-Version:Subject:Date:In-Reply-To:Cc:To:References:Feedback-ID; bh=2+Ux5gnHgvXHiIVLz94a06McZZ2LqBkGH/1lyRlk4eU=; b=aVSwkGE4d4md5N+saTz9VespcjpNHblDNm/hfT8waMqxGE8TM7ypdlLnCsZji22K xKOmU/AgFN3Xz8cQhm7bVszcITxKKzKf0PEe+fF5WQvkdGFclgR5nDAuvkqHcrMGTmQ MoUroZdATsrIrOsZNhGcoYykweo7Psn1gKkW5hq4=
From: Kent Watsen <kent@watsen.net>
Message-ID: <01000174795889dc-006f122c-3f97-4738-a065-7f514ec544a6-000000@email.amazonses.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_075B3824-20F7-4CC6-A2D4-70EF6D824BCD"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
Date: Thu, 10 Sep 2020 18:47:59 +0000
In-Reply-To: <20200910.185258.804843941725520730.id@4668.se>
Cc: jlindbla=40cisco.com@dmarc.ietf.org, "netconf@ietf.org" <netconf@ietf.org>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= <mbj+ietf@4668.se>
References: <FC898DB0-8306-4E23-BD34-88657D36C98B@cisco.com> <20200910.185258.804843941725520730.id@4668.se>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
X-SES-Outgoing: 2020.09.10-54.240.8.33
Feedback-ID: 1.us-east-1.DKmIRZFhhsBhtmFMNikgwZUWVrODEw9qVcPhqJEI2DA=:AmazonSES
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/yhZiVdJEwrhRMY434CMZEw3j30c>
Subject: Re: [netconf] Augmenting rpc-reply
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <netconf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netconf>, <mailto:netconf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netconf/>
List-Post: <mailto:netconf@ietf.org>
List-Help: <mailto:netconf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netconf>, <mailto:netconf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 10 Sep 2020 18:48:14 -0000


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