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

From: Kent Watsen <[email-masked]>
Date: Mon, 21 Aug 2017 22:05:57 +0000

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)

---

From: Tianran Zhou <[email-masked]>
Date: Wed, 23 Aug 2017 02:22:03 +0000

Hi,

I support this document to be adopted by the WG.
The other call for adoption document draft-zheng-netconf-udp-pub-channel-00 will refer this work for the message header design.
So I would like to review and contribute if it is adopted by the WG.

Here are some initial comments:
1. I do not understand why the document separate the two formats for single record and bundled records. In principle, the bundled message can represent 
the general cases. Maybe you are considering some optimization. But I did not see it.

2. You include the "dscp" in the message header. How can this be used in upper transport layer? It's an IP layer parameter.

3. You have a "record-count? uint16" in the bundled record message. Why this is useful? When decoding the records, the count is discovered automatically. And it won't help for decoding the records. Alternatively I think a "message length" would help. The decoder can know how much data to feed.

4. You have "message-generator-id" and "observation-domain-id". I think both of them are used to indicate the source of the data. Then why we need two?

5. In what scope is the subscription-id unique, per device, per receiver, or globally? It's better to indicate.

Cheers,
Tianran

> -----Original Message-----
> From: Netconf [mailto:[email-masked]] On Behalf Of Kent Watsen
> Sent: Tuesday, August 22, 2017 6:06 AM
> To: [email-masked]
> Subject: [Netconf] WG adoption poll
> draft-voit-netconf-notification-messages-01
> 
> 
> All,
> 
> This is start of a two-week poll on making the following draft a NETCONF
> working group document:
> 
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netconf

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Wed, 23 Aug 2017 14:10:39 +0000

Thanks Tianran, some thoughts in-line...

> From: Tianran Zhou, August 22, 2017 10:22 PM
> 
> Hi,
> 
> The other call for adoption document draft-zheng-netconf-udp-pub-channel-00
> will refer this work for the message header design.
> 1. I do not understand why the document separate the two formats for single
> record and bundled records. In principle, the bundled message can represent

There are a few known reasons:
(1) Optimization: one less level of encapsulation for records.
(2) Provides a minimal change from existing YANG notifications: no need to add hierarchical parsing.
(3) Notification-time is mandatory with the bundling format, but optional for single records.

I suspect we will find additional reasons as we examine specific transports

> 2. You include the "dscp" in the message header. How can this be used in upper
> transport layer? It's an IP layer parameter.

If the same application does not control both the notification generation process and the IP bundling process, then there needs to be some communication between them to allow the DSCP to be set appropriately.  

> 3. You have a "record-count? uint16" in the bundled record message. Why this
> is useful? When decoding the records, the count is discovered automatically.
> And it won't help for decoding the records. Alternatively I think a "message
> length" would help. The decoder can know how much data to feed.

This is one of the discussions we want to have about the draft.  It is true that record count can be calculated, but:
(a) it conceivable that a receiver might start processing records before receipt of the whole bundle.  Perhaps the count might matter in allocating resources?
(b) there are historical protocols which include record count as a field
(c) extra layer of error checking?

As you can see, the value might not be enough here to retain this optional header object in the draft.  But having it in for now keeps the discussion open.

 Sadly we can't use message-length in this case as that will depend on the selected encoding.  

> 4. You have "message-generator-id" and "observation-domain-id". I think both
> of them are used to indicate the source of the data. Then why we need two?

The creator of the record and the creator of the bundled notification might not been the same.    For example, a record might be created on a line card, but the notification itself might come from the main CPU.  

One objective of the discussions will be to see if we can/should reuse the definition of observation domains from IPFIX.    IPFIX itself has the concept of "Exporter" and there can be many observation domains per exporter, and many exporters per device.  In the next version of the draft, I will rename message-generator-id to exporter-id to make this discussion clearer.

> globally? It's better to indicate.

Per publisher.   I will update the text to make this clear.

Eric

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

---

From: "Zhengguangying (Walker)" <[email-masked]>
Date: Thu, 24 Aug 2017 00:53:59 +0000

Hi

  I support this document to be adopted by the WG.
  The other call for adoption document draft-zheng-netconf-udp-pub-channel-00 will refer this work for the message header design.
  I would like to review and contribute if it is adopt by WG..

