Re: [netmod] YANG actions - need to define OK/error or can reuse NETCONF ok/rpc-error ?

"Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com> Thu, 07 June 2018 21:24 UTC

Return-Path: <jason.sterne@nokia.com>
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6438F130FA2 for <netmod@ietfa.amsl.com>; Thu, 7 Jun 2018 14:24:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.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 s3InaQf-XaAw for <netmod@ietfa.amsl.com>; Thu, 7 Jun 2018 14:24:16 -0700 (PDT)
Received: from EUR04-DB3-obe.outbound.protection.outlook.com (mail-eopbgr60094.outbound.protection.outlook.com [40.107.6.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6A4B8130EC7 for <netmod@ietf.org>; Thu, 7 Jun 2018 14:24:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=GLGnhxe67XMSeCBBjnL225u3FtdiqF3QZ+swUH7cg48=; b=U++L5EZhOqHSq3lYqf+eJvuRNWrLnB6TpJNLx9rphk0wti4Qk2mkyiCjtOTxeFYc7968w5tt7t3l0jNM9MHj4WRarftS/TKYWVSEToPcos6X/8Zocj5C1y0F3hrY6U55CigFvs/yAArpV/NiKVhDEtPatWWiT9+Q67qk9AkcKgA=
Received: from AM0PR07MB3844.eurprd07.prod.outlook.com (52.134.82.20) by AM0PR07MB4100.eurprd07.prod.outlook.com (52.134.83.140) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.841.10; Thu, 7 Jun 2018 21:24:14 +0000
Received: from AM0PR07MB3844.eurprd07.prod.outlook.com ([fe80::94aa:e7c1:4d51:f39c]) by AM0PR07MB3844.eurprd07.prod.outlook.com ([fe80::94aa:e7c1:4d51:f39c%2]) with mapi id 15.20.0841.011; Thu, 7 Jun 2018 21:24:14 +0000
From: "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com>
To: Martin Bjorklund <mbj@tail-f.com>
CC: "netmod@ietf.org" <netmod@ietf.org>
Thread-Topic: [netmod] YANG actions - need to define OK/error or can reuse NETCONF ok/rpc-error ?
Thread-Index: AdP+jqpxctFzmzk7TxOmtbfCp6waIAAFsNqAAAAKtBA=
Date: Thu, 07 Jun 2018 21:24:14 +0000
Message-ID: <AM0PR07MB3844E1E2FA97C9FB696BA3789B640@AM0PR07MB3844.eurprd07.prod.outlook.com>
References: <AM0PR07MB3844C6E5A6F4085B530B63429B640@AM0PR07MB3844.eurprd07.prod.outlook.com> <20180607.232059.254974416192719323.mbj@tail-f.com>
In-Reply-To: <20180607.232059.254974416192719323.mbj@tail-f.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=jason.sterne@nokia.com;
x-originating-ip: [135.245.20.30]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; AM0PR07MB4100; 7:J5u7gBiwDfZOaKggjsgvFHmTK8SjNruvUdCX2mTlXpc7gU1wopHWY0vzG9373OdFzvAeM12xBDYjGhFfoIDNUSz9of7Y4wIIIy2+PyXyeFfJY4z+Lxaglno6YXEezssAxljcmysB6Gy/JH1L15mF7hguLYXIpRjo6qDLl1HzL3TxkaB6xU08lAPmsSsuWzoVikn6388iO/koLHZrq/OHNbExxv95Se6u74AHMKUYAVG4SWz1onWXdorqJuIoxbir
x-ms-exchange-antispam-srfa-diagnostics: SOS;
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:(109105607167333); BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989080)(48565401081)(5600026)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603328)(7193020); SRVR:AM0PR07MB4100;
x-ms-traffictypediagnostic: AM0PR07MB4100:
x-microsoft-antispam-prvs: <AM0PR07MB4100346D43C1112DAB660ECC9B640@AM0PR07MB4100.eurprd07.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(131327999870524)(82608151540597)(109105607167333);
x-ms-exchange-senderadcheck: 1
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040522)(2401047)(5005006)(8121501046)(3002001)(3231254)(11241501184)(806099)(944501410)(52105095)(93006095)(93001095)(10201501046)(6055026)(149027)(150027)(6041310)(20161123564045)(20161123558120)(20161123560045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011)(7699016); SRVR:AM0PR07MB4100; BCL:0; PCL:0; RULEID:; SRVR:AM0PR07MB4100;
x-forefront-prvs: 06968FD8C4
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(396003)(376002)(39380400002)(39860400002)(13464003)(53754006)(189003)(57704003)(199004)(3280700002)(2900100001)(446003)(53546011)(26005)(102836004)(106356001)(66066001)(186003)(14454004)(59450400001)(55016002)(6506007)(7736002)(105586002)(99286004)(68736007)(486006)(97736004)(81156014)(2906002)(6436002)(53936002)(305945005)(229853002)(5250100002)(7696005)(76176011)(5660300001)(3660700001)(316002)(4326008)(476003)(11346002)(6116002)(6916009)(81166006)(74316002)(9686003)(33656002)(25786009)(8676002)(86362001)(478600001)(3846002)(8936002)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB4100; H:AM0PR07MB3844.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts)
x-microsoft-antispam-message-info: vx56MjcxeWoFUmrvT9QM5kvIFSZvmCd43L1493kCNjXhFxCRimtOFrIi/E//N2apZLE+S26QdctN8O5pbB0OsheC5Sr15fDVb81CyxnQGinGB7g1RkhDV9iJfJOTeIugGlg33bfPcDDR7CmI+dttmIxbtzcFyoyKm7OPjY5cawteXWeJGrmRXjDg+F9TPcvDOwayE+ax8j8crydjtAmagE6IaGtiw2u50lasofWHlHOAacNcbJW/hFwE6wFbjoIP
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-MS-Office365-Filtering-Correlation-Id: 2565d3ec-7575-4f64-76f7-08d5ccbd04b8
X-OriginatorOrg: nokia.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 2565d3ec-7575-4f64-76f7-08d5ccbd04b8
X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Jun 2018 21:24:14.1425 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB4100
Archived-At: <https://mailarchive.ietf.org/arch/msg/netmod/aZmeX5jgYKIGoFFwJsNmyowDQ9Q>
Subject: Re: [netmod] YANG actions - need to define OK/error or can reuse NETCONF ok/rpc-error ?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: NETMOD WG list <netmod.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netmod>, <mailto:netmod-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/netmod/>
List-Post: <mailto:netmod@ietf.org>
List-Help: <mailto:netmod-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netmod>, <mailto:netmod-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 07 Jun 2018 21:24:20 -0000

