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

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

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.

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