Re: [netconf] Augmenting rpc-reply

Martin Björklund <mbj+ietf@4668.se> Thu, 10 September 2020 16:53 UTC

Return-Path: <mbj+ietf@4668.se>
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 470B83A0DE5 for <netconf@ietfa.amsl.com>; Thu, 10 Sep 2020 09:53:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.616
X-Spam-Level:
X-Spam-Status: No, score=-0.616 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, PDS_NAKED_TO_NUMERO=1.482, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=4668.se header.b=cVBd8gpS; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=ZWDzObvR
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 thxnb8Sm4w6K for <netconf@ietfa.amsl.com>; Thu, 10 Sep 2020 09:53:03 -0700 (PDT)
Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 080883A0DE2 for <netconf@ietf.org>; Thu, 10 Sep 2020 09:53:03 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 73910E0E; Thu, 10 Sep 2020 12:53:01 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Thu, 10 Sep 2020 12:53:01 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=4668.se; h=date :message-id:to:cc:subject:from:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=fm2; bh= bvgivuNKv4rbxKFuz6Mm8CNZmhyN3unOiq4cLGJZfFU=; b=cVBd8gpSmKGxtuKQ kklN23s0YWj8lO9kGDrDkM3uLcZOrrrsyvp4fY8+Pwr6SgdmQADcBsKjCBhIaBjY wTGxxBGWEWzPL83yBkWudocaU5xSLLSaFhwTZ1XTHXeLxN5QEdlPFq/YsXS/3TEE KzpUB2Yo5zkNeBB2XCOcmgk8X7uxwdmLJpx0CWgsMGLtVGxyu4Sc5u0Ydf+0GbvJ xuok70H4lB7mx04AZVJnhUCRxbhInPfunq50cBPOHxvfYVuvG+3oaBYJ+sa1Ztjt frjilGqtAIdLz+QMcaMeTWU+N4ZtWmOiUETwt5lr5t41kIoovGP2pISlxa7VO+B/ PZl3Jg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm3; bh=bvgivuNKv4rbxKFuz6Mm8CNZmhyN3unOiq4cLGJZf FU=; b=ZWDzObvRRh9CQv2mTuDVSHoPTwpBbwVTPRps6fOl7UY4p3cxVmeaOqW9e Dr60q0KWWUFOlOy1F6Am+cHwiGmKc5i51xfa/cEpete0klcjO7TDh9iqD3lF8fXB YW6q0qjgaqeWsCwNG+D4Iej6+Z4fYQufdtn09E2UjglHyEExLJbX9RyA7aQxZDbj USU/eTjuNMIODLMpE66gfn2cToXrlgsNcTZLQwYZbMsNVQvOAG9HklOcRTJnDKW8 9j3tmIIV5xYhvolBlvR6x8EZVTaupeapEJQ+9eA3tXC0UYVtHzMtUSTz61FrGeyE vKbR5laMhvg+rUvbMRPapamykJuDA==
X-ME-Sender: <xms:7FlaX6dwzwPduycod_idRHeYd_GPWCbS3VH9Cprj2WRLe-V6ImVlxw> <xme:7FlaX0Mdc_IUWopXL7285YqjSjH_YMKIVl2zvjkqqATdRP5hpmVt1tnpX5hSdcEY2 HtqgKLMxm7fISXVlUY>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudehjedguddttdcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepfffkvffuhfgjfhfogggtgfesth ejredtredtvdenucfhrhhomhepofgrrhhtihhnuceujhpnrhhklhhunhguuceomhgsjhdo ihgvthhfseegieeikedrshgvqeenucggtffrrghtthgvrhhnpedtgefgtdduudejkeelve dviedvveehieegfeefteefgfeffeekheffvdefveffgfenucfkphepudehkedrudejgedr gedrgeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrghilhhfrhhomh epmhgsjhdoihgvthhfseegieeikedrshgv
X-ME-Proxy: <xmx:7FlaX7j_cbJV7NyLOSRw_nQxfmfdOtj6EqVAXh550NRPmCcvEvG5bw> <xmx:7FlaX3-dzPh_MTpxQrNDS_GgJS9oWDDYk65h_zDJ3seG8tK6-It2cA> <xmx:7FlaX2vt9lNKVAW-gGSFCfCcgI1zp6jxS_Y5jVOIVoGkQBBFWx8SKA> <xmx:7VlaX36VdgcCBoIXaGg_O8SFrNOLG-lGMkqOA4msZ_bcd_Pg9JmukQ>
Received: from localhost (unknown [158.174.4.44]) by mail.messagingengine.com (Postfix) with ESMTPA id 140DA306468D; Thu, 10 Sep 2020 12:52:59 -0400 (EDT)
Date: Thu, 10 Sep 2020 18:52:58 +0200 (CEST)
Message-Id: <20200910.185258.804843941725520730.id@4668.se>
To: jlindbla=40cisco.com@dmarc.ietf.org
Cc: netconf@ietf.org
From: Martin =?iso-8859-1?Q?Bj=F6rklund?= <mbj+ietf@4668.se>
In-Reply-To: <FC898DB0-8306-4E23-BD34-88657D36C98B@cisco.com>
References: <FC898DB0-8306-4E23-BD34-88657D36C98B@cisco.com>
X-Mailer: Mew version 6.8 on Emacs 26.3
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/dhODwsyxOYZlLWakcl9Gmv95yhQ>
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 16:53:04 -0000

"Jan Lindblad \(jlindbla\)" <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.


> 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