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

"Eric Voit (evoit)" <evoit@cisco.com> Fri, 06 July 2018 23:13 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 D1217124D68 for <netconf@ietfa.amsl.com>; Fri, 6 Jul 2018 16:13:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level:
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: 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 pLha36q-n8tO for <netconf@ietfa.amsl.com>; Fri, 6 Jul 2018 16:13:49 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 58FEA13108B for <netconf@ietf.org>; Fri, 6 Jul 2018 16:13:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; 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 rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Jul 2018 23:13:46 +0000
Received: from XCH-RTP-014.cisco.com (xch-rtp-014.cisco.com [64.101.220.154]) by rcdn-core-11.cisco.com (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 xch-rtp-013.cisco.com (64.101.220.153) by XCH-RTP-014.cisco.com (64.101.220.154) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Fri, 6 Jul 2018 19:13:45 -0400
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.1320.000; Fri, 6 Jul 2018 19:13:45 -0400
From: "Eric Voit (evoit)" <evoit@cisco.com>
To: Kent Watsen <kwatsen@juniper.net>
CC: "netconf@ietf.org" <netconf@ietf.org>, Alexander Clemm <ludwig@clemm.org>
Thread-Topic: [Netconf] LC on subscribed-notifications-10
Thread-Index: AQHTvAAnP4UPxNeFY0CSJ8tCCoPN1aPROUcQgATP1QCAHwQrAIADjkNQgA1teoD//750sIAJjRkA///cqgCAA11fAIAAqbKwgBOiSQCAARvxAIAIk/4AgACP9NCADaFDgIAAiRzAgAubxgD///ywEAJlO7OAACjJQxABysFmgAAIUZsAAI1lOQAABkzf0ACFw/GAAP59NtAAcDoxgAAGk67AACkcZQAABsxqIA==
Date: Fri, 6 Jul 2018 23:13:45 +0000
Message-ID: <a14c995871794434802ee614bc10e8da@XCH-RTP-013.cisco.com>
References: <17B884BF-0BB8-4B7C-BFBB-0AAFBEA857F6@juniper.net> <aedeb7390d0b4faa9f2bf12c2fe45cd2@XCH-RTP-013.cisco.com> <040a01d3be9f$09700490$1c500db0$@clemm.org> <2089023D-DA09-48E9-8F37-8FE459DC4F49@juniper.net> <dfc78f2b1062498388824b1f6dd97ff6@XCH-RTP-013.cisco.com> <1EC2E732-C524-4552-A3AD-27507239F763@juniper.net> <2b788c22f7ee4af889813b805348d69a@XCH-RTP-013.cisco.com> <9E7F3A66-98B9-4528-882C-43AAD19F0AEC@juniper.net> <96615f0331cd455182901ddf3e6ece23@XCH-RTP-013.cisco.com> <7F8F2AF4-28A5-4016-B727-10CAF6A093AF@juniper.net> <87fbe3cb907a473f816295c4545bd7fa@XCH-RTP-013.cisco.com> <CEE5B81C-31AE-40C6-B2F0-23D93C644D85@juniper.net> <fd172bddff134db6aeda49b7e8bfd3e9@XCH-RTP-013.cisco.com> <B112DC20-D6FC-44BA-AACE-0E641D49C5C3@juniper.net> <3b4744f4e2144ee18b9bfd5225360bf4@XCH-RTP-013.cisco.com> <01486F5E-CEE3-4BDD-9CD2-CA2754981000@juniper.net> <e414fe96c38f4aeba97dd56592748a23@XCH-RTP-013.cisco.com> <49943A03-D229-4084-9947-3065CE58A672@juniper.net> <a18cacd026e046b0a0c08f7a3fc969d2@XCH-RTP-013.cisco.com> <470391DD-9A9E-47EC-9CEC-E8E6BABE3DDF@juniper.net> <b94935c9fbbb4ced8b7393ea42457471@XCH-RTP-013.cisco.com> <38DB151D-81C9-49E4-B6A3-73D083298C53@juniper.net> <fd74cc7419894fec87f5af3e7dc688bd@XCH-RTP-013.cisco.com> <230D4B7A-42E6-4A9E-909B-BE91EE5D2FF3@juniper.net> <bc1b705b88f04d368334b78fbe91b7dd@XCH-RTP-013.cisco.com> <4146A91F-42E3-4C81-A414-C27920CA30C0@juniper.net> <9721a7a06f9543a1b510988b087da6b3@XCH-RTP-013.cisco.com> <BB246B62-0A79-4FAD-9C23-B5EC40AE394D@juniper.net> <a7d654fc37284449ba8c1306a9ce3146@XCH-RTP-013.cisco.com> <1D57D1E2-EC43-4512-BCBA-40F067AB537F@juniper.net>
In-Reply-To: <1D57D1E2-EC43-4512-BCBA-40F067AB537F@juniper.net>
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.228]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/netconf/edmOSyoQVBdsbH39j9-0j_JZZWk>
Subject: Re: [Netconf] LC on subscribed-notifications-10
X-BeenThere: netconf@ietf.org
X-Mailman-Version: 2.1.26
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: 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:
> 
> https://github.com/netconf-wg/rfc5277bis/blob/master/draft-configured-
> 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:
https://github.com/netconf-wg/rfc5277bis/blob/master/draft-configured-replay-slides-ietf102.pdf 
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.)

Eric

> Kent // contributer