Re: [Netconf] mbj's WGLC review of subscribed-notifications-16
Martin Bjorklund <mbj@tail-f.com> Thu, 13 September 2018 17:41 UTC
Return-Path: <mbj@tail-f.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 23585130E47 for <netconf@ietfa.amsl.com>; Thu, 13 Sep 2018 10:41:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 LNOAzCpL6vyj for <netconf@ietfa.amsl.com>; Thu, 13 Sep 2018 10:41:32 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 20DC0130E2F for <netconf@ietf.org>; Thu, 13 Sep 2018 10:41:32 -0700 (PDT)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 7E94B1AE018A; Thu, 13 Sep 2018 19:41:30 +0200 (CEST)
Date: Thu, 13 Sep 2018 19:41:30 +0200
Message-Id: <20180913.194130.1322555935706323857.mbj@tail-f.com>
To: evoit@cisco.com
Cc: netconf@ietf.org
From: Martin Bjorklund <mbj@tail-f.com>
In-Reply-To: <e3b31d1329ed439798205c1068186d38@XCH-RTP-013.cisco.com>
References: <013a970e210d4b9693116818f3d5688e@XCH-RTP-013.cisco.com> <20180913.092134.395462318086733174.mbj@tail-f.com> <e3b31d1329ed439798205c1068186d38@XCH-RTP-013.cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/cDeV6YFfVvCMxgHTZdeFqas04b8>
Subject: Re: [Netconf] mbj's WGLC review of subscribed-notifications-16
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Network Configuration WG mailing 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, 13 Sep 2018 17:41:34 -0000
Hi, "Eric Voit (evoit)" <evoit@cisco.com> wrote: [trimming...] > > > > > > o Section 2.4.6 > > > > > > > > > > > > The text says: > > > > > > > > > > > > 1. "establish-subscription-stream-error-info": This MUST be > > > > > > returned > > > > > > if an RPC error reason has not been placed elsewhere within > > > > > > the > > > > > > transport portion of a failed "establish-subscription" RPC > > > > > > response. > > > > > > > > > > > > (and similar for the other errors) > > > > > > > > > > > > What exactly does "if an RPC error reason has not been placed > > > > > > elsewhere" mean? > > > > > > > > > > The intent is to match how NETCONF & RESTCONF historically handles > > > > > errors. As you know with NETCONF, each error identity will be > > > > > inserted as the "error-app-tag". > > > > > > > > It could also be in "error-tag" and/or "error-message". My point is > > > > that I don't think that you mean that if an implementation populate > > > > say "error-message", then it should not popluate error-info with > > > > establish-subscription-stream- > > > > error-info. > > > > > > I do mean that. I don't think we should send: > > > "establish-subscription-stream-error-info" for NETCONF when there is > > > no hint included. All the necessary error info is already in the > > > existing message. > > > > But is this really true? In the > > "establish-subscription-stream-error-info" there is a leaf called > > "reason", which > > is an identity with a detailed error reason, for example > > "history-unavailable". > > This info is not present anywhere else in the rpc-error, so it needs > > to be > > present here. > > For NETCONF, this info should be mapped into <error-app-tag>. See > section 7 of NETCONF-Notif, as well as Figure 10 for an example. Or > section 3 of RESTCONF-Notif, with Figure 7. > > This was done to align things with existing NETCONF & RESTCONF error > mechanisms. Ok. I thought the special error-app-tag thing was removed. If we have the error-app-tag value, why do we also have the "reason" leaf? Since I thought that the error-app-tag was removed, I asked Alex to remove them from the examples in YANG push (that doc has examples ;). These examples in YANG push need to put back the error-app-tag. So now we're back to the main issue. Is it clear from the SN text when to include the error-info yang-data stuff or not? [...] > > > > > If > > > > > you want to pursue this further it is probably best to start a new > > > > > thread dedicated to this topic alone. > > > > > > > > > > > For example, what happens if the transport session is lost and > > > > > > re-established; are all event records in the buffer replayed again? > > > > > > > > > > No. The publisher will not lose context of what was sent. > > > > > > > > This is not clear from the text. In fact, the text explicitly says: > > > > > > > > The leading event record sent will be the first event record > > > > subsequent to the latest of three different times: the > > > > "replay-log-creation-time", "replay-log-aged- time", or the most > > > > recent publisher boot time. > > > > > > I see your point. I have tweaked the text to: > > > > > > " If the publisher does not know the next record intended for the > > > receiver, the leading event record..." > > > > Hmm, not sure this helps. How about: > > > > OLD: > > > > As a result, when any configured subscription receivers become > > active, buffered event records will be sent immediately after the > > "subscription-started" notification. If the publisher does not know > > the next record intended for the receiver, the leading event record > > sent will be the first event record subsequent to the latest of three > > different times: the "replay-log-creation-time", "replay-log-aged- > > time", or the most recent publisher boot time. > > > > NEW: > > > > As a result, when any configured subscription receivers become > > active, buffered event records will be sent immediately after the > > "subscription-started" notification. The leading event record > > sent will be the first event record subsequent to the latest of four > > different times: the "replay-log-creation-time", "replay-log-aged- > > time", the most recent publisher boot time, and the time of the > > last event record sent to the reciever, if any. > > The reason I didn't word it this way is if there are multiple events > with the same timestamp. How about the text below... > > NEW > > If the publisher knows the last event record sent to a receiver, and > the publisher has not rebooted, the next event record on the stream > which meets filtering criteria will be the leading event record sent. > Otherwise, the leading event record will be the first event record > meeting filtering criteria subsequent to the latest of three different > times: the "replay-log-creation-time", "replay-log-aged-time", or the > most recent publisher boot time. Ok. /martin > > > > I have also made a corresponding tweak to the YANG model. > > > > In the leaf "configured-replay"? I couldn't find this text. > > Not in the configured-replay leaf, that looks good to me. The first > time this object is configured, this is when replay starts. If it > turns out there are multiple subscription-started notifications due to > transport loss, the YANG model won't change. > > To find the updated text, look for: refine > "target/stream/replay-start-time" > > Eric > > [..] > > /martin >
- [Netconf] mbj's WGLC review of subscribed-notific… Martin Bjorklund
- Re: [Netconf] mbj's WGLC review of subscribed-not… Eric Voit (evoit)
- Re: [Netconf] mbj's WGLC review of subscribed-not… Martin Bjorklund
- Re: [Netconf] mbj's WGLC review of subscribed-not… Eric Voit (evoit)
- Re: [Netconf] mbj's WGLC review of subscribed-not… Andy Bierman
- Re: [Netconf] mbj's WGLC review of subscribed-not… Eric Voit (evoit)
- Re: [Netconf] mbj's WGLC review of subscribed-not… Martin Bjorklund
- Re: [Netconf] mbj's WGLC review of subscribed-not… Andy Bierman
- Re: [Netconf] mbj's WGLC review of subscribed-not… Martin Bjorklund
- Re: [Netconf] mbj's WGLC review of subscribed-not… Martin Bjorklund
- Re: [Netconf] mbj's WGLC review of subscribed-not… Eric Voit (evoit)
- Re: [Netconf] mbj's WGLC review of subscribed-not… Eric Voit (evoit)
- Re: [Netconf] mbj's WGLC review of subscribed-not… Martin Bjorklund
- Re: [Netconf] mbj's WGLC review of subscribed-not… Reshad Rahman (rrahman)
- Re: [Netconf] mbj's WGLC review of subscribed-not… Martin Bjorklund
- Re: [Netconf] mbj's WGLC review of subscribed-not… Eric Voit (evoit)
- Re: [Netconf] mbj's WGLC review of subscribed-not… Martin Bjorklund
- Re: [Netconf] mbj's WGLC review of subscribed-not… Eric Voit (evoit)
- Re: [Netconf] mbj's WGLC review of subscribed-not… Eric Voit (evoit)