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 15:23 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 4DA64124408; Thu, 24 Jan 2019 07:23:06 -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 act5ASmMaqcT; Thu, 24 Jan 2019 07:23:02 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04FE41286D9; Thu, 24 Jan 2019 07:23:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=64334; q=dns/txt; s=iport; t=1548343382; x=1549552982; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=W1glKgBnO8n8JCYF2X2CkZxgwYcajE318iMPugt241Q=; b=OCFhYBfDLFGoZT5IDxTP6aJxMdr4MHIOjhxf5vgDtvssiT8OpnH3bg3D ynfTV5V6V4wYlqelvuZ+9K1IfKgU3XLXwmKQE8nuqsLivUqwq7EBZqA3F jfe26YZputbVqxnLe6IB9e9NdwgpKsIgYlwmkWozQVZJIftYfR4djvl2w Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0ADAACJ10lc/5tdJa1ZAQIHGQEBAQEBAQEBAQEBAQcBAQEBAQGBUQQBAQEBAQsBgVopZ4EDJwqDd4gai3GCDYNGlEEUgWcLAQEjhEkCF4JsIjQJDQEDAQECAQECbRwMhUoBAQEBAgEaAQgRQwIFCwIBCA4DBAEBAQICCRoDAgICMBQBCAgCBA4FCIJPTIF5CA+sCIEviiwFgQuLNheBQD+BEYIUfoMeAoE2AQMPAgMqgnKCNSICiVUDCAomC4FKhCkBgViEb4p7XAkChyiDW4cZIIFpiGqBMoYaigmBDIQaiQ+CUgIRFIEnHziBVnAVO4JsgicXE20BCIJCilNBMYhiKYEFgR8BAQ
X-IronPort-AV: E=Sophos;i="5.56,516,1539648000"; d="scan'208";a="229989455"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Jan 2019 15:22:59 +0000
Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id x0OFMxBs021147 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 24 Jan 2019 15:22:59 GMT
Received: from xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 24 Jan 2019 10:22:58 -0500
Received: from xch-rtp-013.cisco.com ([64.101.220.153]) by XCH-RTP-013.cisco.com ([64.101.220.153]) with mapi id 15.00.1395.000; Thu, 24 Jan 2019 10:22:58 -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//60SYAANQ54AAApn7nA=
Date: Thu, 24 Jan 2019 15:22:58 +0000
Message-ID: <26102d90539d4794b9186dcfa9654bd1@XCH-RTP-013.cisco.com>
References: <7b77b0356d074648a5f1d8096c224210@XCH-RTP-013.cisco.com> <20190124.141640.253886322622907272.mbj@tail-f.com> <b72f5c48e01c4742b78e31e803c0e2a7@XCH-RTP-013.cisco.com> <20190124.153938.826269505351606159.mbj@tail-f.com>
In-Reply-To: <20190124.153938.826269505351606159.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.145, xch-rtp-005.cisco.com
X-Outbound-Node: rcdn-core-4.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/K2E3dpPDQZKYZtlnt0n7nosKFMA>
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 15:23:06 -0000
> 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. > > > 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. 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. 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)