Re: [netconf] Augmenting rpc-reply

Martin Björklund <> Fri, 11 September 2020 12:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0A8A63A0B23 for <>; Fri, 11 Sep 2020 05:59:43 -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_H4=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=VcvdBeAu; dkim=pass (2048-bit key) header.b=GXjQ4D3a
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Ev_J9zyPPgZr for <>; Fri, 11 Sep 2020 05:59:41 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1F6573A0B19 for <>; Fri, 11 Sep 2020 05:59:37 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal []) by mailout.west.internal (Postfix) with ESMTP id 04ED3C38; Fri, 11 Sep 2020 08:59:35 -0400 (EDT)
Received: from mailfrontend2 ([]) by compute2.internal (MEProxy); Fri, 11 Sep 2020 08:59:36 -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= wqDZC8jsDd6MH4ho/3Pw9B38j0ASK0zZ9muZFZOY3YA=; b=VcvdBeAuGOdr7Bns RbJs8sUSmH6kh2Q19tEnIYJNHoetAy2wjXyHeJsthWQpRnZfFeGpwh9hww3Wy6sT 8PyRftSzguU7ZoLV5IHv9Dt5NLnPQgbEdm/z/7IPFlM/uIaOEGd5ad9PjDo/PSoE d9ssvXfdJx8pPqZaNcA6Obb7tcOc5ko3wZMalH8gAYqSUfntg2nW5NxPsN7sW4j+ tpXulntqpoOJcjKo9I8QTIaj3zEVTnEByt9XTOSqVEoivMLBxie0LffvJUAtCRWV aj35XzHMeX+4oC9sorCNkzl4AvrJ1B1Q+XepEuZ2LUTbdo65Pel0A4URTb9ko2MQ Ovamwg==
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=wqDZC8jsDd6MH4ho/3Pw9B38j0ASK0zZ9muZFZOY3 YA=; b=GXjQ4D3akye4yw36fNg/IK+8cAFge2Ipjm4hEjK5oQXlrRLM92DDc9rcO +ljfxBTn9aANNSHGGPUWrDocvkqSZKBDIsMmFvjVvyYmm2gpIU6ratm94J9iWRB4 XQ/LLqSU31VBGNhXw4aGpg5OTcT5nuhTPxX19qgNYP12AlNPFNG3pz1D8El6Kjih ccGBaMwam3k5m4j5hb4+Y5ETTTNwhrWEpV5pWr+b4I9FDGrjFom5u9cP1lrXDFXc 6TeTNJTfSRqGgninYmGtsWHthI9HalSEgH0H0luC0oxHIxCk9XeuQRosYeog3dAR qjaA3thnRuE4af6+T4yJy4GLPjWlg==
X-ME-Sender: <xms:tnRbXzM4u-v3obwER9Y78BwoRqj3TTR-vgB1M8hYAwRCvqjiT9A6aw> <xme:tnRbX9_bLuQfxvg57S8b_8Ulu9irTeubN6nj4JSpoqZgZeSDk6qku9B_2g41Wo0Zx sXTjlJjsj92Mc9kioE>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduiedrudehledgieduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucenucfjughrpeffkffvuffhjghfofggtgfgsehtsg ertdertdejnecuhfhrohhmpeforghrthhinhcuuehjnphrkhhluhhnugcuoehmsghjodhi vghtfhesgeeiieekrdhsvgeqnecuggftrfgrthhtvghrnhepvdeuffegvedtfeeukeehke etffetffevheevgedvvdehffdujeevtdefiefggeelnecuffhomhgrihhnpehgihhthhhu sgdrtghomhenucfkphepudehkedrudejgedrgedrgeegnecuvehluhhsthgvrhfuihiivg eptdenucfrrghrrghmpehmrghilhhfrhhomhepmhgsjhdoihgvthhfseegieeikedrshgv
X-ME-Proxy: <xmx:tnRbXyRQckzqHSc87T_PgMuGqcfZn3RI4niEyqMbxnkLVyoRus-Sag> <xmx:tnRbX3vjv57bE_pz1qEOFvxIdc_6F-l8BQL3b07SXM1ktT-qF3ArXA> <xmx:tnRbX7chvJmfqRNjk3Y_j8U_dKFPYwgyif50oWABHgtg4THZJok_FA> <xmx:t3RbX37RyZZtQvs-IViMzBorzNrxzXfSOfPWUqCpqPOf43ttnLcj2g>
Received: from localhost (unknown []) by (Postfix) with ESMTPA id AA42A3064674; Fri, 11 Sep 2020 08:59:33 -0400 (EDT)
Date: Fri, 11 Sep 2020 14:59:32 +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=utf-8
Content-Transfer-Encoding: base64
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: Fri, 11 Sep 2020 12:59:43 -0000

"Jan Lindblad (jlindbla)" <> wrote:
> Thank you all for contributing viewpoints. Actually, these answers
> were a surprisingly faithful reflection of the internal discussion we
> had, which prompted us to to take the question to the list.
> Since there was clearly no rough consensus on the matter, let me voice
> the counter arguments we had in our internal discussion for those
> arguments that were also mentioned here on the list, in order to see
> if we can distill at least some order in this.
> Martin suggested that:
> 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].
> Is it reasonable to interpret this 7950 language to exclude any and
> all extensions? One could argue that this prescribes a single <ok/> as
> far as 7950 and 6241 are concerned, but not ruling out extensions.
> 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.
> XSDs always speak about what they require in their targetNamespace,
> and have no "jurisdiction" over other namespaces. Thus XSDs have no
> way of precluding extensions. Is it reasonable therefore to conclude
> then that the NETCONF XSDs cannot be taken as evidence either for or
> against extensions?

This is not correct.  See for example how namespace="##other" is used
in errorInfoType to explicitly allow elements from other namespaces.

> 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.
> It seems reasonable to assume most or all NETCONF servers would send,
> and most clients would look for <ok/> in the rpc-reply. If anyone has
> a counter example (i.e. can name an implementation that does not),
> please speak up.
> Andy suggested that:
> 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.
> If XSDs have no way of expressing the absence of tags in foreign
> namespaces, and properly written XML parsing applications generally
> are made to skip over tags and attributes in unknown namespaces, would
> it be reasonable to say that extensions are backwards compatible? This
> is the theoretical part of the question.
> The other part is more practical: Assuming the theory is true, would
> the NETCONF WG have the courage to call any implementation that does
> not follow these XML/XSD principles incorrect?

I think in general we expect well-behaved clients to ignore elements
from other namespaces.  But this is a special case since the XSD
explicitly does not allow elements from other namespaces together with
<ok/>  (I think that this is very unfortunate).

> Kent suggested that:
> 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.
> The discussion about well behaved clients is already captured above,
> but the angle about the client side sending capability strings in
> hello is new. In what situations would such a client side capability
> declaration be required? What YANG augments would only be sent to
> clients that have declared knowledge of them, and which augments would
> always be sent?

There is no formal way to specify how a server would react to a
client's advertised capabilities in <hello>.

> For a longterm solution, please consider adding to the NETCONF-next
> tracker:  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.
> Good point. Is it reasonable to believe many RESTCONF clients would
> fail if a server returned a different 2xx code and a body rather than
> 204? And if so, would such a RESTCONF client be considered well
> behaved?
> Borislav also commented, but I believe the topics are already covered
> in the above.
> Best Regards,
> /jan