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

Andy Bierman <andy@yumaworks.com> Fri, 25 January 2019 00:03 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 83185130F40 for <netconf@ietfa.amsl.com>; Thu, 24 Jan 2019 16:03:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.041
X-Spam-Level:
X-Spam-Status: No, score=-2.041 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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=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 Dza0AMmaeHVZ for <netconf@ietfa.amsl.com>; Thu, 24 Jan 2019 16:02:57 -0800 (PST)
Received: from mail-lf1-x12a.google.com (mail-lf1-x12a.google.com [IPv6:2a00:1450:4864:20::12a]) (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 261A11311FC for <netconf@ietf.org>; Thu, 24 Jan 2019 16:02:57 -0800 (PST)
Received: by mail-lf1-x12a.google.com with SMTP id p6so5689468lfc.1 for <netconf@ietf.org>; Thu, 24 Jan 2019 16:02:56 -0800 (PST)
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=iWm8F6t92SrY++Z1biQlLdPj49StXJUAK//6xigRpKo=; b=mtHPyozta4W0XuoZLyDwfCM229MuKEEdsPFYbghaI62ZlrnTZOhvqDdaxa/xD1recD A/+RhH/Ja0/nkEY0x5dkbTOIMAXX0qbFVwiMei+laj3nUDlYZevMl14hXF3N1E9Vioku Tughc3fkz5mmDAWpGh0ZwKUFOF5Ozl+VIAkQuqHVJknIPRyqTTBPqMMJVVLb8odnxQyt ed+MorfuntvH6G9Q4Cn6Tk6DY7EnSOi1VjinI8WCPsbIvsupwy/UL+D1nSiLAcmh8RMy ZUD9XV+GeHQoqbMcdxRFjY4/OpZTu6O4xk16F2OHHpJSe9NyCQHqh+qK+0uiUpnSjKBp lzqQ==
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=iWm8F6t92SrY++Z1biQlLdPj49StXJUAK//6xigRpKo=; b=VNsZKfLcBHMNQDKeKgspG2Oam61cM61R3vI3zxBj5O7qPXx7C39OBCtQTJv3xro8oa QD5lGcqsUE8WXJ+SIQPqSkdQwZQmaaEwQOMjBLJ+oPTrt/esbKWXNk1KknLLrBseTRZy UjJ+54+6y+kFB7Cuwi9XvwvTLAe7V9LAHf6SPIWk9Q0vn0OfQBCNwKpGMou/luoR3+OZ 8ijEAXO4F4j+SCbkdjcySyJgrjqmF+2pZ5JJd01lGpxYml3XRgCpJbOQgCYAROdogcAs HczH5fMuiNFZKWmq5Es6KPAGlaQXvdMRjGZlTu+xaJEb7hEYV8IN5Bg56sH1KGBTb4IO Y45g==
X-Gm-Message-State: AJcUukeQzwr+QROL6hBFi7CqbQiSvLqTIUDj3rA9qg2J84moR/LdHPcm trlrxh4A3t3sF5RNbgDgvdFe6mvnjAmk3nrXdGTXvQ==
X-Google-Smtp-Source: ALg8bN7Ad0SvJsAq+QDHLQBoiZnBsf/EF2UFSxIdlrYrl2z3T6CFUYP2A0dxmdVC7VO5F/Bcf4vW/orUBAysyoU9Y5A=
X-Received: by 2002:a19:1cd3:: with SMTP id c202mr6935171lfc.33.1548374575095; Thu, 24 Jan 2019 16:02:55 -0800 (PST)
MIME-Version: 1.0
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> <1b77e7ca80c141979395f739c4ab9a61@XCH-RTP-013.cisco.com>
In-Reply-To: <1b77e7ca80c141979395f739c4ab9a61@XCH-RTP-013.cisco.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Thu, 24 Jan 2019 16:02:43 -0800
Message-ID: <CABCOCHTyPH-GhZmBJh4Ni1=4SieeoQnCDxezTb5ezONWjYkMLQ@mail.gmail.com>
To: "Eric Voit (evoit)" <evoit@cisco.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>
Content-Type: multipart/alternative; boundary="00000000000087388f05803d0cb6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/WTnXoRxby1sMB-ALH1ZckEcvdUg>
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: Fri, 25 Jan 2019 00:03:00 -0000

On Thu, Jan 24, 2019 at 3:56 PM Eric Voit (evoit) <evoit@cisco.com>; wrote:

> On Thu, Jan 24, 2019 at 9:04 AM Eric Voit (evoit) <evoit@cisco.com>; wrote:
>
> > "Eric Voit (evoit)" <evoit@cisco.com>; wrote:
> > > > From: Martin Bjorklund, January 24, 2019 9:40 AM
> > > >
> > > > "Eric Voit (evoit)" <evoit@cisco.com>; wrote:
> > > > > > From: Martin Bjorklund, January 24, 2019 8:17 AM
> > > > > >
> > > > > > "Eric Voit (evoit)" <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.
>
>
>


I agree.

Using the correct error-tag values plus identity names for error-app-tag
values allows
both generic clients and clients specialized for this application to both
work.



> Eric
>
>
>
>
>
> Andy
>
>
>
>
>
>

Andy


>
>
>
>
>