Re: [Netconf] comments on draft-ietf-netconf-subscribed-notifications-12

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

> From: Martin Bjorklund, June 14, 2018 4:22 AM
> 
> Hi,
> 
> Juergen Schoenwaelder <[e-mail]> wrote:
> > On Wed, Jun 13, 2018 at 03:36:01PM +0000, Eric Voit (evoit) wrote:
> > > Each of the terms used are different.  While they all are defined in the first
> document they are used, let me paraphrase the meanings of the definitions...
> > >
> > > Event - something that happened
> > >
> > > Event record - the recorded details of a single event
> > >
> > > Update record - one or more datastore node updates
> > >
> > > <notification> - a structure defined in RFC5277 which is as a wrapper which
> contains an event record.  A <notification> can exist without any active
> subscription.
> > >
> > > "notification" statement - a structure defined in RFC-7950 section 7.16
> which allows the definition of event record types specific to a YANG module.
> The results of the a YANG "notification" statement are encoded in a
> <notification>.
> >
> > Here is where I am getting lost. The RFC 7950 notification statement
> > (its not a structure btw) does define the content of a notification.
> > And notification used to be defined in RFC 6241 as a "server-initiated
> > message indicating that a certain event has been recognized by the
> > server." Your notion of an event record may come from the RFC 5277
> > format that adds an eventTime etc. but the relationship of what is a
> > YANG defined notification and how it related to your event record and
> > the <notification> structure is still unclear.
> 
> I don't think we should align terminology with 5277.  More important is to
> align with the current set of documents; 7950 and 6241.

Exactly.  

Note that there was no terms imported from 5277.  Subscribed-notifications does define an umbrella term "notification message", and uses Section 2.6 to make the minimal connection necessary to show that an RFC-5277  <notification> is a valid "notification message".  BTW: We had text in earlier versions of subscribed-notifications stating the need to support future types of "notification messages" such as those defined in draft-ietf-netconf-notification-messages.  However reviewers asked these evolving references to be removed.

We do have the option of importing terms from 6241 into the NETCONF-notif document.  This would be the right place to do it because in the subscribed-notifications document we want to limit any introduction of NETCONF dependencies.   (Maybe NETCONF-notif adds text to say that a "RFC6241 client" maps to subscriber, and "RFC6241 server" maps to publisher?)

> If subscribed-notifications is transport-independent, it should probably not talk
> too much about <notifcation> etc; this should go into the transport docs.

In general, this is what is done.  In subscribed-notifications, the only place <notification> is mentioned at all is section 2.6.    If necessary, we could move this section to NETCONF-notif, but that would leave no transport independent framing for the notifications.  I guess it is possible to live without that, but it would leave the subscribed-notifications feeling incomplete.  I suspect a similar thought process drove the inclusion of <notification> within RFC-6020 and then RFC-7950.
 
> 7950 says that the "notification" statement defines a notification.
> As Juergen pointed out this term is not defined in the terminology section, but
> nevertheless the term is used.
>
> Does the WG now want to introduce a new term for what the "notification"
> statement defines?

It certainly might make sense to have a future update of RFC-7950 with something like this.    I spend a bit of time trying to understand the connection of YANG notification statement with <notification>.  Having this be better defined would be helpful.

>  It seems to me that the term "event record" is being
> proposed for this.

An event record is not necessarily a YANG notification, as the event record's payload might not be driven by the result of a YANG statement.

> The answer to this question will have a big impact on the
> rest of the terminology.

As event record has a larger scope than what can come from a YANG notification statement, my suggestion would be for the revision of RFC-7950 to import "event record", and then specify a new subtype term (maybe "YANG event record"?).  If that term works, a YANG event record could then be an event record where the contents are populated by the results of the YANG notification statement.

> > > Notification message - a message intended for a specific subscription
> receiver which includes one or more <notification>. A notification message will
> have undergone any security/content filtering on embedded <notification> as
> appropriate for that receiver.
> >
> > So how does this fit Figure 1 of RFC 6241? This figure indicates that
> > <notification> is a message as seen from the messages layer. You are
> > saying a notification message is something else that includes one or
> > more <notification>s. Yes, I know that the diagram in RFC 5277 is
> > different but the diagram in RFC 6241 is the newer one.
> 
> This confuses me as well.

The requirement for the bundling of many events is being driven by large data center telemetry.  It is unclear at this point whether NETCONF will be a transport used in this environment.

If NETCONF does care about this environment, and does want to support something like draft-ietf-netconf-notification-messages, I do think tweaks to RFC-6241 will be needed.  For example what is the definition of <notification> within 6241, Figure 1 (right now point RFC-5277 isn't explicitly mentioned.).   Must this figure only be interpreted as a RFC 5277 <notification>?  Can the figure also mean a draft-ietf-netconf-notification-messages "message"?

> How much of this do we have to define in this document, and how much
> should go into the transport docs?

Beyond what I describe above, impacts would be to new/updated transport drafts.   Plus an update to subscribed-notifications section 2.6 to indicate that a new transport independent <notification> construct exists.

Eric

> /martin
> 
> 
> > > Per the discussion below, I see an update record being a specialized type of
> event record.  For YANG push, the 'event' is driven by the update trigger: i.e.,
> either the expiration of a periodic timer (for periodic subscriptions), or a
> change to the datastore (on-change subscription).
> > >
> >
> > I am missing a definition what an Update record is. It is surely not
> > in this email. Anyway, if there are changes to architectural concepts,
> > it would be nice to find them in a coherent well explained section.
> >
> > /js
> >
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: [phone]         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   [phone]         <https://www.jacobs-university.de/>
> >