[Netconf] question about "event drafts"

[Martin Bjorklund <[e-mail]>]

Hi,

I just watched the recorded NETCONF session from IETF 96, and read
the minutes.  In the minutes I read that four new drafts related to
event notifications are supposed to be adopted, after validation on
the ML.  I haven't seen any email about this adoption, and I don't
understand which four drafts you referred to.  I can guess that three
of them are:

  draft-gonzalez-netconf-event-notifications-00
  draft-gonzalez-netconf-5277bis-02
  draft-voit-netconf-restconf-notif-00

I don't think that these documents are ready for adoption.  It is not
clear to me how they are supposed to work.  First of all, we have the
5277bis document, which apparently doesn't obsolete 5277.  However,
the event-notifications draft says that it obsoletes 5277.  Also,
there is still quite some overlap between the documents.

For example, 5277bis says:

   This document defines mechanisms that provide an asynchronous message
   notification delivery service for the NETCONF protocol .  This is an
   optional capability built on top of the base NETCONF definition.

And draft-gonzalez-netconf-event-notifications says:

   This document defines the support of [event-notifications] by the
   Network Configuration protocol (NETCONF).

So it seems both drafts define how notifications are sent over
NETCONF.

Further, the intent of draft-voit-netconf-restconf-notif-00 is not
clear.  RESTCONF already supports notifications, and this new draft
has:

  3.1.1.  Dynamic YANG Subscription over RESTCONF

     Dynamic Subscriptions are configured and manage Subscriptions via
     signaling.  This signaling is transported over [restconf].  Once
     established, streaming Event Notifications are then delivered via
     Restconf SSE.

I don't understand what this means.


I think that this confusion is basically just the result of some
reshuffling of contents, and that's fine.  But I think that the intent
of each individual draft must be more clear, and that the text in the
drafts actually reflects this.


/martin