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

[Martin Bjorklund <[e-mail]>]

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?

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 <[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-01
> >
> >
> > 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
> 
<