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

Hi,  

Couple of thoughts inline, <ALEX>

--- Alex

-----Original Message-----
From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Martin Bjorklund
Sent: Thursday, August 24, 2017 11: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-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.  
</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.  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.  

</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 <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