Re: [netconf] Augmenting rpc-reply

Andy Bierman <andy@yumaworks.com> Thu, 10 September 2020 19:31 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 E2F703A10AD for <netconf@ietfa.amsl.com>; Thu, 10 Sep 2020 12:31:32 -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 MdVwsbJDQ87N for <netconf@ietfa.amsl.com>; Thu, 10 Sep 2020 12:31:31 -0700 (PDT)
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com [IPv6:2a00:1450:4864:20::134]) (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 A165F3A1128 for <netconf@ietf.org>; Thu, 10 Sep 2020 12:31:30 -0700 (PDT)
Received: by mail-lf1-x134.google.com with SMTP id d15so4205224lfq.11 for <netconf@ietf.org>; Thu, 10 Sep 2020 12:31:30 -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=dchW3WdRTXUgFwuVmMMiR5epI+mkFlpSGGYbU9acQSw=; b=pHCumdzgfCWHmH2hjAS20oZZlgx9JsgEre4pLwB/uTqLB1ZeEu22PmfFL4aQv8Hqv9 LRV1NrzBgLHJAaIL+CBxd8T1SmicoJQCWbYjpXA5nDmL8Lpvjxud9DzEO48TSkHfnw/o xz51+sLQcsEiKMQXJggJRirhNxFVFWlha57I+D4FS4KYmnQRFtP0HkGma80Sdz57BTp9 xCEUaFzNZN5TdQCKgac6hGCkYunyPyru5Sk4r4yn8AZDvJLZv1d3pISauIp9Ta4wlVGm +XzpGt4L0ERnim0pz8y+p/RrrHNB8v1WAEyMHtOUrSm1RXmYyg0s7uD9vUiwg5ovVm45 btlQ==
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=dchW3WdRTXUgFwuVmMMiR5epI+mkFlpSGGYbU9acQSw=; b=UV6f3bXkMf9vcynrjYWXu3Ui9RhJsmgsl9oyoaNDIwsjcqAenKOidN4VRsfhkYLxtO 36oH5/+pgwwm+28xRtr68zxMyfg4awclJcc5EuR2sd1/k4DpxNsukD7DraG1LOHtN0N9 zqxez57Nr+39OfMAoFsi00EryMr+Aip1hLRGxTooLaWdAQRXymYQ2Uttcgn6vq8Kj2tC UdXxFR9gmk/nirjjUzeoO/9OafNdN6x2fwTy8cr0RgCK6Fs+dQ/evszTb5IbtfMe9wkP LvZ1wUQ2PRxChae3NvtaG2mM4+a/bZ9nFfcgvnEx12h769j/kDjkM2qEjlf2ud4gvlTm 4nmA==
X-Gm-Message-State: AOAM532F7CRpkoIPn5QpFxhb/qBXuk/pV1lIPQQ4CnXLpYRdJAtYFolM Rd9KwuFjdGB6zi4klDAPL2j1ZZ7gle2YBuBSeRwQZw==
X-Google-Smtp-Source: ABdhPJwSvMjCxVzg651R/+BrPYaakhiuBYjOCZW47XLGkDPF5fSDh8mkbHUpf7GfGk+fmkIpbE4kr9ZCtdscImwOcFg=
X-Received: by 2002:a19:ee0d:: with SMTP id g13mr4874095lfb.139.1599766288640; Thu, 10 Sep 2020 12:31:28 -0700 (PDT)
MIME-Version: 1.0
References: <FC898DB0-8306-4E23-BD34-88657D36C98B@cisco.com> <20200910.185258.804843941725520730.id@4668.se>
In-Reply-To: <20200910.185258.804843941725520730.id@4668.se>
From: Andy Bierman <andy@yumaworks.com>
Date: Thu, 10 Sep 2020 12:31:17 -0700
Message-ID: <CABCOCHQnw_H=W0Sgian7LyLgTABMu_Xg+YPfxe5Yx+wJ13074Q@mail.gmail.com>
To: =?UTF-8?Q?Martin_Bj=C3=B6rklund?= <mbj+ietf@4668.se>
Cc: jlindbla=40cisco.com@dmarc.ietf.org, Netconf <netconf@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000005bc39d05aefa9dcc"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/im5dPccV8jbAXfbx9iKy4Qo4RMg>
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 19:31:44 -0000

On Thu, Sep 10, 2020 at 9:53 AM Martin Björklund <mbj+ietf@4668.se> wrote:

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



 <!--
        <rpc-reply> element
       -->
     <xs:complexType name="rpcReplyType">
       <xs:choice>
         <xs:element name="ok"/>
         <xs:sequence>
           <xs:element ref="rpc-error"
                       minOccurs="0" maxOccurs="unbounded"/>
           <xs:element ref="rpcResponse"
                       minOccurs="0" maxOccurs="unbounded"/>
         </xs:sequence>
       </xs:choice>
       <xs:attribute name="message-id" type="messageIdType"
                     use="optional"/>
       <!--
          Any attributes supplied with <rpc> element must be returned
          on <rpc-reply>.
         -->
       <xs:anyAttribute processContents="lax"/>
     </xs:complexType>
     <xs:element name="rpc-reply" type="rpcReplyType"/>

Also:

4.4 <https://tools.ietf.org/html/rfc6241#section-4.4>.  <ok> Element

   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.



Andy




>
> > 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
>
> _______________________________________________
> netconf mailing list
> netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf
>