Re: [netconf] Augmenting rpc-reply

Martin Björklund <> Thu, 10 September 2020 16:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 470B83A0DE5 for <>; Thu, 10 Sep 2020 09:53:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.616
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: (amavisd-new); dkim=pass (2048-bit key) header.b=cVBd8gpS; dkim=pass (2048-bit key) header.b=ZWDzObvR
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id thxnb8Sm4w6K for <>; Thu, 10 Sep 2020 09:53:03 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 080883A0DE2 for <>; Thu, 10 Sep 2020 09:53:03 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 73910E0E; Thu, 10 Sep 2020 12:53:01 -0400 (EDT)
Received: from mailfrontend2 ([]) by compute2.internal (MEProxy); Thu, 10 Sep 2020 12:53:01 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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=; 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 []) by (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: <>
From: Martin =?iso-8859-1?Q?Bj=F6rklund?= <>
In-Reply-To: <>
References: <>
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: <>
Subject: Re: [netconf] Augmenting rpc-reply
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: NETCONF WG list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Sep 2020 16:53:04 -0000

"Jan Lindblad \(jlindbla\)" <> wrote:
> 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;


      <rpc-reply message-id="101"
        <note xmlns="my-namespace">abc...</note>

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"
        <note xmlns="my-namespace">abc...</note>

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