Re: [netconf] Augmenting rpc-reply

BL <bl@ndt-inc.com> Thu, 10 September 2020 14:45 UTC

Return-Path: <bl@ndt-inc.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 619EB3A0C45 for <netconf@ietfa.amsl.com>; Thu, 10 Sep 2020 07:45:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.947
X-Spam-Level:
X-Spam-Status: No, score=-2.947 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, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, NICE_REPLY_A=-0.948, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ndt-inc.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 Ra30QjGIxQg4 for <netconf@ietfa.amsl.com>; Thu, 10 Sep 2020 07:45:57 -0700 (PDT)
Received: from delivery.mailspamprotection.com (delivery.mailspamprotection.com [146.66.121.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8696C3A0C76 for <netconf@ietf.org>; Thu, 10 Sep 2020 07:45:57 -0700 (PDT)
Received: from 108.134.209.35.bc.googleusercontent.com ([35.209.134.108] helo=usm9.siteground.biz) by se16.mailspamprotection.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.92) (envelope-from <bl@ndt-inc.com>) id 1kGNpb-0006FC-I4 for netconf@ietf.org; Thu, 10 Sep 2020 09:45:54 -0500
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ndt-inc.com ; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=JdcvpEaVk4yQx9NYHh+l/MIK/X+nbZ0jkfvM6SPRUrA=; b=YIXNKzxnU/DK4vfT50Az7csQMJ J613ya3vjIH+S/HmrA6dJCUIKmW1vN1hUub9pr3IScX5/WKgmRfrF5eEo/6EAk5IaeEFUvgaFljQt 5ACh0ZxwPvpUKCHrPWRMLegZ3K3pqzwnUFllaD4gci53oYC32+OBQbuCEnIf+USPGGtyWSKz+4QMM /V60+NGh6prvpKq8qh57dmK3eLJ5yVGo4zcypVuPfgrQk3TR+iz+Apa/XVbAiPaKsSiHB70uM5rbY JrfgwdMkRU+TLcSIjFi/xO1Cs5pXFhPJpZWdcfohnBoO7yAMrZQtirq06NPrHMbNYe4ZYGP97nai/ 1lD/25Ag==;
Received: from [104.158.52.238] (port=61121 helo=[192.168.0.11]) by usm9.siteground.biz with esmtpsa tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.90devstart-1178-b07e68e5-XX) (envelope-from <bl@ndt-inc.com>) id 1kGNpX-000CcQ-PX for netconf@ietf.org; Thu, 10 Sep 2020 09:45:43 -0500
To: netconf@ietf.org
References: <FC898DB0-8306-4E23-BD34-88657D36C98B@cisco.com>
From: BL <bl@ndt-inc.com>
Message-ID: <bd3f3dc8-9741-adf9-01e2-d5447829839e@ndt-inc.com>
Date: Thu, 10 Sep 2020 10:45:46 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.9.0
MIME-Version: 1.0
In-Reply-To: <FC898DB0-8306-4E23-BD34-88657D36C98B@cisco.com>
Content-Type: text/html; charset=utf-8
Content-Language: en-CA
Content-Transfer-Encoding: 8bit
X-Originating-IP: 35.209.134.108
X-SpamExperts-Domain: usm9.siteground.biz
X-SpamExperts-Username: 35.209.134.108
Authentication-Results: mailspamprotection.com; auth=pass smtp.auth=35.209.134.108@usm9.siteground.biz
X-SpamExperts-Outgoing-Class: ham
X-SpamExperts-Outgoing-Evidence: Combined (0.19)
X-Recommended-Action: accept
X-Filter-ID: Mvzo4OR0dZXEDF/gcnlw0Ux9i8jFyHj5FzBttN4d2CmpSDasLI4SayDByyq9LIhVpIDKbSMKqCOo AOFMhMffZETNWdUk1Ol2OGx3IfrIJKywOmJyM1qr8uRnWBrbSAGDfAKZvAjuJrqAt2e//bIc/80D SEpCfISRYCKsig5kq2Jj2r6LwVzaeqJ+KmixyRrFZIOQYaDXB30lsHjt7j8HkIUhra8TUx3meeRt +wubTTN8IyMUYcjQIyM7A0a7Hw2/0LXYdRxy64PJ5ar6NXZxz1tOlr0+z/ilDEUwvRrWtaIJYSxy lOCUOhVdCS2dVe3E0p8T4Nd45j4kJRgJ8MJ6+H7AOBBVCDBuvQ2Tzrrvjr54DqxxlnCnOQKjhagE KuLSpFcLxHSMmVCkv47x59CmBIeCSxLZ5vMkhIi5r4+dNkkg921mdjeq9x3a70LThETW8FXNoZZP bj1AsAZNMWt0tZKDcNF1LrVoVLXP90si9Lylvnhbbs49QZ7Zf6tX0XMpdgXkdE4z4t2s9ub/ESVc nxUdFqkFA+YKkUlydLh5cSaHt73jJKU44zPi+Pzpc9G5DMXe7HNAN2+ce9dIwwYzhLSJjzN5e8VF lEjmqR4rzvUXKu1VbgppFJRGoXLED7mHbbgVl4iunqFoEGZzSy+km6VHO6XhXqN3g0DWG4Tioc84 Kpmg5+UpQ2PZprb+nvdWlgS6K9aAlnrXFI3hveFdl1IGypOmEegLwNvezJQnFJr0oL7gETS6dqfh jPl2KHb5vaeQZj2358XprAr7YTpSL1bGTHlR8YuZW/e2yUWvymUkMhj/QRW3+vPbIg67bbBfKC0g nYJkzp6VW+G2xA6YsX3F5Dq2ZyzveRjbFJnnfL66SqVkUMaZbxD5TnK9qN/v2zfpgu2LUdQgOCrc nAageVSgUi8Pewhw/V+Ek8zoH/xuIm8DYKCS8O75N9m22hw18PSCH03pPQqDktravYP+Va7emG6F Iv4osAGsCIqXSq0EpaVTOkDn4bjvSYvcVP/7NwpU15Un0FfK735x4KpOFKSEcE4wvr/xQ1llkMCC BlCXgDw+7QIw0sn8dfnInn3gM4OE8FBo9/u15HPAYu2P3WeupYYdzPm7YfRDaULOU2m1qXL+49o8 azgi4BgggOee9QgtUTdSx3/dYxat0mBq1ebZp1GDaNdqXDvHsn6feTg=
X-Report-Abuse-To: spam@quarantine1.mailspamprotection.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/NfUidtJBxm-Fo9fEZ545GaCLIT8>
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 14:45:59 -0000

RFC 6241: 4.3. <rpc-error> Element

error-info: ...
An implementation MAY include
additional elements to provide extended and/or implementation specific
debugging information.

Regards
    Borislav Lukovic

On 9/10/2020 4:27 AM, Jan Lindblad (jlindbla) 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? 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



_______________________________________________
netconf mailing list
netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf" rel="nofollow">https://www.ietf.org/mailman/listinfo/netconf