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

[Martin Bjorklund <[e-mail]>]

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 <[e-mail]<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-notifications-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-messages-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