Re: [Netconf] LC on subscribed-notifications-10

"Eric Voit (evoit)" <> Fri, 06 July 2018 23:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D1217124D68 for <>; Fri, 6 Jul 2018 16:13:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Status: No, score=-14.51 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_DKIMWL_WL_MED=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pLha36q-n8tO for <>; Fri, 6 Jul 2018 16:13:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 58FEA13108B for <>; Fri, 6 Jul 2018 16:13:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=6540; q=dns/txt; s=iport; t=1530918829; x=1532128429; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=5IMU+0z0fsb2pTqF9oqiftCIfNGkj/hI1xBSSyvWZek=; b=i8uTELElzD6oA0UaTF+fvdizhdFegRLzuD642dCbTeeOwfelDT3n0SzM 91f58Uje1e25BMzTy+j9hA701fc+2sMshB3H4LL0UhloPkXXtLSV1BQDF 9DKt2HW1Pk2jF5J6U4a0xf0wNSUHIyl8r0pffxzS79jVLnO4U+0fqJqBx Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CPCgBN9z9b/5NdJa1bGgEBAQEBAgE?= =?us-ascii?q?BAQEIAQEBAYMfKmJ/KAqDcJQ5ggeDOJF6FIFmCyWERwIXghYhNhYBAgEBAgE?= =?us-ascii?q?BAm0cDIU2AQEBAgEBIwQNQwIFCwIBCA4HBQIJHQICAjAVEAIEDg2CTUyBdwg?= =?us-ascii?q?PqVGBaTOIS4E1BYELh2KBVj+EHoMYAgGBKwEBEgFZgkeCVQKZTwkChgaJFIF?= =?us-ascii?q?JhAyIDIo1hy8CERMBgSQkBSxhcXAVO4JpgiQXg0WKUm+MXIEfgRoBAQ?=
X-IronPort-AV: E=Sophos;i="5.51,318,1526342400"; d="scan'208";a="418288596"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jul 2018 23:13:46 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id w66NDkLj010731 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 6 Jul 2018 23:13:46 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 6 Jul 2018 19:13:45 -0400
Received: from ([]) by ([]) with mapi id 15.00.1320.000; Fri, 6 Jul 2018 19:13:45 -0400
From: "Eric Voit (evoit)" <>
To: Kent Watsen <>
CC: "" <>, Alexander Clemm <>
Thread-Topic: [Netconf] LC on subscribed-notifications-10
Date: Fri, 6 Jul 2018 23:13:45 +0000
Message-ID: <>
References: <> <> <040a01d3be9f$09700490$1c500db0$> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [Netconf] LC on subscribed-notifications-10
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Network Configuration WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 06 Jul 2018 23:13:52 -0000

> From: Kent Watsen, July 6, 2018 5:05 PM
> <Kent14>
> <Eric13> Per this thread, this is now a configured-replay empty object (rather
> than a start-time).  This empty object simply tells the publisher to push off all
> events retained from a stream since reboot.  And yes, all configured
> subscriptions will restart simultaneously.  But without this feature, receivers
> will not see events from boot to transport establishment.  And without this
> feature, two different configured receivers might get different initial events as
> the transport might not be brought up simultaneously.
> <Kent13> I'm unsure how this addresses my concern that replaying is
> unnecessary for configured subscriptions…I somehow thought that it might be
> related since it's listed here.   Separately, I'm unclear about what this change
> does, I know you provide some explanation above, but you can say it
> differently or provide an example or two to illustrate what you mean?   Does
> this change introduce the problem you mentioned before about duplicates
> events being sent?
> <Eric14>  Here is a link to the slides which I have put together for IETF 102
> which hopefully hits your request above:
> replay-slides-ietf102.pdf
> <Kent14> not really.  The switch to "configured-replay" seems orthogonal,
> likely due to it being perceived as easier than specifying an exact time.

<Eric15> It is a flag.   It just means that the replay starts with the earliest event after reboot.

> Separately, as a comment on the slides, perhaps list both Pros and Cons?  

I put PRO and CON on slide 2 of: 
If you disagree with any bullet, let me know.

> I provided 4 perceived benefits in a recent email…

<Eric15>  Pulling the four items which I believe you are referring to:

Kent #1: it is already a SHOULD for the receiver to do a dynamic fetch for already started subscriptions (see quoted paragraph above), so having another SHOULD for newly started configured subscription doesn't threaten of a-d any more than already, 
Eric response #1: Please reread the provided slide.  I tried to reframe (a)-(d) and provide a summary all the other points from our long thread.  For example, asserting that the two SHOULDs can be safely coupled is incorrect.  Per my Option 2, bullet 4, sub-bullet 2, can be are cases where dynamic subscriptions are not needed on the receiver.  

Kent #2: it seems really weird to have persistent configuration that only gets used once in the lifetime of a configured subscription
Eric response #2: This is not a benefit.   Beyond that, a flag that say when to begin is not a bad thing.  And there is plenty of configuration which is used only once. E.g., stop-time, synch-on-start.

(Kent #3) it is good to remove frivolous features
Eric response #3a:  It is optional to implement.  If someone doesn't want to implement it, they don't have to.  
Eric response #3b:  This is not frivolous.  In fact my personal preference would be to have the start time for a configured subscription be at the known/consistent/anchored boot time.  The default right now is that the start time varies based on the point of first transport establishment -> and this will vary by receiver.  Which means independent receivers of a single subscription may have a different first event.   Sadly this default cannot be change to my preference because replay is an optional feature.   
Eric response #3c: As security people want this behavior, they will be forced to attempt Option 2 should Option 1 not exist.  Which has all the CON drawbacks described on the slide.  

(Kent #4) the current text in draft is confusing about replay-start-time.  
Eric response #4:  This is not a benefit.  And the text has been updated.

> BTW, the description statement on replay-start-time seems incorrect, with the
> node now being config false, how can it be used to "trigger" anything?
> <Eric14>  replay-start-time exists as part of the establish-subscription RPC.   The
> RPC is where the triggering occurs.
> <Kent14> right, and that's fine, but it's not okay for configured subscriptions.
> Subscription-policy uses subscription-policy-dynamic, the description needs to
> be refined, like it was for the subscription-started notification.

<Eric 15> Replay-start-time is config false.  Therefore it will not appear populated for a configured subscription in the data nodes.  (Note: What I did do is delete 'replay-start-time' from the refined definition, as that option no longer exists.)


> Kent // contributer