Thanks Martin.  I should have found that myself when I was looking through that section.

What about the case where the operation invocation did not succeed and there are no output parameters defined ?   

Rgds,
Jason

> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]
> Sent: Thursday, June 7, 2018 5:21 PM
> To: Sterne, Jason (Nokia - CA/Ottawa) <jason.sterne@nokia.com>
> Cc: netmod@ietf.org
> Subject: Re: [netmod] YANG actions - need to define OK/error or can reuse
> NETCONF ok/rpc-error ?
> 
> Hi,
> 
> "Sterne, Jason (Nokia - CA/Ottawa)" <jason.sterne@nokia.com> wrote:
> > Hi all,
> >
> > When defining an 'action' in a YANG 1.1 model, and we want the server
> > to be able to respond with <ok> or some error information, do we need
> > to define the ok/error info in the 'output' of the action, or can we
> > define an action without any 'output' statement and have the server
> > respond using the typical <ok> or <rpc-error> in NETCONF ?
> 
> You don't need to define "ok" - see section 7.15.2, the last paragraph
> of RFC 7950:
> 
>    If the action operation invocation succeeded and no output parameters
>    are returned, the <rpc-reply> contains a single <ok/> element defined
>    in [RFC6241].  If output parameters are returned, they are encoded as
>    child elements to the <rpc-reply> element defined in [RFC6241], in
>    the same order as they are defined within the "output" statement.
> 
> 
> 
> /martin
> 
> > I'm not sure if it is relevant, but when I look at the definition of
> > the commit rpc in the NETCONF spec, there is no 'output' defined but
> > clearly a response of <ok> or an rpc-error can be returned by a
> > server.
> >
> > If we don't define the ok/error in the action itself then I suppose
> > other types of interfaces (RESTCONF) may or may not have other ways to
> > reply ok/error (at least it won't be defined by the YANG model for the
> > particular action).
> >
> > But it does seem like a waste to go and specify ok/error information
> > for every action out there if they only need to return ok or error
> > information that could be carried in the standard rpc-error message.
> >
> > Rgds,
> > Jason