Re: [netconf] Augmenting rpc-reply

Andy Bierman <andy@yumaworks.com> Fri, 11 September 2020 16:43 UTC

Return-Path: <andy@yumaworks.com>
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 C54573A14DD for <netconf@ietfa.amsl.com>; Fri, 11 Sep 2020 09:43:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.887
X-Spam-Level:
X-Spam-Status: No, score=-1.887 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.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 K8M_xlb_hzBp for <netconf@ietfa.amsl.com>; Fri, 11 Sep 2020 09:43:52 -0700 (PDT)
Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C5023A1494 for <netconf@ietf.org>; Fri, 11 Sep 2020 09:43:51 -0700 (PDT)
Received: by mail-lf1-x131.google.com with SMTP id d15so6471209lfq.11 for <netconf@ietf.org>; Fri, 11 Sep 2020 09:43:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=iZHRcoAj6mxO9EUleHdz8si6IPqTLd99wMcpSdmoNo8=; b=ndAk+Ps83H4oc+txeRXBjdfx0NeKSuXYL1jmc+2KMRF9pVymTIUMFwp65GCx+/3xUx 40ueVWcDKHE6Zo9Ue48zq5SEXylyuv2ljy4UkW8YXaoyd/g3FiATcW9OnRxMFbm5EkAR fLNI5SIKUC/a0XPlSWInTh1Cr0G2Xj7qX5L8ZZ8xWfjv/YoXXVpPo2brTtkKFF9lhKT1 YdpRDIN51dKpQx3ufhKSeztz6x6agZlSoMDBbf+n/+0igFKn/wZfeisXuLK73tBVBtyp dXL/Z4kqSrf4wA2+dFufzSLDn76fqxIXEjkeHZvC8QfZy92KJ1bAYJdj1HbNWMz5covZ IuvQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=iZHRcoAj6mxO9EUleHdz8si6IPqTLd99wMcpSdmoNo8=; b=IixMGogxQJblVb/GZ9qWua+GUz4sB2DGeiR+pTfaCW6MeyZsL8O1H6iGbXj+0Et5Yi jeePb+uOzbmbFdyp70R2Kk+re+8JRp6NFVGAcvS6USGlLq7HBVQYCYMFGVrW9M5oOZbu fU8IiHu2d52mwbZJkqguijf2QSlu6IZrzXzq3IXmVf5pjzPeq7INaubbZ0mx+44SiUQR 8tzYMwsmy7YDNJrh50ug6UcypY7aJfD4bGVqKw1coloD9XMfk26Is1R37oAQWK9p5Kw8 hb5oKZjRXgdFjlyZM6WI9rQZsJbZL7KtalMXxny1zXNGRli5EUYz/PhXiLbQLy3XQOMv RArA==
X-Gm-Message-State: AOAM531WA0O8p9Sye1uWvm00a4PK/Vc6ZYcSFgiyLJkXV8RfX0/YlVHx 1h7rC3ASaEZ9k0UKpchKjA1jTBQKuH0O580TPOUWTA==
X-Google-Smtp-Source: ABdhPJxRfD4uGoRHjwqYae9DJLvwGEGbwBDz7wrf+4kvGXwPU/trvPERan7c9NQp2qVbqL14U4juyY2xzDfXJgYf0/w=
X-Received: by 2002:a19:e54:: with SMTP id 81mr1105318lfo.178.1599842629226; Fri, 11 Sep 2020 09:43:49 -0700 (PDT)
MIME-Version: 1.0
References: <20200910.185258.804843941725520730.id@4668.se> <CABCOCHQnw_H=W0Sgian7LyLgTABMu_Xg+YPfxe5Yx+wJ13074Q@mail.gmail.com> <0CCA567F-5691-4A85-812C-0B95470E5C6C@cisco.com> <20200911.145932.1721440341637757560.id@4668.se>
In-Reply-To: <20200911.145932.1721440341637757560.id@4668.se>
From: Andy Bierman <andy@yumaworks.com>
Date: Fri, 11 Sep 2020 09:43:38 -0700
Message-ID: <CABCOCHR-XkSuRvsGYpoeZHEEnHXr-3p-qjiLvEkBo7D+oYNNpQ@mail.gmail.com>
To: =?UTF-8?Q?Martin_Bj=C3=B6rklund?= <mbj+ietf@4668.se>
Cc: jlindbla@cisco.com, Netconf <netconf@ietf.org>, bl@ndt-inc.com, Kent Watsen <kent@watsen.net>
Content-Type: multipart/alternative; boundary="0000000000009caa1005af0c638d"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/0cT6fkRsQ8zHw2asUQ4RMlH_A1I>
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 16:43:59 -0000

Hi,

I do not understand why this issue is causing confusion.
RFC 6241 specifies the NETCONF protocol messages.
RFC 7950 defines the data model that would be considered
data returned from the operation.

Note that the <ok/> element is not defined in YANG at all.
Note also that sec 4.4 is quite clear about not adding the <ok/>
element if data is returned:

   The <ok> element is sent in <rpc-reply> messages if no errors or
   warnings occurred during the processing of an <rpc> request, *and no
   data was returned from the operation.*


>From the protocol POV it does not matter if the data comes from the
rpc-stmt or
from an augment-stmt.

In the provided example, <note> would be sent and not <ok/>.
Any NETCONF client that claims to support YANG must expect and accept the
augment.


Andy


On Fri, Sep 11, 2020 at 5:59 AM Martin Björklund <mbj+ietf@4668.se> wrote:

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