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

Hi,

My read from this document is to specify the *transport independent* capabilities for notification messages.
So I think this draft should consider more transports/situation and include information elements that might be useful for certain transport, as many as possible. I.e., the maximum set instead of minimum set, IMHO.
When coming to one specific protocol, e.g., NETCONF/RESTCONF, the message header should only contain the specific well selected parameters, as well as the specific encoding.

Tianran

> -----Original Message-----
> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin
> Bjorklund
> Sent: Friday, August 25, 2017 2:44 AM
> To: evoit@cisco.com
> Cc: netconf@ietf.org
> Subject: Re: [Netconf] WG adoption poll
> draft-voit-netconf-notification-messages-01
> 
> Eric,
> 
> [warning: email quoting messed up below]
> 
> 
> "Eric Voit (evoit)" <evoit@cisco.com> 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:mbj@tail-f.com>> 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-notificati
> 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?
> 
> 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.
> 
> > 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 <kwatsen@juniper.net<mailto:kwatsen@juniper.net>> 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
> > > Netconf@ietf.org<mailto:Netconf@ietf.org>
> > > https://www.ietf.org/mailman/listinfo/netconf
> > >
> >
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org<mailto:Netconf@ietf.org>
> > https://www.ietf.org/mailman/listinfo/netconf
> >
> <
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf