Re: [netconf] YANG Push drafts comments

["Eric Voit (evoit)" <[e-mail]>]

Thanks William.   And some more thoughts back to you (and one to Alex)...

From: William Lupton, January 30, 2019 4:54 AM

Thanks Eric. Please see some follow-ups below (I've removed items where I have no further comment). Cheers, W.

On Tue, 29 Jan 2019 at 20:31, Eric Voit (evoit) <[e-mail]<mailto:[e-mail]>> wrote:
Hi William,

Thanks for the interest, thoughts in-line...

From: netconf <[e-mail]<mailto:[e-mail]>> On Behalf Of William Lupton
Sent: Tuesday, January 29, 2019 6:41 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [netconf] YANG Push drafts comments

1.      General:
1.      Why is the subscription id optional? Without it, will the receiver always be able to tell how to handle an event message?
I assume you are referring to the pushed notification messages carrying event records.  The RFC-5277 one way notification doesn’t support a subscription-id object in its current event schema, so we can’t embed this object for subscribed-notifications.  This is one reason that draft-ietf-netconf-notification-messages was adopted.  For YANG push, we do have a subscription-id in the notification definition, which is then carried within the RFC-5277 one-way notification.

I would expect this question to arise in the minds of many readers. A note might be useful?

<Eric>   Notes on this topic were included in earlier versions of the document (e.g., version 10).   However other reviewers asked to remove these notes as they weren’t explicitly needed for this specification.    In the end, the work on draft-ietf-netconf-notification-messages will restart after we get done these drafts, and hopefully will drive text back to this document to cover this concern.

2.      draft-ietf-netconf-subscribed-notifications:

3.      Event record:
1.      So does the "event record" term apply to all the drafts? If so, does "event" apply to all the drafts? (This note is in the context of a later note about the fact that "event stream" appears to be specific to this draft.)
Subscribing to an event stream is different than a subscribing to a datastore. [...]

This was a terminology comment. I felt that it wasn't always clear which terms were generic and would apply to all drafts. "event record", "event" and "event stream" caused me particular problems. It was just a comment... if people don't think there's a need for clarification (or greater rigor in the use of terms) then that's fine.

<Eric>  The original “event” came from RFC-5277.   But RFC-5277 didn’t have a separate term for the entity against which filter was applied (i.e., an event record).  We also needed to tweak the definition of “event stream” from the original RFC-5277 “stream”.  This was needed because the original definition was NETCONF specific.

With that as a starting point, we then had terminology established where any event could be documented via an event record, and placed on an event stream.  This includes a populating an event stream with the set of notifications coming from a separate YANG push subscription.  Event records generated this way would look 100% identical what would come from original YANG Push subscription.  This was not accidental.  And as a result it becomes possible for a publisher implementation to internally populate an event stream through the under-the-covers use of YANG push software.

Based on this, the terminology was constructed not to exclude the possibility that a push update could be an event record.   But it was felt these were internal publisher complexities on corner cases.  And getting to these details might confuse the casual reader.   So as a result, we simply avoided the use of ‘event records’  within YANG Push.  I guess this is a long way of saying that I hope the current text is sufficient.

4.      Event stream:
1.      Having now read most of the YANG Push draft, I realize that "Event streams" are a legacy thing and are not used by YANG Push. This could be made clear. Otherwise it looks like these are a base concept that will be built on.
I think event streams are useful.  I don’t consider them legacy.

I didn't mean "legacy" pejoratively. Reading the draft I was thinking "Ah, event streams are a core concept that will be leveraged by the other drafts". So I was surprised to discover that YANG Push doesn't use them. Assuming that I'm correct here, I think that a note (either here or in YANG Push) could be helpful.

<Eric> If we do this, the right place would be YANG Push.  I will leave the call on this to Alex. (cc’ed)

3.      So referring to them as sets of Events (rather than sets of Event streams) seems inaccurate.
I don’t see any text on either sets of events, or sets of event streams.

Sorry, part of this got lost in translation. I intended to refer to the fact that:

  *   Event stream is defined (1.2) as "A continuous, chronologically ordered set of events..."
  *   And then later (2.1) it seems to be suggested that an event stream is a set of event records (rather than a set of events)
(But re-reading it just now, I'm not sure whether it really says this! I also note that you commented on this point later. So we can drop this one.)

5.      Notification message:
1.      I don't find "The time the event was generated by the event source" quite clear. Is it the time at which the change occurred or was detected (event occurrence time), or the time at which the message was created? Probably the former?
I can’t find the exact text quote:  "The time the event was generated by the event source" .   Where is this?

Sorry. The actual text is from RFC 5277, describing eventTime. Obviously I'm not suggesting that RFC 5277 be changed!

<Eric>  Yes, I never did like that text from RFC-5277.   I checked into why RFC-5277 was written this way several years a while ago.   Basically different implementations handled this in different ways, and they wanted text which wouldn’t preclude different implementations.

Eric