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 17:05 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 0CD2E131240; Thu, 24 Jan 2019 09:05:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.642
X-Spam-Level:
X-Spam-Status: No, score=-14.642 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.142, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 naf27X2ZERuW; Thu, 24 Jan 2019 09:04:57 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 37DF31311DF; Thu, 24 Jan 2019 09:04:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=75916; q=dns/txt; s=iport; t=1548349497; x=1549559097; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=qwtjYH8ZwLZaxxjU4AS5OVlXiD2hD9GTdPbdwbj+aK0=; b=fqWxYDJKJJLu8hlha97nuwvFtXFdjEBdp8CPbXARHFWIBX/Ry56wGsi8 twE9l7kS9tQfC6iwpcJ5ZDnkkvFj3S9vKlKo5sFpFEhZMFgc7akdIn5a6 sC3+S4HTZL/u6FLniZWWZxjL5gqylGdORLFe35niVTyblcoVAYWFeqmUi 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ADAABT70lc/5xdJa1aAQIHGQEBAQE?= =?us-ascii?q?BAQEBAQEBAQcBAQEBAQGBUQQBAQEBAQsBgVopZ4EDJwqDd4gai3KCDXyCSpR?= =?us-ascii?q?BFIFnCwEBI4RJAheCbCI0CQ0BAwEBAgEBAm0cDIVKAQEBAQIBGgEIEUMCBQs?= =?us-ascii?q?CAQgOAwQBAQECAgkaAwICAjAUAQgIAgQOBQiCT0yBeQgPrCiBL4opBYELizY?= =?us-ascii?q?XgUA/gRGCFEk1gx4CgTYBAw8CAyqCcoI1IgKJVQMICiYLgUqEKQGBWIRvint?= =?us-ascii?q?cCQKHKINbhxkggWmIaoEyhhqKCYEMhBqJD4JSAhEUgScfOIFWcBU7gmyCJxc?= =?us-ascii?q?TbQEIgkKKU0ExiGIpgQWBHwEB?=
X-IronPort-AV: E=Sophos;i="5.56,517,1539648000"; d="scan'208";a="230643397"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jan 2019 17:04:55 +0000
Received: from XCH-RTP-002.cisco.com (xch-rtp-002.cisco.com [64.101.220.142]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x0OH4s2f025507 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 24 Jan 2019 17:04:55 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-002.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 24 Jan 2019 12:04:53 -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 12:04:54 -0500
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Martin Bjorklund <mbj@tail-f.com>
CC: "andy@yumaworks.com" <andy@yumaworks.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
Date: Thu, 24 Jan 2019 17:04:53 +0000
Message-ID: <9f0f48b7e17c40fab9a64b4a2488997e@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>
In-Reply-To: <20190124.162945.523862790570074888.mbj@tail-f.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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Outbound-SMTP-Client: 64.101.220.142, xch-rtp-002.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/GWj29ioCEUe_7DkooVOXD1vFMN8>
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 17:05:02 -0000

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

> > > > > Thinking some more, what is supposed to happen if the client on
> > > > > the same session sends first an establish-subscription with dscp
> > > > > 42, and then another establish-subscription with dscp 10?
> > > >
> > > > This would be allowed.
> > >
> > > On linux at least this is a sockopt, i.e., the option applies to the
> > > socket, which means all packets on the session.  So how is this
> > > supposed to be implemented if different messages on the session
> > > should have different dscp values?
> > > Or is the
> > > idea that you send the msg, flush all data from ssh/tls to tcp, then
> > > flush the tcp buffers (not that easy...)?
> > >
> > > Even if there's just one establish-subscription with a dscp value,
> > > since it applies to the session it means that all normal rpcs on
> > > this session will get the same dscp value.  It is not clear that
> > > this is the intention?
> >
> > For a NETCONF session, I agree that an implementation need not try to
> > attempt to support more than one DSCP for that session.  And the error
> > identity dscp-unavailable is a valid response here.
> 
> Then that should be explained (preferrably in the leaf dscp).
> 
> > For RESTCONF and other transports, there options which can more
> > flexibly support different DSCP values.  This is one reason I was
> > pushing hard in 2016 to leverage HTTP2.
> 
> We're talking about dynamic subscriptions here.  I don't think anyone has
> suggested HTTP2 for dynamic subscriptions.

I have always believed that HTTP2 for dynamic subscriptions was a useful industry target.   This driver was the original reason I wrote the original draft which became draft-ietf-netconf-restconf-notif, and many variations on dynamic subscriptions with HTTP2.    In the meantime, GRPC subscriptions (based on HTTP2) has grown into this space.

Eric

> For configured subscriptions, this is not an issue, not even for NETCONF.
> 
> 
> /martin
> 
> 
> 
> >
> > Eric
> >
> > > /martin
> > >
> > >
> > > > The interesting part comes with bundling the event records.  The
> > > > initial versions of draft-ietf-netconf-notification-messages
> > > > required that all event records in a bundle had a common dscp.  At
> > > > this point, that seems overly restrictive to the marshalling
> > > > process, so for now that requirement is not in the document.
> > > >
> > > > > >           encoding-unsupported   invalid-value
> > > > >
> > > > > Ok.  But this identity doesn't give more information than the
> > > > > standard
> > > > > error:
> > > > >
> > > > >   error-tag: invalid-value
> > > > >   error-path: /rpc/establish-subscription/encoding
> > > > >
> > > > >
> > > > > >           filter-unavailable     invalid-value
> > > > >
> > > > > This is a "subscription-terminated-reason", which will never be
> > > > > sent in an rpc- error, and thus should not be mapped to an error-tag.
> > > >
> > > > Yes, forgot to remove those.  It is now out.
> > > >
> > > > > >          filter-unsupported     invalid-value
> > > > >
> > > > > Ok.  But this identity doesn't give more information than the
> > > > > standard
> > > > > error:
> > > > >
> > > > >   error-tag: invalid-value
> > > > >   error-path: /rpc/establish-subscription/stream-xpath-filter
> > > > >
> > > > >
> > > > > >           insufficient-resources resource-denied
> > > > >
> > > > >
> > > > > Ok.  But this identity doens't give more information than the
> > > > > standard error in the case of establish-subscription and
> > > > > modify-subscription.
> > > > >
> > > > > >           no-such-subscription   invalid-value
> > > > >
> > > > > Ok.  But this identity doens't give more information than the
> > > > > standard error in the case of establish-subscription and
> > > > > modify-subscription.
> > > > >
> > > > > >           replay-unsupported     operation-not-supported
> > > > >
> > > > > Ok.  But this identity doesn't give more information than the
> > > > > standard error.
> > > > >
> > > > > >           stream-unavailable     invalid-value
> > > > >
> > > > > This is a "subscription-terminated-reason", which will never be
> > > > > sent in an rpc- error, and thus should not be mapped to an error-tag.
> > > >
> > > > Yes, forgot to remove those.  It is now out.
> > > >
> > > > > >           suspension-timeout     operation-failed
> > > > >
> > > > > This is a "subscription-terminated-reason", which will never be
> > > > > sent in an rpc- error, and thus should not be mapped to an error-tag.
> > > >
> > > > Yes, forgot to remove those.  It is now out.
> > > >
> > > > > >           unsupportable-volume   too-big
> > > > >
> > > > > This is a "subscription-terminated-reason", which will never be
> > > > > sent in an rpc- error, and thus should not be mapped to an error-tag.
> > > >
> > > > Yes, forgot to remove those.  It is now out.
> > > >
> > > > > >        Or this "error-tag" will correspond to the error
> > > > > > identities
> > > > > >
> > > > > >        within [I-D.ietf-netconf-yang-push] Appendix A.1 for
> > > > > >
> > > > > >        subscription errors specific to YANG datastores:
> > > > > >
> > > > > >
> > > > > >
> > > > > >           error identity              uses error-tag
> > > > > >
> > > > > >           ----------------------      --------------
> > > > > >
> > > > > >           cant-exclude                operation-not-supported
> > > > > >
> > > > > >           datastore-not-subscribable  operation-not-supported
> > > > >
> > > > > I think that this should be invalid-value.
> > > >
> > > > Ok
> > > >
> > > > /Eric
> > > >
> > > > > >           no-such-subscription-resync invalid-value
> > > > >
> > > > > Ok, but again the value of having this is unclear.
> > > > >
> > > > > >           on-change-unsupported       operation-not-supported
> > > > > >
> > > > > >           on-change-sync-unsupported  operation-not-supported
> > > > > >
> > > > > >           period-unsupported          invalid-value
> > > > > >
> > > > > >           update-too-big              too-big
> > > > > >
> > > > > >           sync-too-big                too-big
> > > > > >
> > > > > >           unchanging-selection        operation-failed
> > > > >
> > > > >
> > > > >
> > > > > /martin
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Do you (or anyone else in this thread) have any suggestions on
> > > > > > the text or proposed mappings?  If this turns out to be ok,
> > > > > > Alex will need to remove the NETCONF error-tag specifics from
> > > > > > draft-ietf-netconf-yang-push Sections 4.4.1 & 4.4.2
> > > > > >
> > > > > >
> > > > > >
> > > > > > Also Reshad will have to do some work because he is the YANG
> > > > > > doctor of
> > > > > netconf-netconf-event-notifications, and he will want to include
> > > > > the same information within draft-ietf-netconf-restconf-notif.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Thanks,
> > > > > >
> > > > > > Eric
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > From: Andy Bierman <andy@yumaworks.com>;
> > > > > >
> > > > > > Sent: Wednesday, January 23, 2019 12:42 PM
> > > > > >
> > > > > > To: Eric Voit (evoit) <evoit@cisco.com>;
> > > > > >
> > > > > > Cc: Martin Bjorklund <mbj@tail-f.com>;; yang-doctors@ietf.org;
> > > > > > netconf@ietf.org;
> > > > > > draft-ietf-netconf-subscribed-notifications.all@ietf.org
> > > > > >
> > > > > > Subject: Re: [yang-doctors] Yangdoctors last call review of
> > > > > > draft-ietf-netconf-subscribed-notifications-21
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Wed, Jan 23, 2019 at 4:35 AM Eric Voit (evoit)
> > > > > > <mailto:evoit@cisco.com>
> > > > > wrote:
> > > > > >
> > > > > > > From: Martin Bjorklund, January 23, 2019 3:32 AM
> > > > > >
> > > > > > >
> > > > > >
> > > > > > > Hi,
> > > > > >
> > > > > > >
> > > > > >
> > > > > > > "Eric Voit (evoit)" <mailto:evoit@cisco.com> wrote:
> > > > > >
> > > > > > > > Hi Andy,
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > Looking at your proposal...  My reading is that it takes
> > > > > > > > the transport
> > > > > >
> > > > > > > > specific error info contained in
> > > > > >
> > > > > > > > draft-ietf-netconf-netconf-event-notifications section 7,
> > > > > > > > and then
> > > > > >
> > > > > > > > replicates that info within 12 separate description
> > > > > > > > objects of the
> > > > > >
> > > > > > > > transport independent ietf-subscribed-notifications.yang.
> > > > > > > > The value
> > > > > >
> > > > > > > > you are asserting is that RFCs containing YANG models
> > > > > > > > containing the
> > > > > >
> > > > > > > > rpc-stmt have traditionally document the
> > > > > > > > mandatory-to-implement
> > > > > >
> > > > > > > > "error-tag" field within the model.  And presumably you
> > > > > > > > are concerned
> > > > > >
> > > > > > > > that developers should not have to look elsewhere for this
> > > > > >
> > > > > > > > information.
> > > > > >
> > > > > > >
> > > > > >
> > > > > > > I think that maybe there are two separate issues here.
> > > > > >
> > > > > > >
> > > > > >
> > > > > > > The first issue is that for each error identity defined,
> > > > > > > there needs to be a
> > > > > >
> > > > > > > mapping to the protocol-specific error handling.  Andy
> > > > > > > suggests that this info is
> > > > > >
> > > > > > > added to this document, but currently this information is
> > > > > > > available in the
> > > > > >
> > > > > > > protcol-mapping documents (netconf-notif and restconf-notif).
> > > > > > > Personally, I
> > > > > >
> > > > > > > think that the current split of text between documents is fine.
> > > > > >
> > > > > > >
> > > > > >
> > > > > > > The second issue is that currently, both netconf-notif and
> > > > > > > restconf-notif say
> > > > > >
> > > > > > > that *all* these errors use the error-tag "operation-failed".
> > > > > > > Essentially it means
> > > > > >
> > > > > > > that we bypass the error handling in the protocols.  As Andy
> > > > > > > points out below,
> > > > > >
> > > > > > > the error "insufficient-resources" should be mapped to
> > > > > > > "resource-denied" in
> > > > > >
> > > > > > > NETCONF and RESTCONF (they mean the same thing).  So it
> > > > > > > might make sense
> > > > > >
> > > > > > > to carefully go through the list of errors and map them to
> > > > > > > the correct error-tag
> > > > > >
> > > > > > > (but specifiy this in the transport drafts).
> > > > > >
> > > > > >
> > > > > >
> > > > > > I am completely good with this.   Does this work for you Andy?
> > > > > >
> > > > > >
> > > > > >
> > > > > > This is better.
> > > > > >
> > > > > > I'm glad no other drafts are creating their own error
> > > > > > reporting system for
> > > > > each rpc-stmt.
> > > > > >
> > > > > > This is a bad precedent and likely to be skipped in implementations.
> > > > > >
> > > > > >
> > > > > >
> > > > > > Eric
> > > > > >
> > > > > >
> > > > > >
> > > > > > > /martin
> > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > Andy
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > >
> > > > > > >
> > > > > >
> > > > > > >
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > If the YANG doctors require this, it can be inserted.  A
> > > > > > > > similar text
> > > > > >
> > > > > > > > change would be needed for quite a few error identities
> > > > > > > > within YANG
> > > > > >
> > > > > > > > Push.  Personally I don’t like that YANG models should be
> > > > > > > > required to
> > > > > >
> > > > > > > > embed this information.  But I will make the change if you
> > > > > > > > really want
> > > > > >
> > > > > > > > this, and nobody else objects.
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > Other than that, I am not aware of any other open issues
> > > > > > > > in the YANG
> > > > > >
> > > > > > > > Doctor review.  Do you know of anything else?
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > Eric
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > From: Andy Bierman, January 21, 2019 2:26 PM
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > Hi,
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > I think the error-tag issue can be resolved by including 1
> > > > > > > > extra
> > > > > >
> > > > > > > > sentence in each error identity.
> > > > > >
> > > > > > > > I know this is NETCONF and RESTCONF centric but those are
> > > > > > > > the only
> > > > > > > > 2
> > > > > >
> > > > > > > > standard protocols supported for the YANG language right now.
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > >        If the 'error-tag' field is used in error
> > > > > > > > reporting,
> > > > > >
> > > > > > > >        then the value '<correct error-tag>' MUST be used.
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > For example:
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > OLD:
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > >   identity insufficient-resources {
> > > > > >
> > > > > > > >     base establish-subscription-error;
> > > > > >
> > > > > > > >     base modify-subscription-error;
> > > > > >
> > > > > > > >     base subscription-suspended-reason;
> > > > > >
> > > > > > > >     description
> > > > > >
> > > > > > > >       "The publisher has insufficient resources to support
> > > > > > > > the
> > > > > >
> > > > > > > >        requested subscription.  An example might be that
> > > > > > > > allocated CPU
> > > > > >
> > > > > > > >        is too limited to generate the desired set of
> > > > > > > > notification
> > > > > >
> > > > > > > >        messages.";
> > > > > >
> > > > > > > >   }
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > NEW:
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > >   identity insufficient-resources {
> > > > > >
> > > > > > > >     base establish-subscription-error;
> > > > > >
> > > > > > > >     base modify-subscription-error;
> > > > > >
> > > > > > > >     base subscription-suspended-reason;
> > > > > >
> > > > > > > >     description
> > > > > >
> > > > > > > >       "The publisher has insufficient resources to support
> > > > > > > > the
> > > > > >
> > > > > > > >        requested subscription.  An example might be that
> > > > > > > > allocated CPU
> > > > > >
> > > > > > > >        is too limited to generate the desired set of
> > > > > > > > notification
> > > > > >
> > > > > > > >        messages. If the 'error-tag' field is used in error
> > > > > > > > reporting,
> > > > > >
> > > > > > > >        then the value 'resource-denied' MUST be used.";
> > > > > >
> > > > > > > >   }
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > Andy
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > On Fri, Jan 18, 2019 at 11:53 AM Eric Voit (evoit)
> > > > > >
> > > > > > > > <mailto:evoit@cisco.com<mailto:mailto:evoit@cisco.com>> wrote:
> > > > > >
> > > > > > > > Hi Andy,
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > Thanks.  I have incorporated items where there was agreement.
> > > > > > > > I have
> > > > > >
> > > > > > > > removed the items below where you were ok.
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > Remaining below are the open items, with responses.
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > > >    Should be clear somewhere that
> > > > > >
> > > > > > > > > >    suspend is for CPU and other resources, and NACM
> > > > > > > > > > not considered
> > > > > >
> > > > > > > > > >    to be a resource.
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > If NACM is active, it needs to be followed.  The text we
> > > > > > > > > have for
> > > > > >
> > > > > > > > > NACM is in Section 5.4.  Do you see something else
> > > > > > > > > specific to
> > > > > >
> > > > > > > > > subscription suspension needed here?  (Maybe I am not
> > > > > > > > > getting your
> > > > > >
> > > > > > > > > point.)
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > No -- OK to leave NACM as terminate-if-loss-of-rights
> > > > > > > > > (Is there an
> > > > > >
> > > > > > > > > error identity for this event?)
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > The identity which applies here is "stream-unavailable".
> > > > > > > > This is the
> > > > > >
> > > > > > > > same identity which would be used if a subscriber had
> > > > > > > > never sufficient
> > > > > >
> > > > > > > > permissions in the first place.  I don't believe we would
> > > > > > > > want to
> > > > > >
> > > > > > > > return an identity specific to when NACM when permissions
> > > > > > > > have just
> > > > > >
> > > > > > > > been changed.
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > > > I3) sec 2.1 para 6:
> > > > > >
> > > > > > > > > >    Event records MUST NOT be delivered to a receiver
> > > > > > > > > > in a different
> > > > > >
> > > > > > > > > >    order than they were placed onto an event stream.
> > > > > >
> > > > > > > > > >
> > > > > >
> > > > > > > > > >   -- does this apply to subscription-state? Think not,
> > > > > > > > > > they are not events
> > > > > >
> > > > > > > > > >     placed in event stream.
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > Agree that they are not on the event stream.  So they do
> > > > > > > > > not violate
> > > > > >
> > > > > > > > > this requirement.
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > Additionally there is supporting text in "Section 2.7:
> > > > > > > > > subscription
> > > > > >
> > > > > > > > > state notifications", including...
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > " Instead, they are inserted (as defined in this
> > > > > > > > > section) within the
> > > > > >
> > > > > > > > > sequence of notification messages sent to a particular
> > > > > > > > > receiver."
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > >     Need to allow ended or suspended to be sent
> > > > > >
> > > > > > > > > >     head-of-line whenever state changes
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > I am not sure that suspended should always be sent head-of-line.
> > > > > >
> > > > > > > > > Consider
> > > > > >
> > > > > > > > > that implementation might want to let the existing queue
> > > > > > > > > of filtered
> > > > > >
> > > > > > > > > event records be sent if is filter complexity causing
> > > > > > > > > the CPU issue.
> > > > > >
> > > > > > > > > That could be different than if it is a bandwidth issue
> > > > > > > > > driving the
> > > > > >
> > > > > > > > > suspension, and you definitely want the 'subscription-suspended'
> > > > > > > > > to
> > > > > >
> > > > > > > > > be placed at the head of line.
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > It is up to the publisher to decide when to stop sending
> > > > > > > > > events on a
> > > > > >
> > > > > > > > > subscription.
> > > > > >
> > > > > > > > > Obviously the publisher cannot wait until the
> > > > > > > > > subscription is idle.
> > > > > >
> > > > > > > > > The reason it is getting suspended is it is far from
> > > > > > > > > idle
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > So also up to the publisher wrt/ what to do with any
> > > > > > > > > events that
> > > > > >
> > > > > > > > > have not been delivered yet on a subscription.  Could
> > > > > > > > > delete them or
> > > > > >
> > > > > > > > > save them for when more bandwidth available (for
> > > > > > > > > example)
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > Agree fully with this.  Is there text required in the draft here?
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > ...
> > > > > >
> > > > > > > > > Beyond that it is up to the implementation to decide if
> > > > > > > > > some
> > > > > >
> > > > > > > > > un-transmitted queue of event records should be flushed
> > > > > > > > > and
> > > > > >
> > > > > > > > > reprocessed based on the modification.  I do not expect
> > > > > > > > > this would
> > > > > >
> > > > > > > > > popular, as a replay subscription could accomplish this
> > > > > > > > > same
> > > > > >
> > > > > > > > > functional need.
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > Agreed that an implementation can drop at any time and
> > > > > > > > > increment the
> > > > > >
> > > > > > > > > appropriate counters. It will try to to do this, but no
> > > > > > > > > requirements
> > > > > >
> > > > > > > > > except maybe subscription events like 'replay-completed'
> > > > > > > > > cannot be
> > > > > >
> > > > > > > > > dropped
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > Have put a minor tweak into Section 2.7:
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > [old]  subscription state change notifications cannot be
> > > > > > > > filtered out
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > [new] subscription state change notifications cannot be
> > > > > > > > dropped or
> > > > > >
> > > > > > > > filtered out
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > ...
> > > > > >
> > > > > > > > > Thinking more on your point, it might be worth tweaking
> > > > > > > > > a couple
> > > > > >
> > > > > > > > > words to allow for head-of-line placement of
> > > > > >
> > > > > > > > > "subscription-suspended".
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > >    "Subscribed event records queued for sending after
> > > > > > > > > the issuance of
> > > > > >
> > > > > > > > >    this
> > > > > >
> > > > > > > > >    subscription state change notification may now be sent."
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > Are you good with this suggested change?
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > Not sure -- it needs to be clear that
> > > > > > > > > subscription-suspended is the
> > > > > >
> > > > > > > > > last event sent before suspending and
> > > > > > > > > subscription-resumed is the
> > > > > >
> > > > > > > > > first event sent after transition from suspended to active.
> > > > > >
> > > > > > > > > The next event could also be subscription-terminated.
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > I do think this possibility is covered in the text.  For
> > > > > > > > Section
> > > > > > > > 2.7.4
> > > > > >
> > > > > > > > subscription-suspended the current text is:
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > "No further notification will be sent until the
> > > > > > > > subscription resumes
> > > > > >
> > > > > > > > or is terminated."
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > And Section 2.7.5 subscription-resumed says":
> > > > > >
> > > > > > > > "Subscribed event records generated after the issuance of
> > > > > > > > this
> > > > > >
> > > > > > > > subscription state change notification may now be sent."
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > Based on the discussion, I can make it:
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > "Subscribed event records are again permitted to be sent
> > > > > > > > following
> > > > > >
> > > > > > > > this subscription state change notification."
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > Is this sufficient for you?
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > ...
> > > > > >
> > > > > > > > > > I4) sec 2.4.6: RPC Failures
> > > > > >
> > > > > > > > > >   -- concern about a subscription-specific error
> > > > > > > > > > reporting system
> > > > > >
> > > > > > > > > >      must make sure protocol error reporting system is
> > > > > > > > > > used
> > > > > >
> > > > > > > > > > correctly
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > Yes.  We have done our best to integrate with the
> > > > > > > > > embedded NETCONF
> > > > > >
> > > > > > > > > and RESTCONF mechanisms.  There is much additional
> > > > > > > > > information in
> > > > > >
> > > > > > > > > the transport drafts here.
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > >   -- The error-tag value needs to be identified for each
> > > > > > > > > >   -- 'reason'
> > > > > >
> > > > > > > > > > identity
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > This is done in the transport drafts.  E.g., see
> > > > > >
> > > > > > > > > draft-ietf-netconf-netconf-event-
> > > > > >
> > > > > > > > > notifications Section 7
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > I do not agree this is a good idea.
> > > > > >
> > > > > > > > > Each error identity should simply state the required "error-tag"
> > > > > >
> > > > > > > > > that is associated with the error.  This is expected of
> > > > > > > > > protocol
> > > > > >
> > > > > > > > > operations that are added to NETCONF and RESTCONF.
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > In draft-ietf-netconf-netconf-event-notifications, section
> > > > > > > > 7, the
> > > > > >
> > > > > > > > required "error-tag" is identified as "operation-failed".
> > > > > > > > If we
> > > > > >
> > > > > > > > instead placed that "error-tag" information in the YANG
> > > > > > > > model, then we
> > > > > >
> > > > > > > > have tied the YANG model to the RESTCONF and NETCONF
> transports.
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > > Both NETCONF and RESTCONF use a compatible error
> > > > > > > > > reporting data
> > > > > >
> > > > > > > > > structure.
> > > > > >
> > > > > > > > > The "error-tag" is used in both of them.  IMO client
> > > > > > > > > developers do
> > > > > >
> > > > > > > > > not want a different set of error codes for the same
> > > > > > > > > error conditions.
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > draft-ietf-netconf-restconf-notif Section 3.3 also
> > > > > > > > requires an
> > > > > >
> > > > > > > > "error-tag" node of "operation-failed".  So we used the
> > > > > > > > transport
> > > > > >
> > > > > > > > drafts rather than the YANG model to support the same
> > > > > > > > error codes for
> > > > > >
> > > > > > > > the same error conditions.
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > > I agree that transport drafts could define their own
> > > > > > > > > error
> > > > > >
> > > > > > > > > identities, which would document the expected error-tag there.
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > >    2.  "modify-subscription-stream-error-info": This
> > > > > > > > > > MUST be returned
> > > > > >
> > > > > > > > > >        with the leaf "reason" populated if an RPC
> > > > > > > > > > error reason has not
> > > > > >
> > > > > > > > > >        been placed elsewhere within the transport
> > > > > > > > > > portion of a failed
> > > > > >
> > > > > > > > > >        "modify-subscription" RPC response.  This MUST
> > > > > > > > > > be sent if
> > > > > >
> > > > > > > > > > hints
> > > > > >
> > > > > > > > > >
> > > > > >
> > > > > > > > > >   -- all 3 paragraphs like this; unclear what "placed
> > > > > > > > > >   -- elsewhere"
> > > > > >
> > > > > > > > > >       text means; not appropriate for MUST;
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > Instead of "placed elsewhere", how about: "placed in
> > > > > > > > > subscription
> > > > > >
> > > > > > > > > transport document defined object".  Would this be sufficient?
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > No -- NETCONF and RESTCONF have well-defined error reporting.
> > > > > >
> > > > > > > > > The server requirements for this error reporting must be
> > > documented.
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > I agree with the following approach:
> > > > > >
> > > > > > > > >   - each operation MUST identify the error-tags that are
> > > > > > > > > expected for
> > > > > >
> > > > > > > > >     various error conditions (such s is done in RFC
> > > > > > > > > 6241)
> > > > > >
> > > > > > > > >   - the server MUST return the specified error-tags. If
> > > > > > > > > a condition not
> > > > > >
> > > > > > > > >   - explicitly
> > > > > >
> > > > > > > > >     defined then the server MUST pick the appropriate
> > > > > > > > > error-tag from RFC
> > > > > >
> > > > > > > > >     6241
> > > > > >
> > > > > > > > >  - the server MAY include the specified rc:yang-data in
> > > > > > > > > the
> > > > > >
> > > > > > > > > <error-info>
> > > > > >
> > > > > > > > >  - data
> > > > > >
> > > > > > > > > structure
> > > > > >
> > > > > > > > >  - the server MUST use the appropriate rc:yang-data to
> > > > > > > > > report hints
> > > > > >
> > > > > > > > >  - for protocols other than NETCONF and RESTCONF, they
> > > > > > > > > can map
> > > > > >
> > > > > > > > > error-tag
> > > > > >
> > > > > > > > >  - or
> > > > > >
> > > > > > > > > ignore it,
> > > > > >
> > > > > > > > >    but the document defining the protocol operation MUST
> > > > > > > > > provide
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > Functionally, everything you ask for is fully covered when
> > > > > > > > you include
> > > > > >
> > > > > > > > consider draft-ietf-netconf-netconf-event-notifications
> > > > > > > > (section
> > > > > > > > 7)
> > > > > >
> > > > > > > > and draft-ietf-netconf-restconf-notif (section 3.3).
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > My read of the issue is that you believe "error-tag" must
> > > > > > > > be specified
> > > > > >
> > > > > > > > in the YANG model.  I believe that "error-tag" shouldn't
> > > > > > > > be in the
> > > > > >
> > > > > > > > YANG model because that would tie the model to a transport type.
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > Any thoughts on how we might close this?  If absolutely
> > > > > > > > required I
> > > > > >
> > > > > > > > could place a new comment line in the YANG model under
> > > > > >
> > > > > > > > /* Identities for RPC and Notification errors */
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > The comment would be something like:
> > > > > >
> > > > > > > > /* When used with NETCONF and RESTCONF RPCs:
> > > > > >
> > > > > > > >     "error-type" node to be used is "application"
> > > > > >
> > > > > > > >      "error-tag" must be "operation-failed".  */
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > This seems incongruous.  Just throwing it out as a suggestion.
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > > In any case, the -v21 wording results from the attempted
> > > > > > > > > balancing
> > > > > >
> > > > > > > > > the WG requests for:
> > > > > >
> > > > > > > > > * merging with transport protocol error mechanisms
> > > > > >
> > > > > > > > > * WG leadership guidance to provide requirements for
> > > > > > > > > transport
> > > > > >
> > > > > > > > > documents
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > >      Only 3 fields seem
> > > > > >
> > > > > > > > > >       to be relevant (error-tag, error-app-tag, error-info).
> > > > > >
> > > > > > > > > >       Protcol operations are expected to document
> > > > > > > > > > server requirements
> > > > > >
> > > > > > > > > >       for these 3 fields, if applicable.  Only the
> > > > > > > > > > error-tag
> > > > > >
> > > > > > > > > >       is mandatory-to-use.
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > Hopefully these are covered sufficiently when this
> > > > > > > > > document is
> > > > > >
> > > > > > > > > coupled with the NETCONF and RESTCONF Notif transport
> > > documents.
> > > > > >
> > > > > > > > > For other transports, the tags you identify about would
> > > > > > > > > not be
> > > > > >
> > > > > > > > > applicable.
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > >   -- the error assignments are extremely specific.
> > > > > > > > > > e.g., it is not
> > > > > >
> > > > > > > > > >      possible for <kill-subscription> to fail with an
> > > > > >
> > > > > > > > > >      'insufficient-resources' error;
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > This is the intent of the base specification, e.g., we
> > > > > > > > > don't believe
> > > > > >
> > > > > > > > > a
> > > > > >
> > > > > > > > > kill-
> > > > > >
> > > > > > > > > subscription should fail for an insufficient-resources reason.
> > > > > > > > > But
> > > > > >
> > > > > > > > > vendors might desire more specificity.  As a result is
> > > > > > > > > certainly ok
> > > > > >
> > > > > > > > > for vendor implementations to add new error identities.
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > IMO anything can fail for insufficient resources. That
> > > > > > > > > is very
> > > > > >
> > > > > > > > > implementation-
> > > > > >
> > > > > > > > > specific.
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > Instead of implementation specific I would call it
> > > > > > > > application
> > > > > >
> > > > > > > > specific.  Right now we don't have a catch-all
> > > > > > > > error-identity of
> > > > > >
> > > > > > > > 'other-error'.  We preferred that error conditions beyond
> > > > > > > > the current
> > > > > >
> > > > > > > > ones listed could be included by vendors as needed.
> > > > > > > > Further
> > > > > >
> > > > > > > > deployment experience could result in new error identities
> > > > > > > > surfacing
> > > > > >
> > > > > > > > for standardization should this draft catch on.
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > > >      Do not agree that scoping each
> > > > > >
> > > > > > > > > >      identity to specific RPC operations is a good idea.
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > This level of specificity was not the author's original plans.
> > > > > > > > > Nor
> > > > > >
> > > > > > > > > was this level of specificity part of earlier draft
> > > > > > > > > versions up
> > > > > >
> > > > > > > > > through -v08.  However members of the WG made it clear
> > > > > > > > > that such
> > > > > >
> > > > > > > > > specificity was necessary for draft progression.
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > >   -- how are errors in these parameters reported for
> > > > > > > > > > configured
> > > > > >
> > > > > > > > > >      subscriptions when <edit-config> is the RPC that has the
> > > > > > > > > >      error?
> > > > > >
> > > > > > > > > >      How are the yang-data structs used for
> > > > > > > > > > edit-config or commit
> > > > > errors?
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > None of these yang-data structures are specified for use
> > > > > > > > > with
> > > > > >
> > > > > > > > > <edit-config> operations.  For <edit-config>, the change
> > > > > > > > > to a
> > > > > >
> > > > > > > > > configured subscription would be written to the
> > > > > > > > > datastore if it were
> > > > > >
> > > > > > > > > semantically valid.  At this point the subscription
> > > > > > > > > enters the
> > > > > >
> > > > > > > > > [evaluate] points of Figure 8.  Issues from this point
> > > > > > > > > out would be
> > > > > >
> > > > > > > > > reported with a vendor specific construct such as SYSLOG.
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > So how are hints reported for configured subscriptions?
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > There is nothing in the specification which requires this.
> > > > > > > > An
> > > > > >
> > > > > > > > implementation could choose to place these in some form of
> SYSLOG.
> > > > > >
> > > > > > > > ...
> > > > > >
> > > > > > > > > > I6) sec 2.5, para 3:
> > > > > >
> > > > > > > > > >
> > > > > >
> > > > > > > > > >    On a receiver of a
> > > > > >
> > > > > > > > > >    configured subscription, support for dynamic
> > > > > > > > > > subscriptions is
> > > > > >
> > > > > > > > > >    optional except where replaying missed event records is
> > > > > > > > > >    required.
> > > > > >
> > > > > > > > > >
> > > > > >
> > > > > > > > > >   -- confusing because text in 1.3:
> > > > > >
> > > > > > > > > >      Note that there is no mixing-and-matching of
> > > > > > > > > > dynamic and configured
> > > > > >
> > > > > > > > > >      operations on a single subscription.
> > > > > > > > > > Specifically, a configured
> > > > > >
> > > > > > > > > >   -- clarify the receiver may have multiple
> > > > > > > > > > subscriptions here
> > > > > >
> > > > > > > > > >   -- not clear what "except where replaying..." text
> > > > > > > > > > means
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > How about the following tweak:
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > "On a receiver of a configured subscription, support for
> > > > > > > > > dynamic
> > > > > >
> > > > > > > > > subscriptions is optional.  However if replaying missed
> > > > > > > > > event
> > > > > >
> > > > > > > > > records is required for a configured subscription,
> > > > > > > > > support for
> > > > > >
> > > > > > > > > dynamic subscription is highly recommended.  In this
> > > > > > > > > case, a
> > > > > >
> > > > > > > > > separate dynamic subscription can be established to
> > > > > > > > > retransmit the
> > > > > >
> > > > > > > > > missing event records."
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > OK
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > Change made.
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > > > I7) leaf stream-xpath-filter: [multiple uses]
> > > > > >
> > > > > > > > > >
> > > > > >
> > > > > > > > > >            The expression is evaluated in the following XPath
> > > > > > > > > >            context:
> > > > > >
> > > > > > > > > >
> > > > > >
> > > > > > > > > >              o The set of namespace declarations is the set of
> > > > > > > > > >              prefix
> > > > > >
> > > > > > > > > >                  and namespace pairs for all YANG
> > > > > > > > > > modules implemented
> > > > > >
> > > > > > > > > >                  by the server, where the prefix is
> > > > > > > > > > the YANG module
> > > > > >
> > > > > > > > > >                  name and the namespace is as defined
> > > > > > > > > > by the
> > > > > >
> > > > > > > > > >                  'namespace' statement in the YANG module.
> > > > > >
> > > > > > > > > >
> > > > > >
> > > > > > > > > >   -- This prefix processing is not done anywhere else
> > > > > > > > > > in NETCONF
> > > > > >
> > > > > > > > > >      or RESTCONF.  IMO a bad precedent.  Only the XML
> > > > > > > > > > prefixes
> > > > > >
> > > > > > > > > >      should be required for processing of XML encoding.
> > > > > > > > > > YANG
> > > > > >
> > > > > > > > > >      module prefixes are not required to be unique,
> > > > > > > > > > unlike
> > > > > >
> > > > > > > > > >      the prefix mappings in XML
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > This text was proposed by Martin as a result of the
> > > > > > > > > "xpath
> > > > > >
> > > > > > > > > expressions in JSON"
> > > > > >
> > > > > > > > > thread last October in NETMOD.
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > I am happy to incorporate whatever text is appropriate.
> > > > > > > > > I was
> > > > > >
> > > > > > > > > hoping that the suggested text was sufficient for now.
> > > > > > > > > Kent has
> > > > > >
> > > > > > > > > already incorporated this as an issue for yang-next
> > > > > >
> > > > > > > > > https://github.com/netmod-wg/yang-next/issues/55
> > > > > >
> > > > > > > > > So hopefully there is no final precedent being claimed.
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > I do not agree that this YANG module should define a new
> > > > > > > > > way to
> > > > > >
> > > > > > > > > encode XPath into XML instance documents. This will
> > > > > > > > > require
> > > > > >
> > > > > > > > > significant changes to server implementations.  YANG
> > > > > > > > > module prefixes
> > > > > >
> > > > > > > > > are not even required to be unique so the set of
> > > > > > > > > prefixes used by
> > > > > >
> > > > > > > > > the server in XML instance documents may be different,
> > > > > > > > > since it must
> > > > > >
> > > > > > > > > be unique.
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > See next note
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > > >   -- NMDA allows the same module to appear in multiple
> > > > > > > > > > module-sets
> > > > > >
> > > > > > > > > >      and different in each datastore. This text about
> > > > > > > > > > "implemented by
> > > > > >
> > > > > > > > > >      the server" does not work for NMDA
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > I am happy to adopt whatever text meets YANG doctor approval.
> > > > > > > > > Can
> > > > > >
> > > > > > > > > you suggest?
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > Remove all text about YANG prefixes and continue using
> > > > > > > > > XML encoding
> > > > > >
> > > > > > > > > without modification
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > As a different YANG doctor has required the current text
> > > > > > > > modification,
> > > > > >
> > > > > > > > I believe this is a blocker.  What is the process for YANG
> > > > > > > > model
> > > > > >
> > > > > > > > reviews in such a case.  I am happy to accept whatever here.
> > > > > > > > Any
> > > > > >
> > > > > > > > suggestions on next steps?
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > ...
> > > > > >
> > > > > > > > > >   -- there should be an example of a configurable
> > > > > > > > > > encoding
> > > > > >
> > > > > > > > > > provided
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > I am happy to enhance the definition YANG model's
> > > > > > > > > identity
> > > > > >
> > > > > > > > > definition of "configurable-encoding".  I could do this
> > > > > > > > > by adding
> > > > > >
> > > > > > > > > the following additional text to the description: "An
> > > > > > > > > example of a
> > > > > >
> > > > > > > > > configurable encoding might be a new identity such as
> > > > > > > > > 'encode-cbor'.
> > > > > >
> > > > > > > > > Such an identity could use
> > > > > >
> > > > > > > > > 'configurable-
> > > > > >
> > > > > > > > > encoding' as its base.  This would allow a dynamic
> > > > > > > > > subscription
> > > > > >
> > > > > > > > > encoded in JSON [RFC-8259] to request notification
> > > > > > > > > messages be
> > > > > >
> > > > > > > > > encoded via CBOR [RFC- 7049].  Further details for any
> > > > > > > > > specific
> > > > > >
> > > > > > > > > configurable encoding would be explored in a transport
> > > > > > > > > document
> > > > > >
> > > > > > > > > based on this specification."  Does this meet your ask?
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > OK
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > Added
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > > > I11) extension subscription-state-notification {
> > > > > >
> > > > > > > > > >
> > > > > >
> > > > > > > > > >        This statement is not for use
> > > > > >
> > > > > > > > > >        outside of this YANG module.";
> > > > > >
> > > > > > > > > >
> > > > > >
> > > > > > > > > >   -- this text should be removed. There is no value in
> > > > > > > > > > limiting
> > > > > >
> > > > > > > > > >      the scope of this extension.  It prevents even
> > > > > > > > > > this WG from
> > > > > >
> > > > > > > > > >      creating a module that uses the extension again.
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > This was the subject of significant debate in the WG.
> > > > > > > > > The authors
> > > > > >
> > > > > > > > > did not want this restriction either.
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > To be allowed to progress the document, we inserted the
> > > > > > > > > document.
> > > > > >
> > > > > > > > > If this really is mandatory-to-remove from a YANG doctor
> > > > > >
> > > > > > > > > point-of-view, what is the process for quick closure on
> > > > > > > > > this issue
> > > > > >
> > > > > > > > > between WG leadership and the YANG doctors?
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > The YANG language makes no restrictions about exporting
> > > statements.
> > > > > >
> > > > > > > > > I guess I missed that debate so I will just say OK and
> > > > > > > > > wonder what
> > > > > >
> > > > > > > > > problem this is supposed to solve. I guess the WG wants
> > > > > > > > > to give YANG
> > > > > >
> > > > > > > > > Doctors more things to check. (This is what we called a
> > > > > > > > > CLR in
> > > > > >
> > > > > > > > > SNMP-land ;-)
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > Thanks.  No action taken.
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > > > I13)   notification subscription-started {
> > > > > >
> > > > > > > > > >     sn:subscription-state-notification;
> > > > > >
> > > > > > > > > >     if-feature "configured";
> > > > > >
> > > > > > > > > >     description
> > > > > >
> > > > > > > > > >       "This notification indicates that a subscription
> > > > > > > > > > has started and
> > > > > >
> > > > > > > > > >         notifications are beginning to be sent. This
> > > > > > > > > > notification shall
> > > > > >
> > > > > > > > > >        only be sent to receivers of a subscription; it
> > > > > > > > > > does not
> > > > > >
> > > > > > > > > >        constitute a general-purpose notification.";
> > > > > >
> > > > > > > > > >
> > > > > >
> > > > > > > > > >   -- 2nd sentence is confusing; all notifications are
> > > > > > > > > > sent to
> > > > > >
> > > > > > > > > >      receivers of a subscription. last part is
> > > > > > > > > > redundant since
> > > > > >
> > > > > > > > > >      the sn:subscription-state-notification extension
> > > > > > > > > > is used
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > There is no issue with removing this second sentence completely.
> > > > > > > > > If
> > > > > >
> > > > > > > > > I did that, would this address your concern?
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > OK
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > Done
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > > > I14)   rc:yang-data modify-subscription-stream-error-info {
> > > > > >
> > > > > > > > > >
> > > > > >
> > > > > > > > > >       leaf filter-failure-hint {
> > > > > >
> > > > > > > > > >         type string;
> > > > > >
> > > > > > > > > >           description
> > > > > >
> > > > > > > > > >             "Information describing where and/or why a
> > > > > > > > > > provided filter
> > > > > >
> > > > > > > > > >              was unsupportable for a subscription.";
> > > > > >
> > > > > > > > > >       }
> > > > > >
> > > > > > > > > >
> > > > > >
> > > > > > > > > >   -- rpc-error already allows more precise error
> > > > > > > > > > reporting
> > > > > >
> > > > > > > > > >      It uses error-tag, error-path, error-string, and
> > > > > > > > > > error-info
> > > > > >
> > > > > > > > > >      extensions
> > > > > >
> > > > > > > > > >      to identify which parameters/conditions caused
> > > > > > > > > > the RPC to be
> > > > > >
> > > > > > > > > >      rejected.
> > > > > >
> > > > > > > > > >      This error reporting will continue to be used,
> > > > > > > > > > Not sure this
> > > > > >
> > > > > > > > > >      failure-hint
> > > > > >
> > > > > > > > > >      has any standards value. Perhaps real-use example
> > > > > > > > > > can be
> > > > > >
> > > > > > > > > > added
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > Per your thoughts on rpc-error...  For NETCONF and
> > > > > > > > > RESTCONF, you
> > > > > >
> > > > > > > > > point to error structures which historically been used
> > > > > > > > > with those
> > > > > >
> > > > > > > > > transports.
> > > > > >
> > > > > > > > > Of course
> > > > > >
> > > > > > > > > we were looking to have all subscription hints
> > > > > > > > > supportable across
> > > > > >
> > > > > > > > > transports via a single portable YANG data structure.
> > > > > > > > > So the value
> > > > > >
> > > > > > > > > is that a single string object exists so to transport
> > > > > > > > > whatever the
> > > > > >
> > > > > > > > > vendor thinks would be useful as a hint in this case.
> > > > > > > > > I.e., there
> > > > > >
> > > > > > > > > has been no attempt to standardize the contents of this string.
> > > > > > > > > If
> > > > > >
> > > > > > > > > operational experiences drive a desire for such
> > > > > > > > > structuring, this
> > > > > >
> > > > > > > > > could provide the basis for a new draft building off of
> > > > > > > > > this
> > > > > >
> > > > > > > > > starting point.
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > I guess I do not consider NETCONF and RESTCONF
> > > > > > > > > "historic" quite
> > > yet.
> > > > > >
> > > > > > > > > There are many implementations using the rpc-error
> > > > > > > > > reporting with no
> > > > > >
> > > > > > > > > intent to replace it with something else.
> > > > > >
> > > > > > > > >
> > > > > >
> > > > > > > > > I was just asking for an example, since I have no idea
> > > > > > > > > what an
> > > > > >
> > > > > > > > > implementor would put in this leaf.
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > Here is an example from our implementation.  Say you
> > > > > > > > mistype an extra
> > > > > >
> > > > > > > > "\" to an xpath filter:
> > > > > >
> > > > > > > > /if:interfaces-state/interface[name="GigabitEthernet0/0"]/
> > > > > > > > oper
> > > > > > > > -sta
> > > > > > > > tus
> > > > > >
> > > > > > > > As a result, the filter is passed to the publisher is:
> > > > > >
> > > > > > > > /if:inte\rfaces-state/interface[name="GigabitEthernet0/0"]
> > > > > > > > /ope
> > > > > > > > r-st
> > > > > > > > atus
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > What we would return in the failure-hint string is:
> > > > > >
> > > > > > > > Invalid expression: offset(9) in
> > > > > >
> > > > > > > > '/if:inte\rfaces-state/interface[name="GigabitEthernet0/0"
> > > > > > > > ]/oper-
> > > status'
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > Eric
> > > > > >
> > > > > > > >
> > > > > >
> > > > > > > > > Andy