Re: [netconf] [yang-doctors] Yangdoctors last call review of draft-ietf-netconf-subscribed-notifications-21
Andy Bierman <andy@yumaworks.com> Thu, 24 January 2019 17:29 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 8E6FE1312A7 for <netconf@ietfa.amsl.com>; Thu, 24 Jan 2019 09:29:56 -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=unavailable 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 YBAnNUmsvY_Z for <netconf@ietfa.amsl.com>; Thu, 24 Jan 2019 09:29:48 -0800 (PST)
Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (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 4FB39131197 for <netconf@ietf.org>; Thu, 24 Jan 2019 09:29:47 -0800 (PST)
Received: by mail-lj1-x235.google.com with SMTP id t9-v6so5963805ljh.6 for <netconf@ietf.org>; Thu, 24 Jan 2019 09:29:47 -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=g6t0EdS8iOX9gCO6HQotf8EBjWFlmWI0HsHlG0BAlKM=; b=Ub6iNxeDKCyJGhzJqn5cYrlwmtKVXMw9kBAPYLR0LzpYGk4R3VKjvWqoyKEPvJv2wT wtUztq45IRXCYeDtqBBh5cwubIgkbQIGExcPVVkXieSug5Ckh24WQ0a23fajXR+KH7Gx o7AQCcuAmgCb0gSCW/kdO1IVyubupymq9wOLFz4HnJqA+hnGTHAQVkFKYl1T1eY0d5GC kgglPF4Zx15AQ5r2kaBuvlKIRmE8r9nDI+EoJMTc/00xkwWX5OMQNphXx4KYX4ZzaKSq lSez3RCYtsAH2bgrmLPEMz1zg91otnC6ArJ/JrXahNwXu0JFT+fWHldNfkZx7bZsd5/9 PAPQ==
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=g6t0EdS8iOX9gCO6HQotf8EBjWFlmWI0HsHlG0BAlKM=; b=kRWxY8h/knQ3y2HbDQSx48tMtJ2Gjj+DkPj0x2aoGdoL0rxxn4pBJblAfRBoCvq4wi W8w7wuImNJ5xHwPcD5CglFVwjs9Q7sgEFMgRYccfJWK2XYypdPTLt8aF6aZErCt+JswE jwZ9Op/QXL8eIMkEQx9yQ78FEFq8O5HkJTsyVR/Flj9uicQIVtQipuxZ8mRwIoPcJhcu 8E9aUJ/gmHefMw7u93K04nd+DKBWMvgcQV/+WUNw+Gzlav8M1sUDfJTzWJGWn5kgUZlw 2xVlNbRdZ3hSqOogxZfvq12AE3VySLrgW9uHs9KKufyQUWki2eHMfhl2p4sfTZkPf8uL krMw==
X-Gm-Message-State: AJcUukcbD0kiMlIll+8AmGti08YWkoMCd5EWWZXBdg0clCPKpWdoxoVT QgSHy4XC0AJhMpvc4V2Bz7UAmQ0Q3ggKci9wJ+7AKzjr
X-Google-Smtp-Source: ALg8bN5VECspZfQR89J19CDyuMm1B+DhZ7TSm2aN8OQreTJqWaHtj1U1A0CBX0stlMQwdPe1cN+wbrLOQVUqbOsmAD0=
X-Received: by 2002:a2e:458b:: with SMTP id s133-v6mr6829571lja.170.1548350984772; Thu, 24 Jan 2019 09:29:44 -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>
In-Reply-To: <9f0f48b7e17c40fab9a64b4a2488997e@XCH-RTP-013.cisco.com>
From: Andy Bierman <andy@yumaworks.com>
Date: Thu, 24 Jan 2019 09:29:32 -0800
Message-ID: <CABCOCHQTxdi8=x-k+FaWrVUwsg0J945i_c1_jmLJRC=FonZoAg@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="0000000000006f828a0580378e21"
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/VTm2wQ1Ldh1WdsCp9mfo84SZOA4>
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:29:57 -0000
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. Andy > > > > > 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 >
- [Netconf] Yangdoctors last call review of draft-i… Andy Bierman
- Re: [Netconf] Yangdoctors last call review of dra… Eric Voit (evoit)
- Re: [Netconf] Yangdoctors last call review of dra… Andy Bierman
- Re: [netconf] Yangdoctors last call review of dra… Eric Voit (evoit)
- Re: [netconf] Yangdoctors last call review of dra… Mehmet Ersue
- Re: [netconf] Yangdoctors last call review of dra… Andy Bierman
- Re: [netconf] [yang-doctors] Yangdoctors last cal… Martin Bjorklund
- Re: [netconf] [yang-doctors] Yangdoctors last cal… Andy Bierman
- Re: [netconf] Yangdoctors last call review of dra… Andy Bierman
- Re: [netconf] Yangdoctors last call review of dra… Eric Voit (evoit)
- Re: [netconf] Yangdoctors last call review of dra… Andy Bierman
- Re: [netconf] [yang-doctors] Yangdoctors last cal… Martin Bjorklund
- Re: [netconf] [yang-doctors] Yangdoctors last cal… Eric Voit (evoit)
- Re: [netconf] [yang-doctors] Yangdoctors last cal… Andy Bierman
- Re: [netconf] [yang-doctors] Yangdoctors last cal… Eric Voit (evoit)
- Re: [netconf] [yang-doctors] Yangdoctors last cal… Martin Bjorklund
- Re: [netconf] [yang-doctors] Yangdoctors last cal… Eric Voit (evoit)
- Re: [netconf] [yang-doctors] Yangdoctors last cal… Martin Bjorklund
- Re: [netconf] [yang-doctors] Yangdoctors last cal… Eric Voit (evoit)
- Re: [netconf] [yang-doctors] Yangdoctors last cal… Martin Bjorklund
- Re: [netconf] [yang-doctors] Yangdoctors last cal… Eric Voit (evoit)
- Re: [netconf] [yang-doctors] Yangdoctors last cal… Andy Bierman
- Re: [netconf] [yang-doctors] Yangdoctors last cal… Martin Bjorklund
- Re: [netconf] [yang-doctors] Yangdoctors last cal… Eric Voit (evoit)
- Re: [netconf] [yang-doctors] Yangdoctors last cal… Eric Voit (evoit)
- Re: [netconf] [yang-doctors] Yangdoctors last cal… Andy Bierman
- Re: [netconf] [yang-doctors] Yangdoctors last cal… Martin Bjorklund
- Re: [netconf] [yang-doctors] Yangdoctors last cal… Eric Voit (evoit)
- Re: [netconf] [yang-doctors] Yangdoctors last cal… Martin Bjorklund
- Re: [netconf] [yang-doctors] Yangdoctors last cal… Eric Voit (evoit)
- Re: [netconf] [yang-doctors] Yangdoctors last cal… Per Hedeland
- Re: [netconf] [yang-doctors] Yangdoctors last cal… Eric Voit (evoit)
- Re: [netconf] [yang-doctors] Yangdoctors last cal… Per Hedeland
- Re: [netconf] [yang-doctors] Yangdoctors last cal… Eric Voit (evoit)
- Re: [netconf] [yang-doctors] Yangdoctors last cal… Eric Voit (evoit)