Here are some initial comments:
1.Now single record message header and bundled message header is not same, it makes implementation a little complex, whether it can make the message header and record header same no matter it is bundled or not.
Such as；
1)Single Notification:
[message header] 
[record header]
[notification content]

2)Bundled Notifications:
[message header] 
[Bundle header]
[notification records]
  [record header]
  [notification content]

2.why subscription-id define as " leaf-list ", I think for one subscriber same notification will be subscribed only by one subscription-id.

Cheers,
Walker

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 24 Aug 2017 14:24:41 +0200 (CEST)

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.  Then a followup document (like
draft-voit-netconf-notification-messages) can use this extensibility
mechanism to define more common header fields.

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.

I would like to see these concerns addressed before the WG adopts this
document.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 24 Aug 2017 09:04:59 -0700

> I would like to see these concerns addressed before the WG adopts this
I agree these issues need to be addressed.

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

> /martin
Andy

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 24 Aug 2017 18:29:27 +0000

From: Andy Bierman, August 24, 2017 12:05 PM

On Thu, Aug 24, 2017 at 5:24 AM, Martin Bjorklund <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

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

<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 <[email-masked]<mailto:[email-masked]>> wrote:
> [email-masked]<mailto:[email-masked]>

_______________________________________________
Netconf mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/netconf

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 24 Aug 2017 20:43:36 +0200 (CEST)

Eric,

[warning: email quoting messed up below]

"Eric Voit (evoit)" <[email-masked]> wrote:
> <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.

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.

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

> > [1] https://tools.ietf.org/id/draft-voit-netconf-notification-messages-01
<

---

From: Alexander Clemm <[email-masked]>
Date: Fri, 25 Aug 2017 00:06:21 +0000

Hi,  

Couple of thoughts inline, <ALEX>

--- Alex

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Martin Bjorklund
Sent: Thursday, August 24, 2017 11:44 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] WG adoption poll draft-voit-netconf-notification-messages-01

Eric,

> <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 backw…

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.

> <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 w…

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>

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

> > document.  If yes, please also feel free to provide comments you'd 
> > like to see addressed once the document is a WG document.
> >
> >
> > [1] 
<

---

From: Tianran Zhou <[email-masked]>
Date: Fri, 25 Aug 2017 05:41:47 +0000

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

> Sent: Friday, August 25, 2017 2:44 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [Netconf] WG adoption poll
> > On Thu, Aug 24, 2017 at 5:24 AM, Martin Bjorklund
> <[email-masked]<mailto:[email-masked]>> wrote:
> > Hi,
> >
> > <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.
> 
> > 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.
> > <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.
> 
> 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.
> 
> > <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.)
> >
> > <Eric> Hopefully the thoughts above sufficient for now.   Any alternative
> approaches/proposals would be great to hear.
>

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 25 Aug 2017 09:11:44 +0200 (CEST)

Hi,

> <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 f…

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

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

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 25 Aug 2017 19:36:12 +0000

Hi Martin,

Thanks for your thoughts.

We had two threads on notifications and draft structure issues in January.  
(1) nested notifications
(2) New Notification and Subscription Features WASFW: 3 Options for Subscription & Event Notification draft structure

My read on the outcome was that that there was a desire have a specification which would be a standalone enhancement to RFC-7950.  But the document could be later incorporated into a YANG 1.2. 

One dialog between Kent & Andy also focused on the exact issue of this thread. See:
https://mailarchive.ietf.org/arch/msg/netconf/NXK4eWlOE32vEn_7X0yHC_8u4Mk
 
Andy has continued his thinking and as you point out has included some of his suggested concepts into draft-bierman-netmod-yang-data-ext-00.

Your very useful solution proposal below synchs nicely with that thinking.   And an integration of these proposals should be included within this draft.  My suggested next step is to collapse that work into the next version.

As a side note: we did consider including much of this within draft-ietf-netconf-subscribed-notifications.   But it was not necessary to delay that draft (which focuses on the control plane) with something that fixes gaps in yang 1.1 notifications & data plane.  So what we did in section 6 is to define the minimum information which must be transported in a data plane message, and provide two header objects which need to be included in an existing message which would then make the data plane compliant.  This is a minimal way to get people started, and can easily work with existing 5277 data plane parsing.  The rest of section 6 then points to this new work in preparation for the time yang notifications are updated (as per the thread above). 

Eric

