Re: [netconf] Augmenting rpc-reply

Martin Björklund <mbj+ietf@4668.se> Fri, 11 September 2020 12:59 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 0A8A63A0B23 for <netconf@ietfa.amsl.com>; Fri, 11 Sep 2020 05:59:43 -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_H4=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=VcvdBeAu; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=GXjQ4D3a
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 Ev_J9zyPPgZr for <netconf@ietfa.amsl.com>; Fri, 11 Sep 2020 05:59:41 -0700 (PDT)
Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1F6573A0B19 for <netconf@ietf.org>; Fri, 11 Sep 2020 05:59:37 -0700 (PDT)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42]) by mailout.west.internal (Postfix) with ESMTP id 04ED3C38; Fri, 11 Sep 2020 08:59:35 -0400 (EDT)
Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Fri, 11 Sep 2020 08:59:36 -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= 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= 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=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 [158.174.4.44]) by mail.messagingengine.com (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: <20200911.145932.1721440341637757560.id@4668.se>
To: jlindbla@cisco.com
Cc: netconf@ietf.org, mbj+ietf@4668.se, andy@yumaworks.com, bl@ndt-inc.com, kent@watsen.net
From: Martin =?iso-8859-1?Q?Bj=F6rklund?= <mbj+ietf@4668.se>
In-Reply-To: <0CCA567F-5691-4A85-812C-0B95470E5C6C@cisco.com>
References: <20200910.185258.804843941725520730.id@4668.se> <CABCOCHQnw_H=W0Sgian7LyLgTABMu_Xg+YPfxe5Yx+wJ13074Q@mail.gmail.com> <0CCA567F-5691-4A85-812C-0B95470E5C6C@cisco.com>
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: <https://mailarchive.ietf.org/arch/msg/netconf/eATicmOflxCh9X4Cmok6fPYA-h8>
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: Fri, 11 Sep 2020 12:59:43 -0000

"Jan Lindblad (jlindbla)" <jlindbla@cisco.com> wrote:
> Dear NETCONF WG,
> 
> 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: 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.
> 
> 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
> 



/martin