Re: [netconf] YANG Push drafts comments

[William Lupton <[e-mail]>]

Thanks. No more questions or comments. Cheers, W.

On Fri, 1 Feb 2019 at 17:18, Eric Voit (evoit) <[e-mail]> wrote:

> 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]> wrote:
>
> Hi William,
>
>
>
> Thanks for the interest, thoughts in-line...
>
>
>
> *From:* netconf <[e-mail]> *On Behalf Of *William Lupton
> *Sent:* Tuesday, January 29, 2019 6:41 AM
> *To:* [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
>