Re: [Netconf] WG adoption poll draft-voit-netconf-notification-messages-01

[Alexander Clemm <[e-mail]>]

Hi Martin

Thank you for your response - replies inline, <ALEX>

--- Alex

-----Original Message-----
From: Martin Bjorklund [mailto:[e-mail]] 
Sent: Monday, August 28, 2017 1:26 AM
To: Alexander Clemm <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Netconf] WG adoption poll draft-voit-netconf-notification-messages-01

Hi,

Alexander Clemm <[e-mail]> wrote:
> Hi Martin, Eric, all,
> 
> First, I think we are all in agreement that we should define an update to RFC 7950.  This makes a lot of sense to me.  Good point also regarding extending that update to RFC 8040.  
> 
> It seems to me that in subscribed-notifications, we should indicate 
> what the instantiated notification header structure will look like, 
> but leave the actual update to RFC 7950 to a later draft.

See my email to Eric.  If this is not defined in subscribed-notifications, but in a separate document, I think this separate document needs to be referenced from subscribed-notifications.

<ALEX> So in this case we need to make sure this clear in subscribed notifications.  We cannot have to introduce and await an entirely new document, but we do need to progress yang-push.   We can apply the textual updates from there, and make the current text stronger (and clearer as needed).  
</ALEX>

> It seems
> to me that draft-voit-netconf-notification-messages is a good place to 
> put it, since this talks about the various notification and 
> notification bundle fields extensively.  Are YANG data extensions 
> needed for this per Martin's suggestion?  Possibly, although not sure 
> this is required - at least I am not convinced yet on that
> point: clearly, it will be good if we don't make the notification 
> record itself not just an anydata (as is the case now

Actually, today the "notification" message in RFC 5277 is defined in XSD, so it is even worse than anydata.

> - I agree this
> needs to be improved) and this provides a good option to do that.

Yes!

> At the same time, the YANG information this is nested in is not 
> "general" YANG information, but defines what will be used in the 
> header structure of the notification element,

Right, which is why rc:yang-data is the correct YANG statement for this - not "notification".

<ALEX> Reading through this module, I am actually not exactly sure if it is.  RFC 8040 states in very clear terms this module applies only to RESTCONF protocol messages.  We do not have this restricted context here.  From the specification it is also not clear (at least not to me) how this statement would be used even if the context were to be extended?   We _do_ want to specify data to be carried in the header structure of the notification element.  It would seem to me that we can specify the notification element in a corresponding subsection in the document and simply indicate the fields that can be included per a YANG data model we can define for this purpose that states very clear this is data not to be instantiated in a data store but for <notification> messages.  I don't think we would even need a YANG extension  for that.  
--- Alex

</ALEX>


/martin