> From: Martin Bjorklund [mailto:[email-masked]]
> Sent: Friday, August 25, 2017 3:12 AM
> To: [email-masked]
> Cc: Eric Voit (evoit) <[email-masked]>; [email-masked]
> > > NETCONF and RESTCONF.  It has a non-exensible header, and I agree
> > > that it would be good to fix that.
> > >
> > > documents in this set (not sure which one) needs to properly define
> > > a new notification message, and introduce an extensibility mechanism
> > > for the header.
> 6<https://tools.ietf.org/html/draft-ietf-netconf-subscribed-notifications-
> 03#section-6> defines minimal object additions as well as backwards
> 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.
> >
> > > 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.
> because these extensible headers are not backwards compatible that a
> separate new draft is being proposed.
> > <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:
> 
> 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.
> 
> 
> > > 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
> > > <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
> > > I would like to see these concerns addressed before the WG adopts
> > > this document.
> > >
> > > > 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)
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >

---

From: Alexander Clemm <[email-masked]>
Date: Fri, 25 Aug 2017 20:50:36 +0000

Hi Martin, Eric, all,

First, I think we are all in agreement that we should define an update to RFC 7950.  This makes a lot of sense to me.  Good point also regarding extending that update to RFC 8040.  

It seems to me that in subscribed-notifications, we should indicate what the instantiated notification header structure will look like, but leave the actual update to RFC 7950 to a later draft.  It seems to me that draft-voit-netconf-notification-messages is a good place to put it, since this talks about the various notification and notification bundle fields extensively.  Are YANG data extensions needed for this per Martin's suggestion?  Possibly, although not sure this is required - at least I am not convinced yet on that point: clearly, it will be good if we don't make the notification record itself not just an anydata (as is the case now - I agree this needs to be improved) and this provides a good option to do that.  At the same time, the YANG information this is nested in is not "general" YANG information, but defines what will be used in the header structure of the notification element, so it could be defined specifically for that purpose without redirecting to yet another mechanism.  

--- Alex

-----Original Message-----
From: Eric Voit (evoit) [mailto:[email-masked]] 
Sent: Friday, August 25, 2017 12:36 PM
To: Martin Bjorklund <[email-masked]>
Cc: Alexander Clemm <[email-masked]>; [email-masked]; Andy Bierman ([email-masked]) <[email-masked]>; Kent Watsen <[email-masked]>
Subject: RE: [Netconf] WG adoption poll draft-voit-netconf-notification-messages-01

Hi Martin,

 

Eric

> > > 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.
> ons- 03#section-6> defines minimal object additions as well as 
> backwards compliance with YANG 1.1 Notifications (RFC-7950 section 
> > 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.
> >
> is critical as we don’t want to require a new notification element for 
> the existing event subscription work.
> > > draft-voit-netconf-notification-messages) can use this 
> > > extensibility mechanism to define more common header fields.
> 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.
> >
> 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.
> 
> documents, as long as the base document with the extensibility mechanism is clear.
> 
> > </ALEX>
> >
> > 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.
> >
> >
> 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.
> >
> "Updates: RFC 7950", with text that explains how YANG-defined 
> notifications are encoded.  This is probably what we need to do here.
> 
> a solution
> namespace in order to differentiate from RFC 5277.  Use yang-data for this purpose:
> 
> regardless of protocol.  It also needs to update RFC 8040 which currently says that RFC 5277 is used.
> 
> 
> > > 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.
> > >   2) ability to identify mandatory vs. optional property (even if 
> > > nothing else
> understood)

---

From: Alberto Gonzalez Prieto <[email-masked]>
Date: Sun, 27 Aug 2017 23:53:15 +0000

Hi,

I support the adoption of this document.

Thanks,

Alberto

-----Original Message-----
    From: Netconf [mailto:[email-masked]] On Behalf Of Kent Watsen
    Sent: Monday, August 21, 2017 6:06 PM
    To: [email-masked]
    Subject: [Netconf] WG adoption poll draft-voit-netconf-notification-messages-01

    All,
    
    This is start of a two-week poll on making the following draft a NETCONF working group document:

    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://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_id_draft-2Dvoit-2Dnetconf-2Dnotification-2Dmessages-2D01&d=DwIFAg&c=uilaK90D4TOVoH58JNXRgQ&r=KJ_RyS3eAzz1Ve3fwHPCSA8ePAC6WkGpet-3T1-b68U&m=_0I3eljt7fxKUujAdYFn2nwW7wQ-nYsMvaWylkQvjlY&s=9tqxWWjoeautgzrMVhabWgWFyqJzj1yOFyTbdX8hghI&e= 

    Thank you,
    Kent (and Mahesh)

   
    \

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 28 Aug 2017 10:17:18 +0200 (CEST)

