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

[Kent Watsen <[e-mail]>]

Please look for <Kent12> below.



 <Kent6> okay, I think I got it this time.  Having a *configurable* replay-start-time is so confusing.  Is it really worth having?



<Eric7>   Yes it is worth having.

(a) In many environments, reboot is very infrequent.  Without configurable start time, an operator setting up a configured subscription would not have the ability to designate what to send.  It could only send the full log (at whatever size).

(b) on-publisher security or troubleshooting diagnostics might identify a breach or some event where streaming recent historical event records is a MUST.  As a result, it might want to stream a subset of event records off a box going back in time to potential events which might have been evidence or contributing factors.



<Kent7> Let me come at this another way.  Assume we drop all support for *configurable* replay-start-time.  As such, configured subscriptions always start with the next-generated event (no replay at all).   This covers most use-cases, right?   For those receivers that really wanted the older logs, can't they just do a dynamic subscription to collect them, same as we've been discussing above?



<Eric8> Some reasons this might not always be practical:

(a) IoT devices just might want to passively listen to event streams of Telemetry.  (I.e., this would force configured receivers to support dynamic subscriptions.)

(b) This forces complexity onto applications which only ever need to track what has happened since boot.  (E.g., per above, continuous Integrity Measurement Architecture (IMA) boot log streaming and evaluation.)

(c) Publisher access permissions for who can use the establish-subscription RPC might have to be expanded to include lots of configured receivers.  This might open up a vector to control plane DDoS.  Right now the access permissions would just have to allow the receiver read access to the event records.

(d) A publisher may choose to firewall classes of receivers (or locations of receivers) into a listen-only mode without the ability to establish subscriptions.



<Kent8> This response seems to address the "can't they just do a dynamic subscription" aspect of my comment, but doesn't really address the "why is it important" (I paraphrase) part.  My contention is that the concept of a *configurable* replay-start-time seems confusing and of low value.   I acknowledge that there is some value, but it seems like the value is limited to a one-time start-up optimization that can be alternatively addressed by a dynamic subscription to fetch earlier events (assuming it's allowed, per your points b-d).   Additionally, FWIW, I've never seen such a feature implemented before, and logging mechanisms have been around for decades, so this makes me think that this is something that probably isn't worth having.



<Eric9> As you point out, the why "can't they just do a dynamic subscription" is covered, and we shouldn’t always assume away (b)-(d) as they can matter in some scenarios.  So if we want to support the use case of streaming log entries made after boot, but before the transport session is available, the only alternative I see is to have a configured replay-flag rather than a configuring a start-time.  Are you ok with a flag instead?  Or do you have an alternative suggestion?



<Kent9> see below.



In terms of using this configured replay capability, Cisco’s Integrity Verification application

https://www.cisco.com/c/dam/en/us/td/docs/cloud-systems-management/application-policy-infrastructure-controller-enterprise-module/1-5-x/integrity_verification/user-guide/Cisco_Integrity_Verification_Application_APIC-EM_User_Guide_1_5_0_x.pdf<https://urldefense.proofpoint.com/v2/url?u=https-3A__www.cisco.com_c_dam_en_us_td_docs_cloud-2Dsystems-2Dmanagement_application-2Dpolicy-2Dinfrastructure-2Dcontroller-2Denterprise-2Dmodule_1-2D5-2Dx_integrity-5Fverification_user-2Dguide_Cisco-5FIntegrity-5FVerification-5FApplication-5FAPIC-2DEM-5FUser-5FGuide-5F1-5F5-5F0-5Fx.pdf&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=YLzifR1978kb_hHj64ZtYbrlHE2fJaofeSKu9OAFQXg&s=Vc8m5WAJJE8YkQIpZuxlnVTgAtVKQZ-n0dyoRKX3Eao&e=>

does do a shell access event log fetch of the full log after boot, and then just does incremental fetch the deltas of the log (based on log line numbers).  This application is interested in configured subscriptions subsequent to boot for this purpose.  So such incremental streaming of portions of syslog after boot seems like a typical/common need to me.



<Kent9> it might be typical/common desire, but it's still once in the lifetime of the configured subscription.  It seems like, if the device supports dynamic subscriptions, after receiving subscription-started, the client could a) pause the configured subscription, b) use a dynamic subscript to fetch the missing logs, and then c) resume the flow of logs from the configured subscriptions.



<Eric10> Your proposal still precludes (b)-(d) above.   In addition for your step a), there is no RPC or action which allows the event records from a configured (or dynamic) subscription to be paused.  The solution also adds complexity into the client to recognize that early events might be missing, to issue an establish-subscription, and then to tie the results of the independent subscriptions together.



<Kent10> pausing can be implemented by the receiver not reading any more from the TCP socket, or something else.



<Eric11> There is no mechanism for a receiver to pause a single subscription without pausing other subscriptions on the TCP session (as subscriptions typically would share a common TCP.)



<Kent11> Different "receivers" of different configured subscriptions pointing to the same underlying netconf or restconf call-home connection?



<Eric12> Yes



<Kent12> Ack.  So, *if* we were to do this, the client would either have to pause all the subscriptions, or do a dynamic fetch in parallel.  Hmmm, given that we're talking about the *configured* replay-start-time, which kicks in after a reboot, all the subscriptions would be restarted simultaneously (right?), so maybe this isn't a big issue?









How is it any more complex for the client/receiver than the following in the SN draft already?



   When a receiver of a configured subscription gets a new

   "subscription-started" message for a known subscription where it is

   already consuming events, the receiver SHOULD retrieve any event

   records generated since the last event record was received.  This can

   be accomplish by establishing a separate dynamic replay subscription

   with the same filtering criteria with the publisher", assuming the

   publisher supports the "replay" feature.



<Eric11> It is the same general process.  But it turns the SHOULD into a MUST for applications which need to know the events since boot.  It also doesn’t deliver the events in order to the application, delaying application event analysis.



<Kent11> here's another question that might be good to raise to the WG level.   Please be sure to capture my general concern and also the availability of this workaround.  Thanks.



<Eric12>  You are welcome to take the question to the WG level.  I have no desire to waste people’s time with such an obvious question:

- The current solution does not add the extra complexity described above for configured subscription replay.

- The current solution supports deployment scenarios (b)-(d) above.

- The current solution has far less implementation complexity and error reconciliation states for the client.



<Kent12> No Eric, you are the Editor.  We can take this to Montreal if you prefer.   We need more opinions to break the standoff, and I don't think folks are watching this thread.  Please try to present the tradeoffs in a fair manner.   BTW, a==b and c==d, AFAICT.  a/b seems true and c/d also seems true, but 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, 2) it seems really weird to have persistent configuration that only gets used once in the lifetime of a configured subscription, 3) it is good to remove frivolous features, and 4) the current text in draft is confusing about replay-start-time.   #4 is what started this fork in the thread, but rather than fix the text, I'm thinking it might be better to remove the feature.





Kent  // contributor