> so it could be defined
> specifically for that purpose without redirecting to yet another 
> mechanism.
> 
> --- Alex
> 
> 
> -----Original Message-----
> From: Eric Voit (evoit) [mailto:[e-mail]]
> Sent: Friday, August 25, 2017 12:36 PM
> To: Martin Bjorklund <[e-mail]>
> Cc: Alexander Clemm <[e-mail]>; [e-mail]; 
> Andy Bierman ([e-mail]) <[e-mail]>; Kent Watsen 
> <[e-mail]>
> Subject: RE: [Netconf] WG adoption poll 
> draft-voit-netconf-notification-messages-01
> 
> Hi Martin,
> 
> Thanks for your thoughts.
> 
> We had two threads on notifications and draft structure issues in January.  
> (1) nested notifications
> (2) New Notification and Subscription Features WASFW: 3 Options for 
> Subscription & Event Notification draft structure
> 
> My read on the outcome was that that there was a desire have a specification which would be a standalone enhancement to RFC-7950.  But the document could be later incorporated into a YANG 1.2. 
> 
> One dialog between Kent & Andy also focused on the exact issue of this thread. See:
> https://mailarchive.ietf.org/arch/msg/netconf/NXK4eWlOE32vEn_7X0yHC_8u
> 4Mk
>  
> Andy has continued his thinking and as you point out has included some of his suggested concepts into draft-bierman-netmod-yang-data-ext-00.
> 
> Your very useful solution proposal below synchs nicely with that thinking.   And an integration of these proposals should be included within this draft.  My suggested next step is to collapse that work into the next version.
> 
> As a side note: we did consider including much of this within draft-ietf-netconf-subscribed-notifications.   But it was not necessary to delay that draft (which focuses on the control plane) with something that fixes gaps in yang 1.1 notifications & data plane.  So what we did in section 6 is to define the minimum information which must be transported in a data plane message, and provide two header objects which need to be included in an existing message which would then make the data plane compliant.  This is a minimal way to get people started, and can easily work with existing 5277 data plane parsing.  The rest of section 6 then points to this new work in preparation for the time yang notifications are updated (as per the thread above). 
> 
> Eric
> 
> > -----Original Message-----
> > From: Martin Bjorklund [mailto:[e-mail]]
> > Sent: Friday, August 25, 2017 3:12 AM
> > To: [e-mail]
> > Cc: Eric Voit (evoit) <[e-mail]>; [e-mail]
> > Subject: Re: [Netconf] WG adoption poll
> > draft-voit-netconf-notification-
> > messages-01
> > 
> > Hi,
> > 
> > Alexander Clemm <[e-mail]> wrote:
> > > Hi,
> > >
> > > Couple of thoughts inline, <ALEX>
> > >
> > > --- Alex
> > >
> > > -----Original Message-----
> > > From: Netconf [mailto:[e-mail]] On Behalf Of 
> > > Martin Bjorklund
> > > Sent: Thursday, August 24, 2017 11:44 AM
> > > To: [e-mail]
> > > Cc: [e-mail]
> > > Subject: Re: [Netconf] WG adoption poll
> > > draft-voit-netconf-notification-messages-01
> > >
> > > Eric,
> > >
> > > [warning: email quoting messed up below]
> > >
> > >
> > > "Eric Voit (evoit)" <[e-mail]> wrote:
> > > > From: Andy Bierman, August 24, 2017 12:05 PM
> > > >
> > > > On Thu, Aug 24, 2017 at 5:24 AM, Martin Bjorklund <mbj@tail-
> > f.com<mailto:[e-mail]>> wrote:
> > > > Hi,
> > > >
> > > > I support the problem statement in this draft, but I have 
> > > > concerns with the proposed solution.
> > > >
> > > > Currently, the notification message is defined in RFC 5277, for 
> > > > both NETCONF and RESTCONF.  It has a non-exensible header, and I 
> > > > agree that it would be good to fix that.
> > > >
> > > > We have a set of notfication-related documents that are supposed 
> > > > to replace RFC 5277, to make it more flexible.  I think that one 
> > > > of the documents in this set (not sure which one) needs to 
> > > > properly define a new notification message, and introduce an 
> > > > extensibility mechanism for the header.
> > > > <Eric> Draft-ietf-netconf-subscribed-notifications, section
> > 6<https://tools.ietf.org/html/draft-ietf-netconf-subscribed-notifica
> > ti
> > ons- 03#section-6> defines minimal object additions as well as 
> > backwards compliance with YANG 1.1 Notifications (RFC-7950 section 
> > 7.16.3)<https://tools.ietf.org/html/rfc7950#section-7.16.3> .
> > >
> > > Actually, you point to one of my main concerns with the set of 
> > > notification
> > drafts.  The section you refer *should* provide a clear 
> > specification for what the notification message is, and a clear 
> > specification of how the header can be extended.  But it doesn't; it 
> > talks about things that ought to go into a notification, and shows an example.
> > >
> > > I have similar concerns for how filters and streams are defined.
> > >
> > > > It is this backwards compliance part with existing YANG 
> > > > notifications which
> > is critical as we don’t want to require a new notification element 
> > for the existing event subscription work.
> > > > draft-voit-netconf-notification-messages is the first attempt at 
> > > > an
> > extensibility mechanism and format for a new notification message.   It is
> > because these extensible headers are not backwards compatible that a 
> > separate new draft is being proposed.
> > > > Then a followup document (like
> > > > draft-voit-netconf-notification-messages) can use this 
> > > > extensibility mechanism to define more common header fields.
> > > > <Eric> It seems that a small number of known headers would be 
> > > > useful to
> > put in the same draft as the extensibility mechanism.  We could 
> > break these into two drafts, but I think that would be more work for a reader.
> > >
> > > This is also fine with me.  Then I assume that this draft is not 
> > > really needed at
> > this time?
> > >
> > > <ALEX> What I am taking away from this is the request to make the 
> > > definition
> > of the <notification> message more formal, i.e. explicit.  Sure, 
> > let's look at what edits are required.  What I do not follow is the 
> > conclusion why the draft would not be needed?  Clearly, there are 
> > new elements being defined in draft-voit- 
> > netconf-notification-messages, including the option to bundle multiple notification records.
> > 
> > I read Eric's message above that he preferred to define small set of 
> > headers in the same doc as the extensibility mechanism itself, and 
> > that he didn't want two documents.  Personally I'm fine with two 
> > documents, as long as the base document with the extensibility mechanism is clear.
> > 
> > > </ALEX>
> > >
> > > And BTW, the mechanism that this draft "extends" the notification 
> > > header is
> > by defining a YANG notification.  This simply doesn't work of 
> > course, since we need to define how any YANG notification is encoded 
> > in this new notfication message that the base documents will define.
> > >
> > >
> > > <ALEX> I would consider the fact that we are using YANG a feature, 
> > > not a bug.
> > 
> > If you misuse a well-defined construct (YANG's notification 
> > statement), how can that be a feature?
> > 
> > > Now, it is true that really we are dealing with two tiers of 
> > > information - the
> > notification record itself, and the construct that it is contained / 
> > encapsulated in (the bundle/housekeeping stuff).  And yes, an 
> > independently defined notification should be transported 
> > "encapsulated" within the new header we are defining, not separately from it.
> > >
> > > Really what we should be doing is update RFC 7950.  I think I 
> > > vaguely
> > remember an earlier discussion thread that stated we could state in 
> > a new RFC
> > "Updates: RFC 7950", with text that explains how YANG-defined 
> > notifications are encoded.  This is probably what we need to do here.
> > 
> > Agreed.  BUT, it needs to be done properly.  Here's a quick sketch 
> > of a solution
> > proposal:
> > 
> > In the base document, define the new message layout / the 
> > encapsulation of notifications.  This needs to be in a new XML 
> > namespace in order to differentiate from RFC 5277.  Use yang-data for this purpose:
> > 
> >   module ietf-yang-notification-message {
> >     namespace "urn:ietf:params:xml:ns:netconf:notification:2.0";
> >               // or maybe even a new namespace w/o 'netconf' in it
> >     prefix ynm;
> > 
> >     import ietf-restconf {
> >       prefix rc;
> >     }
> > 
> >     rc:yang-data notification {
> >       container header {
> >         leaf event-time { ... }
> >         leaf another-common-leaf { ... }
> >       }
> >       // notification content goes here, or possibly:
> >       //  container data { // ... here }
> >     }
> >   }
> > 
> > The base document should update RFC 7950 and state that all YANG 
> > defined notifications are encapsulated in this new structure, 
> > regardless of protocol.  It also needs to update RFC 8040 which currently says that RFC 5277 is used.
> > 
> > 
> > To extend this, use Andy's proposed yang-data-augment, and make use 
> > of features and modules to avoid the kitchen-sink syndrome:
> > 
> >   module notifi-header-extensions-for-foobar {
> >     ...
> >     import ietf-yang-notification-message {
> >       prefix ynm;
> >     }
> >     import yang-data-ext {
> >       prefix ydx;
> >     }
> > 
> >     feature foobar-extra { ... }
> > 
> >     ydx:augment-yang-data /ynm:notification/ynm:header {
> >       leaf foobar-id { ...}
> >       leaf foobar-extra {
> >         if-feature foobar-extra;
> >         ...
> >       }
> >       ...
> >     }
> >   }
> > 
> > Details about bundling messages TDB in the base spec.
> > 
> > 
> > /martin
> > 
> > 
> > 
> > 
> > 
> > >
> > > </ALEX>
> > >
> > >
> > > > On another level, I'm also worried that this becomes a 
> > > > kitchen-sink of various headers that may or may not useful.  I 
> > > > would prefer an initially small set of well thought-through 
> > > > headers, and work from there.
> > > > <Eric> When developing v01, it seemed to me more useful to 
> > > > include
> > potential header objects which could later be removed.  The real intention in
> > their inclusion is to spur others’ thinking.   I have zero issue in dropping or
> > morphing proposed headers during draft development.     (Note that it was
> > entries like observation-domain-id which allowed Benoit to make a 
> > 1:1 conceptual mapping with corresponding concepts in IPFIX at IETF 
> > 98.)
> > > >
> > > > I would like to see these concerns addressed before the WG 
> > > > adopts this document.
> > > >
> > > > I agree these issues need to be addressed.
> > > >
> > > > <Eric> Hopefully the thoughts above sufficient for now.   Any alternative
> > approaches/proposals would be great to hear.
> > >
> > > My proposal would be to make sure the base is solid before adding
> > extensions.
> > >
> > >
> > > /martin
> > >
> > >
> > >
> > > >
> > > > Many other protocols have these properties:
> > > >   1) ability to add headers over time in separate RFCs
> > > >   2) ability to identify mandatory vs. optional property (even 
> > > > if nothing else
> > understood)
> > > >   3) ability to skip over unknown optional headers
> > > >
> > > > <Eric> These three are viable in the current draft.
> > > >
> > > > Eric
> > > >
> > > >
> > > > /martin
> > > >
> > > > Andy
> > > >
> > > >
> > > > Kent Watsen <[e-mail]<mailto:[e-mail]>> wrote:
> > > > >
> > > > > All,
> > > > >
> > > > > This is start of a two-week poll on making the following draft 
> > > > > a NETCONF working group document:
> > > > >
> > > > >   draft-voit-netconf-notification-messages-01 [1]
> > > > >
> > > > > Please send email to the list indicating "yes/support" or 
> > > > > "no/do not support".  If indicating no, please state your 
> > > > > reservations with the document.  If yes, please also feel free 
> > > > > to provide comments you'd like to see addressed once the 
> > > > > document is a WG
> > document.
> > > > >
> > > > >
> > > > > [1]
> > > > > https://tools.ietf.org/id/draft-voit-netconf-notification-mess
> > > > > ag
> > > > > es
> > > > > -0
> > > > > 1
> > > > >
> > > > >
> > > > > Thank you,
> > > > > Kent (and Mahesh)
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > _______________________________________________
> > > > > Netconf mailing list
> > > > > [e-mail]<mailto:[e-mail]>
> > > > > https://www.ietf.org/mailman/listinfo/netconf
> > > > >
> > > >
> > > > _______________________________________________
> > > > Netconf mailing list
> > > > [e-mail]<mailto:[e-mail]>
> > > > https://www.ietf.org/mailman/listinfo/netconf
> > > >
> > > <
> > > _______________________________________________
> > > Netconf mailing list
> > > [e-mail]
> > > https://www.ietf.org/mailman/listinfo/netconf