Re: [netconf] [yang-doctors] Yangdoctors last call review of draft-ietf-netconf-subscribed-notifications-21

"Eric Voit (evoit)" <evoit@cisco.com> Thu, 24 January 2019 23:56 UTC

Return-Path: <evoit@cisco.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 0E1381311F3; Thu, 24 Jan 2019 15:56:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -19.052
X-Spam-Level:
X-Spam-Status: No, score=-19.052 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-4.553, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.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 YFb3Z3sLrAQN; Thu, 24 Jan 2019 15:56:01 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8331130F40; Thu, 24 Jan 2019 15:56:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21884; q=dns/txt; s=iport; t=1548374160; x=1549583760; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=o2lEtx1QrSENPx619XSdpur315QW95+OTMDR4/RNrWI=; b=SFfODsu0Tp3PRrxmao4Ct+SxdqofphZrgGVBAtsH9zY40mVkBfiWqSdP KSnlTZqvZiPovslWctK27yRTk1l8GRhJluoIs0z9U5kDzI26gclJg9FUJ /dCgD+DnRHDxp4lu3Vjbn9+iODT5R4NV3l1XCoJofw8UyLEvfaQw8MTlh Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAACKT0pc/5RdJa1bCRkBAQEBAQE?= =?us-ascii?q?BAQEBAQEHAQEBAQEBgVEEAQEBAQELAYENTSlngQMnCoN3iBqLc4INkh2FaoF?= =?us-ascii?q?7CwEBhGwCF4JsIjQJDQEDAQECAQECbSiFSgEBAQEDIwpKAhACAQgVAw0aAwI?= =?us-ascii?q?CAjAUEQIEDgUIgk9MgR1krEWBL4oyjEEXgUA/hCOEVzgqglGCNSICiVUVgXu?= =?us-ascii?q?EEYFxkEYJAohQiUwgkh+bEAIRFIEnHziBVnAVgyeCUY4LQTGKD4EfAQE?=
X-IronPort-AV: E=Sophos;i="5.56,518,1539648000"; d="scan'208,217";a="509296787"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jan 2019 23:55:59 +0000
Received: from XCH-RTP-004.cisco.com (xch-rtp-004.cisco.com [64.101.220.144]) by rcdn-core-12.cisco.com (8.15.2/8.15.2) with ESMTPS id x0ONtxEI000397 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 24 Jan 2019 23:55:59 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-004.cisco.com (64.101.220.144) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 24 Jan 2019 18:55:58 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1395.000; Thu, 24 Jan 2019 18:55:58 -0500
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Andy Bierman <andy@yumaworks.com>
CC: Martin Bjorklund <mbj@tail-f.com>, "Reshad Rahman (rrahman)" <rrahman@cisco.com>, "alexander.clemm@huawei.com" <alexander.clemm@huawei.com>, "yang-doctors@ietf.org" <yang-doctors@ietf.org>, "netconf@ietf.org" <netconf@ietf.org>, "draft-ietf-netconf-subscribed-notifications.all@ietf.org" <draft-ietf-netconf-subscribed-notifications.all@ietf.org>
Thread-Topic: [yang-doctors] Yangdoctors last call review of draft-ietf-netconf-subscribed-notifications-21
Thread-Index: AQHUrG6+nBjZ9hMl8U25QTRsXd0ZC6Ww36AggANDEICAARW3EIAAAXJggAU/bACAAWWKIIABCD+A///v5GCAAKn4AP//skVAgAGV2gD//60SYAANQ54AAApn7nD//7rBgIAATO5Q///UiQD//+og8A==
Date: Thu, 24 Jan 2019 23:55:58 +0000
Message-ID: <1b77e7ca80c141979395f739c4ab9a61@XCH-RTP-013.cisco.com>
References: <b72f5c48e01c4742b78e31e803c0e2a7@XCH-RTP-013.cisco.com> <20190124.153938.826269505351606159.mbj@tail-f.com> <26102d90539d4794b9186dcfa9654bd1@XCH-RTP-013.cisco.com> <20190124.162945.523862790570074888.mbj@tail-f.com> <9f0f48b7e17c40fab9a64b4a2488997e@XCH-RTP-013.cisco.com> <CABCOCHQTxdi8=x-k+FaWrVUwsg0J945i_c1_jmLJRC=FonZoAg@mail.gmail.com>
In-Reply-To: <CABCOCHQTxdi8=x-k+FaWrVUwsg0J945i_c1_jmLJRC=FonZoAg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.118.56.229]
Content-Type: multipart/alternative; boundary="_000_1b77e7ca80c141979395f739c4ab9a61XCHRTP013ciscocom_"
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.144, xch-rtp-004.cisco.com
X-Outbound-Node: rcdn-core-12.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/n4zZLoAElgSZ5ADEq30x93QYREY>
Subject: Re: [netconf] [yang-doctors] Yangdoctors last call review of draft-ietf-netconf-subscribed-notifications-21
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, 24 Jan 2019 23:56:04 -0000