"Eric Voit (evoit)" <[email-masked]> wrote:
> Your very useful solution proposal below synchs nicely with that
> thinking.   And an integration of these proposals should be included
> within this draft.  My suggested next step is to collapse that work
> into the next version.

Agreed!  I would like to see this introdcuced before adopting the
document.

> As a side note: we did consider including much of this within
> draft-ietf-netconf-subscribed-notifications.   But it was not
> necessary to delay that draft (which focuses on the control plane)
> with something that fixes gaps in yang 1.1 notifications & data
> plane.  So what we did in section 6 is to define the minimum
> information which must be transported in a data plane message, and
> provide two header objects which need to be included in an existing
> message which would then make the data plane compliant.  This is a
> minimal way to get people started, and can easily work with existing
> 5277 data plane parsing.

But then draft-ietf-netconf-subscribed-notifications
(+event-notif) cannot obsolete RFC 5277, as it does currently.

And I don't understand how I can implement
draft-ietf-netconf-subscribed-notifications with RFC5277, when
draft-ietf-netconf-subscribed-notifications mandates a
"subscription-id" in the header, when no such element is defined in
RFC 5277.  It seems to me that
draft-ietf-netconf-subscribed-notifications really requires
draft-voit-netconf-notification-messages.

I would prefer a complete solution, or rather, that we build from
the bottom and up, rather than the other way around.

Note that you're trying to replace several mechanisms:

1)  The "notification" message in NETCONF's Message Layer (see section
    1.2 of RFC 6241), and corresponding in RESTCONF.

    This is currently defined in Section 2.2 and 4 in RFC 5277
    (NETCONF) and section 6.4 in RFC 8040 (RESTCONF).

2)  How YANG notifications are encoded in XML and JSON.

    This is currently defined in 7.16 in RFC 7950 (XML) and section
    6.4 in RFC 8040 (JSON).
    
3)  How notification subscriptions are handled.

    This is currently defined in section 2.1 and 3 in RFC 5277
    (NETCONF) and section 6 in RFC 8040 (RESTCONF).

As a minimum, it must be clear how these updates / replacements are
done in the new set of documents.

/martin

The rest of section 6 then points to this new work in preparation for the time yang notifications are updated (as per the thread above).

---

From: Martin Bjorklund <[email-masked]>
Date: Mon, 28 Aug 2017 10:25:36 +0200 (CEST)

Hi,

Alexander Clemm <[email-masked]> wrote:
> It seems to me that in subscribed-notifications, we should indicate
> what the instantiated notification header structure will look like,
> but leave the actual update to RFC 7950 to a later draft.

See my email to Eric.  If this is not defined in
subscribed-notifications, but in a separate document, I think this
separate document needs to be referenced from
subscribed-notifications.

> It seems
> to me that draft-voit-netconf-notification-messages is a good place
> to put it, since this talks about the various notification and
> notification bundle fields extensively.  Are YANG data extensions
> needed for this per Martin's suggestion?  Possibly, although not
> sure this is required - at least I am not convinced yet on that
> point: clearly, it will be good if we don't make the notification
> record itself not just an anydata (as is the case now

Actually, today the "notification" message in RFC 5277 is defined in
XSD, so it is even worse than anydata.

> - I agree this
> needs to be improved) and this provides a good option to do that.

Yes!

> At the same time, the YANG information this is nested in is not
> "general" YANG information, but defines what will be used in the
> header structure of the notification element,

Right, which is why rc:yang-data is the correct YANG statement for
this - not "notification".

/martin

> so it could be defined
> specifically for that purpose without redirecting to yet another
> mechanism.
> 
> --- Alex
> 
>

---

From: Alexander Clemm <[email-masked]>
Date: Mon, 28 Aug 2017 21:59:24 +0000

Hi Martin

Thank you for your response - replies inline, <ALEX>

--- Alex

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Monday, August 28, 2017 1:26 AM
To: Alexander Clemm <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Re: [Netconf] WG adoption poll draft-voit-netconf-notification-messages-01

Hi,