On Thu, Jan 24, 2019 at 9:04 AM Eric Voit (evoit) <evoit@cisco.com<mailto:evoit@cisco.com>> wrote:
> "Eric Voit (evoit)" <evoit@cisco.com<mailto:evoit@cisco.com>> wrote:
> > > From: Martin Bjorklund, January 24, 2019 9:40 AM
> > >
> > > "Eric Voit (evoit)" <evoit@cisco.com<mailto:evoit@cisco.com>> wrote:
> > > > > From: Martin Bjorklund, January 24, 2019 8:17 AM
> > > > >
> > > > > "Eric Voit (evoit)" <evoit@cisco.com<mailto:evoit@cisco.com>> wrote:
> > > > > > Hi Andy,
> > > > > >
> > > > > >
> > > > > >
> > > > > > Thanks very much for the thorough YANG Doctor review.  I have
> > > > > > included the
> > > > > agreed upon comments, and uploaded to:
> > > > > >
> > > > > > draft-ietf-netconf-subscribed-notifications-22
> > > > > >
> > > > > > a summary of the clarifications made is at the end of the document.
> > > > > > Let me know if there anything else needed to conclude the YANG
> > > > > > doctor review of this document.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Also as the result of the ‘error-tag’ discussion with you and
> > > > > > Martin, we need to perform the refinement of the ‘error-tag’
> > > > > > mapping within both
> > > > > > draft-ietf-netconf-netconf-event-notifications
> > > Section
> > > > > > 7, and draft-ietf-netconf-restconf-notif Section 3.3.   Directly
> > > > > > below is some text and proposed error-tag mappings for those
> > > > > > documents.
> > > > > >
> > > > > >
> > > > > >
> > > > > >     o  An "error-tag" node with the value being a string that
> > > > > >
> > > > > >        corresponds to an identity associated with the error.
> > > > > > This
> > > > > >
> > > > > >        "error-tag" will correspond to the error identities
> > > > > > within
> > > > > >
> > > > > >        [I-D.draft-ietf-netconf-subscribed-notifications]
> > > > > > section
> > > > > >
> > > > > >        2.4.6 for general subscription errors:
> > > > > >
> > > > > >
> > > > > >
> > > > > >           error identity         uses error-tag
> > > > > >
> > > > > >           ---------------------- --------------
> > > > > >
> > > > > >           dscp-unavailable       invalid-value
> > > > >
> > > > > Ok.  But it is not clear to me when this error is actually
> > > > > supposed to be generated?  The leaf and identity have the same
> > > > > if-feature, so it isn't a special errro code for "unsupported leaf", which is
> good!
> > > > >
> > > > > Then I have to assume it is supposed to be some kind of runtime error?
> > > >
> > > > Yes.  A publisher, nor the network to which is connects does not
> > > > have
> > > > to:
> > > > (a) support all DSCP values, nor
> > > > (b) allow a particular value requested by a particular subscriber,
> > > > So this condition allows a publisher to reject a request for a
> > > > DSCP value where is knows the value will not be respected.
> > >
> > > Good explanation, I wish it was part of the "leaf dscp" in the
> > > module
> > > :)
> > >
> > > The dscp-unavailable identity doesn't add any addition value
> > > compared to the standard error.
> >
> > For NETCONF and RESTCONF, this is the case.
>
> And comi.  The point is, what makes the rpcs in this module so special
> that they have to invent a new error reporting scheme?   If we do that
> for these rpcs, why not for all other rpc in all other modules?

The current RPC error mechanisms ties YANG RPCs to NETCONF and RESTCONF transports.   Over many years there has been lots of work to align the subscription drafts to these existing mechanisms, while maintaining as much transport independence for hints as possible.


The subscription draft changes error reporting in significant ways, for the worse, not the better.
There are a set of error-tag values that are used for all protocol operations defined with rpc-stmt.
It was first defined in NETCONF but it has been applied to RESTCONF as well.

This draft uses identities to replace the set of common error-tags.  Instead, every single
rpc-stmt can have its own set of error codes. Even worse, a different set of error codes
depending on the protocol that was used.

Why should a 'resource-denied' error be something different in RESTCONF vs. NETCONF?
Or even in CoMI or some unknown protocol?  Why would 'invalid-value' be different,
depending on the operation?

It is 1 thing to change the documentation of YANG-based protocol operations.
It is another to omit mandatory information needed to work with NETCONF and RESTCONF.
If the error-tag values are properly documented and the NETCONF and RESTCONF mappings are identical
then there should not be any problems using standard error reporting.

<Eric> I believe that with this thread, that the error-tag values will be well documented and identical between NETCONF and RESTCONF transport drafts.

Eric


Andy