> but leave the actual update to RFC 7950 to a later draft.

See my email to Eric.  If this is not defined in subscribed-notifications, but in a separate document, I think this separate document needs to be referenced from subscribed-notifications.

<ALEX> So in this case we need to make sure this clear in subscribed notifications.  We cannot have to introduce and await an entirely new document, but we do need to progress yang-push.   We can apply the textual updates from there, and make the current text stronger (and clearer as needed).  
</ALEX>

> It seems
> to me that draft-voit-netconf-notification-messages is a good place to 
> put it, since this talks about the various notification and 
> needed for this per Martin's suggestion?  Possibly, although not sure 
> this is required - at least I am not convinced yet on that

Actually, today the "notification" message in RFC 5277 is defined in XSD, so it is even worse than anydata.

Yes!

> header structure of the notification element,

Right, which is why rc:yang-data is the correct YANG statement for this - not "notification".

<ALEX> Reading through this module, I am actually not exactly sure if it is.  RFC 8040 states in very clear terms this module applies only to RESTCONF protocol messages.  We do not have this restricted context here.  From the specification it is also not clear (at least not to me) how this statement would be used even if the context were to be extended?   We _do_ want to specify data to be carried in the header structure of the notification element.  It would seem to me that we can specify the notification element in a corresponding subsection in the document and simply indicate the fields that can be included per a YANG data model we can define for this purpose that states very clear this is data not to be instantiated in a data store but for <notification> messages.  I don't think we would even need a YANG extension  for that.  
--- Alex

</ALEX>

/martin

> Cc: Alexander Clemm <[email-masked]>; [email-masked]; 
> Andy Bierman ([email-masked]) <[email-masked]>; Kent Watsen 
> <[email-masked]>
> Subject: RE: [Netconf] WG adoption poll 
> (2) New Notification and Subscription Features WASFW: 3 Options for 
> Subscription & Event Notification draft structure
> 
> > > > I support the problem statement in this draft, but I have 
> > > > concerns with the proposed solution.
> > > >
> > drafts.  The section you refer *should* provide a clear 
> > talks about things that ought to go into a notification, and shows an example.
> > >
> > is critical as we don’t want to require a new notification element 
> > 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.
> > >
> > 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.
> > 
> > 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.
> > >
> > >
> > To extend this, use Andy's proposed yang-data-augment, and make use 
> > of features and modules to avoid the kitchen-sink syndrome:
> > 
> > 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.
> > > >
> > > >   2) ability to identify mandatory vs. optional property (even 
> > > > if nothing else
> > understood)
> > > > > 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-mess
> > > > > ag
> > > > > es
> > > > > -0
> > > > > 1
> > > > >
> > > > >
> > > > > Thank you,
> > > > > Kent (and Mahesh)
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 29 Aug 2017 12:17:26 +0200 (CEST)

> <ALEX> So in this case we need to make sure this clear in subscribed notifications.  We cannot have to introduce and await an entirely new document, but we do need to progress yang-push.   We can a…

Fine (*).  Just make sure that the set of documents you want to progress
are internally consistent and consistent with 5277 (if we assume that
it will not be obsoleted by this new set of documents).  The current
set of documents both says that they obsolete 5277, and at the same
time use stuff from 5277 (the "notification" XSD).

(*) Personally, I would like to see a complete solution, including a
protcol-netutral notification message definition, and if it uses
rc:yang-data and just includes a minimal set of leafs in the header,
it shouldn't take very long to finish.

> <ALEX> Reading through this module, I am actually not exactly sure
> if it is.  RFC 8040 states in very clear terms this module applies
> only to RESTCONF protocol messages.

This has been discussed before.  Personally, I would like to see
rc:yang-data moved to a separate document, together with the proposed
augment-yang-data extension.  But for now, it is perfectly fine to use
rc:yang-data outside of RESTCONF.  (An example is the anima voucher
definition).

> We do not have this restricted context here.  From the specification it is also not clear (at least not to me) how this statement would be used even if the context were to be extended?   We _do_ want to specify data to be carried in the header structure of the notification element.  It would seem to me that we can specify the notification element in a corresponding subsection in the document and simply indicate the fields that can be included per a YANG data model we can define for this purpose that states very clear this is data not to be instantiated in a data store but for <notification> messages.  I don't think we would even need a YANG extension  for that.  

I don't understand what you are proposing.  Can you examplify / clarify?

/martin