Subject: [Netconf] nested notifications

From: Andy Bierman <[email-masked]>
Date: Thu, 5 Jan 2017 14:24:39 -0800

Hi,

I would like some text in RFC 7950 to be reinterpreted. The text implies
each
notification message can only describe 1 instance of 1 event type.

RFC 7950, sec 7.16.2

   The innermost container or list contains an XML
   element that carries the name of the defined notification.

There are 3 corner-cases that should be considered in order
to minimize network overhead for notifications in 5277bis.
Replicating the node/key hierarchy could be expensive
and events occurring at the same time could be correlated.

Duplicating the notification messages is inefficient,
but processing multiple events per message makes
filtering and parsing more complicated.

I am curious if the WG thinks notification overhead is a concern and
if it needs to be addressed somehow in 5277bis.

1) multiple non-sibling events in same subtree

  <notification>

    <interfaces>

    *  <my-top-event>*

*        <my-data>42</my-data>*

*      </my-top-event>*

      <interface>

        <name>eth0</name>

    *    <my-interface-event>*

*              <if-data>auto</if-data>*

*        </my-interface-event>*

      </interface>

    </interfaces>

  </notification>

2) multiple sibling events in the same subtree

  <notification>

    <interfaces>

      <interface>

        <name>eth0</name>

     *   <my-interface-event>*

*              <if-data>auto</if-data>*

*        </my-interface-event>*

*        <interface-enabled>*

*           <by-user>admin</by-user>*

*        </interface-enabled>  *

      </interface>

    </interfaces>

  </notification>

3) multiple non-sibling events in different subtrees

  <notification>

    <system>

   *   <my-system-event>*

*            <my-data>42</my-data>*

*      </my-system-event>*

    </system>

    <interfaces>

      <interface>

        <name>eth0</name>

       * <my-interface-event>*

*              <if-data>auto</if-data>*

*        </my-interface-event>*

      </interface>

    </interfaces>

  </notification>

Andy

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 6 Jan 2017 01:16:32 +0000

Hi Andy,

“The innermost container or list” text is similar to that for actions in section 7.15.2.   Perhaps the mental model of one target for an action was replicated?

I had not considered that YANG 1.1’s definition might force the breakup of a verbose software component generated notification into multiple pushed notification messages.  Looking at the three cases below, I don’t think that arbitrary choices made in YANG model structure should impact what could or couldn’t be in encoded within any single notification.  So my preference would be that all three variants below should supportable if that is how the system passed them to be encoded as part of an event.

What if the reinterpretation were as simple as “An innermost” or “The first innermost”?

Eric

From: Netconf [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Thursday, January 5, 2017 5:25 PM
To: Netconf <[email-masked]>
Subject: [Netconf] nested notifications

Hi,

I would like some text in RFC 7950 to be reinterpreted. The text implies each
notification message can only describe 1 instance of 1 event type.

RFC 7950, sec 7.16.2

  <notification>

    <interfaces>

      <my-top-event>

        <my-data>42</my-data>

      </my-top-event>

      <interface>

        <name>eth0</name>

        <my-interface-event>

              <if-data>auto</if-data>

        </my-interface-event>

      </interface>

    </interfaces>

  </notification>

  <notification>

    <interfaces>

      <interface>

        <name>eth0</name>

        <my-interface-event>

              <if-data>auto</if-data>

        </my-interface-event>

        <interface-enabled>

           <by-user>admin</by-user>

        </interface-enabled>

      </interface>

    </interfaces>

  </notification>

  <notification>

    <system>

      <my-system-event>

            <my-data>42</my-data>

      </my-system-event>

    </system>

    <interfaces>

      <interface>

        <name>eth0</name>

        <my-interface-event>

              <if-data>auto</if-data>

        </my-interface-event>

      </interface>

    </interfaces>

  </notification>

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 5 Jan 2017 18:43:11 -0800

On Thu, Jan 5, 2017 at 5:16 PM, Eric Voit (evoit) <[email-masked]> wrote:

> Hi Andy,
>
>
>
> “The innermost container or list” text is similar to that for actions in
> section 7.15.2.   Perhaps the mental model of one target for an action was
> replicated?
>
>
>
> I had not considered that YANG 1.1’s definition might force the breakup of
> a verbose software component generated notification into multiple pushed
> notification messages.  Looking at the three cases below, I don’t think
> that arbitrary choices made in YANG model structure should impact what
> could or couldn’t be in encoded within any single notification.  So my
> preference would be that all three variants below should supportable if
> that is how the system passed them to be encoded as part of an event.
>
>
>

I think the WG did not consider these details and assumed they were the same
as for action.

This would be a MAY for the server and a MUST for the client, so it is not
an easy decision.

A couple use-cases I have in mind:

  1) event broker
      subscriber is really a broker that may be pre-processing lots of
      subscriptions or event types within 1 subscription

   2) digest (time-based push)
     Subscriber wants an update every 5 seconds with all the YANG 1.1 events
    for the previous 5 seconds

> What if the reinterpretation were as simple as “An innermost” or “The

This covers case 2. (Change "The" to "An").
The client would need to check for YANG 1.1 notifications in the
same way it checks child nodes already.

Andy

> *From:* Netconf [mailto:[email-masked]] *On Behalf Of *Andy
> Bierman
> *Sent:* Thursday, January 5, 2017 5:25 PM
> *To:* Netconf <[email-masked]>
> *Subject:* [Netconf] nested notifications
>
>
>
> Hi,
>
>
>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Fri, 6 Jan 2017 17:28:30 +0000

> From: Andy Bierman, January 5, 2017 9:43 PM
> 
> On Thu, Jan 5, 2017 at 5:16 PM, Eric Voit (evoit) <mailto:[email-masked]>
> wrote:
> Hi Andy,
> 
> “The innermost container or list” text is similar to that for actions in section
> 7.15.2.   Perhaps the mental model of one target for an action was replicated?
> 
> I had not considered that YANG 1.1’s definition might force the breakup of a
> verbose software component generated notification into multiple pushed
> notification messages.  Looking at the three cases below, I don’t think that
> arbitrary choices made in YANG model structure should impact what could or
> couldn’t be in encoded within any single notification.  So my preference would
> be that all three variants below should supportable if that is how the system
> passed them to be encoded as part of an event.
> 
> 
> 

These are both reasonable as controllers are requiring scalable methods of synching on device status.

> same way it checks child nodes already.

"Any innermost"...?   And yes, this is a more significant change on the client.  Beyond this, for use cases (1) & (2), if you don't want to summarize the eventTime, the time should be placed with each innermost event.  I am not suggesting we do this, but like Andy I want to figure out what the WG might be willing to consider in scope.

Eric

> Eric
> 
> 
> Andy
> 
> From: Netconf [mailto:mailto:[email-masked]] On Behalf Of Andy
> Bierman
> To: Netconf <mailto:[email-masked]>

---

From: Andy Bierman <[email-masked]>
Date: Fri, 6 Jan 2017 20:21:57 -0800

On Fri, Jan 6, 2017 at 9:28 AM, Eric Voit (evoit) <[email-masked]> wrote:

> section
> that
> > What if the reinterpretation were as simple as “An innermost” or “The
> first
> > innermost”?
> >
> "Any innermost"...?   And yes, this is a more significant change on the
> client.  Beyond this, for use cases (1) & (2), if you don't want to
> summarize the eventTime, the time should be placed with each innermost
> event.  I am not suggesting we do this, but like Andy I want to figure out
> what the WG might be willing to consider in scope.
>
>

There was actually a lot of discussion about "eventTime" in the NETCONF WG
when RFC 5277 was done.
Lots of disagreement on what it means.  The RFC offers little guidance or
hint of the discussion:

    eventTime:
       The time the event was generated by the event source.

It may take the server some time to detect the event after it occurs.
It may take some time to save the event for replay and transmission.
Which of these 3 different times is it? (Out of scope I think)

Adding more timestamps is an interesting idea.

But I think something like this could be done without a client MUST.
The client MAY request 'bulk-encoding' and if the server supports it,
a more optimized structure would be sent instead of the normal message.
The receiver MAY extract individual messages from the bulk format (maybe
binary)
into other formats (like XML or JSON).

I am trying to plan ahead for when YANG Push turns out to be a slow network
hog :-)

Eric
 Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 12 Jan 2017 13:53:20 +0100 (CET)

> and events occurring at the same time could be correlated.
      ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

So how common is this?  Is it worth the additional complexity to
support this case?  How many events would have to be generated at the
same time for this "optimization" be worth it?

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 12 Jan 2017 13:59:47 +0100 (CET)

> a more optimized structure would be sent instead of the normal message.

I prefer this approach, rather than the example in the original
email.  If the bulk-encoded notifications are encoded into a normal
notification, we don't have to change anything:

  <notification
      xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
    <eventTime>2017-01-08T00:01:00Z</eventTime>
    <bulk-notifications xmlns="...">
      <notification
          xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
        <eventTime>2017-01-08T00:00:00Z</eventTime>
        <link-up .../>
      </notification>

      <notification
          xmlns="urn:ietf:params:xml:ns:netconf:notification:1.0">
        <eventTime>2017-01-08T00:00:01Z</eventTime>
        <link-down .../>
      </notification>
      ...
   </notification>

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 12 Jan 2017 09:25:23 -0800

> > and events occurring at the same time could be correlated.
Depends on the meaning of "same time".
If I am implementing a client-configured digest service, and the client only
wants to receive notifications every 1 - 5 seconds instead of ASAP.
I can build up a tree of YANG 1.1 notifications and send it off in N
seconds,
then start a new tree.

I agree it is very implementation dependent whether or not the originator
of the event
will combine that event with others. (Most likely not).

Andy

---

From: Andy Bierman <[email-masked]>
Date: Thu, 12 Jan 2017 09:37:01 -0800

On Thu, Jan 12, 2017 at 4:59 AM, Martin Bjorklund <[email-masked]> wrote:

> > > > I had not considered that YANG 1.1’s definition might force the
> breakup
> > > of a
> > > > arbitrary choices made in YANG model structure should impact what
> could
> > > or
> > > > couldn’t be in encoded within any single notification.  So my
> preference
> > > would
> > > > be that all three variants below should supportable if that is how
> the
> > > system
> > > > I think the WG did not consider these details and assumed they were
> the
> > > same
> > > > as for action.
> > > >
> > > > This would be a MAY for the server and a MUST for the client, so it
> is
> > > not
> > > > an easy decision.
> > > >
> > > These are both reasonable as controllers are requiring scalable
> methods of
> > > synching on device status.
> > >
I was hoping for a bulk format that reduced the payload.
Your example actually increases the payload size.

I think the subscription needs some sort of encoding negotiation like the
Accept header in HTTP.
People will eventually think of lots of optimizations that we never
imagined.  The protocol should
be robust enough to allow this to happen.  e.g., send multiple
subscription-id values in
1 notification instead of duplicating that notification to the receiver N
times.
Another obvious optimization is the ability to group similar events into a
range
like link-up for a port-range, representing the entire line card that was
just plugged in.

  <notification>
     <hdr>....no restrictions on what is in the header ... </hdr>
     <link-down> ... </link-down>   // limit to 1 element for payload?
  </notification>

A simple notification is the canonical form.
A notification subscriber acting as a broker will need to convert the bulk
form
into 1 or more notifications in canonical format.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 12 Jan 2017 19:30:29 +0100 (CET)

> Your example actually increases the payload size.

For illustration purpose only ;-)

It's perfectly fine w/ me if the contents of this "bulk-notification"
notif contains a compressed or cleverly encoded list of
notifications.

The nice thing with your idea is that it doesn't change the core
protocol.

/martin

---

From: Mahesh Jethanandani <[email-masked]>
Date: Thu, 12 Jan 2017 10:57:15 -0800

> On Jan 12, 2017, at 9:25 AM, Andy Bierman <[email-masked]> wrote:
> 
> 
> 
> On Thu, Jan 12, 2017 at 4:53 AM, Martin Bjorklund <[email-masked] <mailto:[email-masked]>> wrote:
> Andy Bierman <[email-masked] <mailto:[email-masked]>> wrote:
> > Hi,
> >
> I can build up a tree of YANG 1.1 notifications and send it off in N seconds,
> then start a new tree.
> 
> I agree it is very implementation dependent whether or not the originator of the event

The ability to correlate events is important. 

Take the example of OAM running at different layers in the network. A failure at the physical layer will result in multiple events being generated at the higher layers. The ability to correlate events allows the suppression of events/alarms in the layer directly above the level where the fault/event was first detected. And if I can do that for one extra event, I have optimized.

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

Mahesh Jethanandani
[email-masked]

---

From: Alexander Clemm <[email-masked]>
Date: Thu, 12 Jan 2017 21:34:42 +0000

I agree that it makes sense to allow multiple notifications to be sent in one message.  

We need to allow for different time stamps, allowing to stamp individual notifications separately.  Clearly, compression schemes can be devised, including a trivial compression scheme to apply one "bulk" timestamp for every notification in the message.  

Looking at RFC 7950 Section 7.16.2, I am not sure how to parse it, specifically it is not clear what is really mandated as part of the encoding.  The RFC states merely that the notification is encoded as _a_ child XML element to the <notification> element.  The specification/definition of the <notification> element itself is however not part of RFC 7950, neither is the definition of the time stamp (event-time).  It seems that all that is specified is the encoding of the event itself, i.e. the representation of the notification identifier and then the parameters contained within it. 

Does RFC 7950 imply that notification nodes can only be encoded as contained in a <notification> element as defined in RFC 5277?  That would be a considerable limitation and issue at least in the context of Netconf.  I guess one could always define other encoding rules outside of Netconf.  I don't think defining a bulk notification as a special notification, that itself needs to be carried in a regular notification, is a good solution.  The notification element is pure overhead at this point.  Allowing the definition of a new bulk notification element, which can be used in lieu of a notification element, would seem a lot more desirable.  

--- Alex

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Martin Bjorklund
Sent: Thursday, January 12, 2017 10:30 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] nested notifications

Andy Bierman <[email-masked]> wrote:
> > > On Fri, Jan 6, 2017 at 9:28 AM, Eric Voit (evoit) 
> > > <[email-masked]>
> > wrote:
> > >
> > > > > verbose software component generated notification into 
> > > > > multiple
> > pushed
> > > > > notification messages.  Looking at the three cases below, I 
> > > > > don’t
> > think
> > > > that
> > > > >       subscriber is really a broker that may be pre-processing 
> > > > > lots
> > of
> > > > >      Subscriber wants an update every 5 seconds with all the 
> > > > > YANG 1.1
> > > > events
> > > > > The client would need to check for YANG 1.1 notifications in 
> > > > > the same way it checks child nodes already.
> > > >
> > > > client.  Beyond this, for use cases (1) & (2), if you don't want 
> > > > to summarize the eventTime, the time should be placed with each 
> > > > innermost event.  I am not suggesting we do this, but like Andy 
> > > > I want to figure
> > out
> > > There was actually a lot of discussion about "eventTime" in the 
> > > NETCONF
> > WG
> > > when RFC 5277 was done.
> > > Lots of disagreement on what it means.  The RFC offers little 
> > > guidance or hint of the discussion:
> > >
> > >
> > >     eventTime:
> > > The client MAY request 'bulk-encoding' and if the server supports 
> > > it, a more optimized structure would be sent instead of the normal message.
> >

It's perfectly fine w/ me if the contents of this "bulk-notification"
notif contains a compressed or cleverly encoded list of notifications.

The nice thing with your idea is that it doesn't change the core protocol.

/martin

> I think the subscription needs some sort of encoding negotiation like 
> the Accept header in HTTP.
> imagined.  The protocol should be robust enough to allow this to 
> happen.  e.g., send multiple subscription-id values in
> 1 notification instead of duplicating that notification to the 
> receiver N times.
> Another obvious optimization is the ability to group similar events 
> into a range like link-up for a port-range, representing the entire 
> line card that was just plugged in.
> 
>   <notification>
> A notification subscriber acting as a broker will need to convert the 
> bulk form into 1 or more notifications in canonical format.
> 
> 
> 
> >
> > /martin
> >
> 
> Andy
> 
> 
> >
> >
> > > I am trying to plan ahead for when YANG Push turns out to be a 
> > > slow
> > network
> > > hog :-)
> > >
> > >
> > > Eric
> > > >
> > > >
> > >  Andy
> > >
> > > > Eric
> > > > >
> > > > >
> > > > > Andy
> > > > >
> > > > > From: Netconf [mailto:mailto:[email-masked]] On 
> > > > > Behalf Of
> > Andy
> > > > > Bierman
> > > > > I would like some text in RFC 7950 to be reinterpreted. The 
> > > > > text
> > implies
> > > > each
> > > > > There are 3 corner-cases that should be considered in order to 
> > > > > minimize network overhead for notifications in 5277bis.
> > > > > Replicating the node/key hierarchy could be expensive and 
> > > > > events occurring at the same time could be correlated.
> > > > >
> > > > > Duplicating the notification messages is inefficient, but 
> > > > > processing multiple events per message makes filtering and 
> > > > > parsing more complicated.
> > > > >
> > > > > I am curious if the WG thinks notification overhead is a 
> > > > > concern and if it needs to be addressed somehow in 5277bis.
> > > > >
> > > > >

---

From: Per Hedeland <[email-masked]>
Date: Thu, 12 Jan 2017 22:45:43 +0100

> Looking at RFC 7950 Section 7.16.2, I am not sure how to parse it, specifically it is not clear what is really mandated as part of the encoding.  The RFC states merely that the notification is enco…

It seems that you are reading only the first paragraph of 7.16.2, the
one that starts with "A notification node that is defined on the top
level of a module...". Try the second one.:-)

--Per

>>>>>> The innermost container or list text is similar to that for
>>> actions in
>>>>> section
>>>>>> I had not considered that YANG 1.1s definition might force 
>>>>>> the
>>> breakup
>>>>> of a
>>>>>> dont
>>>>>> couldnt be in encoded within any single notification.  So my
>>> preference
>>>>> would
>>>>>> What if the reinterpretation were as simple as An innermost 
>>>>>> or The
>>>>> first
>>>>>> innermost?
>>>>>>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 12 Jan 2017 22:55:35 +0100 (CET)

> level of a module...". Try the second one.:-)

And also check the XSD in RFC 5277; it allows exactly one child element
for the notification content.

> > Does RFC 7950 imply that notification nodes can only be encoded as contained in a <notification> element as defined in RFC 5277?  That would be a considerable limitation and issue at least in the…

Even in the bulk case you probably want the eventTime for each
individual notification, and if we add more header fields some might
be notification specific.  The overhead of the top-level element
'notification' is minimal in this case.  And for the header fields
that apply to all notifications within the bulk, they can nicely be
handled if the bulk thingie is a notification.

/martin

---

From: Alexander Clemm <[email-masked]>
Date: Thu, 12 Jan 2017 22:31:50 +0000

Understood, 5277 allows exactly one child element for the notification element.  

My question is about 7950.  Does 7950 mandate that notification nodes MUST be used/encoded per 5277 - does 5277 by extension become part of 7950?  Or does it merely specify what goes below (the notification element element in the case of 5277, and perhaps a bulk element or something else in case a 5277 alternative becomes available?  I guess from your responses it's the former (which I find somewhat limiting - but I guess we are free to define other encodings for other contexts beyond Netconf XML...).  

--- Alex

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Thursday, January 12, 2017 1:56 PM
To: [email-masked]
Cc: Alexander Clemm <[email-masked]>; [email-masked]
Subject: Re: [Netconf] nested notifications

> level of a module...". Try the second one.:-)

And also check the XSD in RFC 5277; it allows exactly one child element for the notification content.

> > Does RFC 7950 imply that notification nodes can only be encoded as contained in a <notification> element as defined in RFC 5277?  That would be a considerable limitation and issue at least in the…

Even in the bulk case you probably want the eventTime for each individual notification, and if we add more header fields some might be notification specific.  The overhead of the top-level element 'notification' is minimal in this case.  And for the header fields that apply to all notifications within the bulk, they can nicely be handled if the bulk thingie is a notification.

/martin

> >>>>>> I had not considered that YANG 1.1s definition might force the
> >>> breakup
> >>>>> of a
> >>> email.  If the bulk-encoded notifications are encoded into a 
> >>> normal notification, we don't have to change anything:
> >>>
> >>>   <notification
> >> I think the subscription needs some sort of encoding negotiation 
> >> like the Accept header in HTTP.
> >> A notification subscriber acting as a broker will need to convert 
> >> the bulk form into 1 or more notifications in canonical format.
> >>
> >>
> >>
> >>>
> >>> /martin
> >>>
> >>
> >> Andy
> >>
> >>
> >>>
> >>>

---

From: "Eric Voit (evoit)" <[email-masked]>
Date: Thu, 12 Jan 2017 22:58:53 +0000

We should split the need for nesting, which is a function of encoding efficiency from the need for bundling, which might be done to limit the number of messages sent.

If encoding efficiency isn't really an issue, we can just concatenate events into a single event notification bundle.  And then push the bundle.  Such a thing would impact the headers of course, and we might want different headers for each notification as well as the overall bundle.  Something like:

<notification  xmlns="some-new-namespace">
  <hdr>
    <notification-time>2017-01-12T12:00:05Z</notification-time>
   <notification-identifier>349873</notification-identifier>
    <previous-notification-identifier>094882</previous-notification-identifier>
  </hdr>
  <event>
      <hdr>
         <event-time>2017-01-12T12:00:00Z</event-time>
         <subscription-id>22</subscription-id>
      </hdr>
      <netconf-config-change xmlns="netconf-notification-ns">
          ...
      </netconf-config-change>
   </event>
  <event>
      ...
  </event>
</notification>

As each event above is discrete, we should be able to multiplex general notifications, subscribed notifications, and yang-push updates.

Eric

> From: Netconf, January 12, 2017 5:32 PM
> 
> My question is about 7950.  Does 7950 mandate that notification nodes MUST
> be used/encoded per 5277 - does 5277 by extension become part of 7950?  Or
> does it merely specify what goes below (the notification element element in
> the case of 5277, and perhaps a bulk element or something else in case a 5277
> alternative becomes available?  I guess from your responses it's the former
> (which I find somewhat limiting - but I guess we are free to define other
> encodings for other contexts beyond Netconf XML...).
> 
> --- Alex
> 
> > > We need to allow for different time stamps, allowing to stamp individual
> notifications separately.  Clearly, compression schemes can be devised,
> including a trivial compression scheme to apply one "bulk" timestamp for every
> notification in the message.
> > >
> > > Looking at RFC 7950 Section 7.16.2, I am not sure how to parse it,
> specifically it is not clear what is really mandated as part of the encoding.  The
> RFC states merely that the notification is encoded as _a_ child XML element to
> the <notification> element.  The specification/definition of the <notification>
> element itself is however not part of RFC 7950, neither is the definition of the
> time stamp (event-time).  It seems that all that is specified is the encoding of
> the event itself, i.e. the representation of the notification identifier and then
> the parameters contained within it.
> >
> > > Does RFC 7950 imply that notification nodes can only be encoded as
> contained in a <notification> element as defined in RFC 5277?  That would be a
> considerable limitation and issue at least in the context of Netconf.  I guess one
> could always define other encoding rules outside of Netconf.  I don't think
> defining a bulk notification as a special notification, that itself needs to be
> carried in a regular notification, is a good solution.  The notification element is
> pure overhead at this point.  Allowing the definition of a new bulk notification
> element, which can be used in lieu of a notification element, would seem a lot
> more desirable.
> 
> Even in the bulk case you probably want the eventTime for each individual
> notification, and if we add more header fields some might be notification
> specific.  The overhead of the top-level element 'notification' is minimal in this
> case.  And for the header fields that apply to all notifications within the bulk,
> they can nicely be handled if the bulk thingie is a notification.
> 
> 
> 
> /martin
> 
> 
> 
> > >
> > > --- Alex
> > >

---

From: Martin Bjorklund <[email-masked]>
Date: Fri, 13 Jan 2017 10:26:27 +0100 (CET)

Alexander Clemm <[email-masked]> wrote:
> My question is about 7950.  Does 7950 mandate that notification nodes
> MUST be used/encoded per 5277 - does 5277 by extension become part of
> 7950?  Or does it merely specify what goes below (the notification
> element element in the case of 5277, and perhaps a bulk element or
> something else in case a 5277 alternative becomes available?  I guess
> from your responses it's the former (which I find somewhat limiting -
> but I guess we are free to define other encodings for other contexts
> beyond Netconf XML...).

Maybe a little of both...  The section is called "NETCONF XML Encoding
Rules".  So clearly other contexts can have other rules.  But when it
is time to send a notification over NETCONF, clients know how the
notification will be encoded.  Now, suppose we obsolete 5277 and
define a new <notfifcation> element.  In this case we should probably
define a paragraph in the new RFC which "Updates: RFC 7950", with text
that exaplains how YANG-defined notifications are encoded.

/martin

> > > We need to allow for different time stamps, allowing to stamp
> > > individual notifications separately.  Clearly, compression schemes can
> > > be devised, including a trivial compression scheme to apply one "bulk"
> > > timestamp for every notification in the message.
> > > 
> > > specifically it is not clear what is really mandated as part of the
> > > encoding.  The RFC states merely that the notification is encoded as
> > > _a_ child XML element to the <notification> element.  The
> > > specification/definition of the <notification> element itself is
> > > however not part of RFC 7950, neither is the definition of the time
> > > stamp (event-time).  It seems that all that is specified is the
> > > encoding of the event itself, i.e. the representation of the
> > > notification identifier and then the parameters contained within it.
> > 
> > > contained in a <notification> element as defined in RFC 5277?  That
> > > would be a considerable limitation and issue at least in the context
> > > of Netconf.  I guess one could always define other encoding rules
> > > outside of Netconf.  I don't think defining a bulk notification as a
> > > special notification, that itself needs to be carried in a regular
> > > notification, is a good solution.  The notification element is pure
> > > overhead at this point.  Allowing the definition of a new bulk
> > > notification element, which can be used in lieu of a notification
> > > element, would seem a lot more desirable.
>

---

From: Alexander Clemm <[email-masked]>
Date: Fri, 13 Jan 2017 18:43:50 +0000

If can have a clause that allows us to updates RFC 7950, clearly designates as such, that will work.
Thanks
--- Alex

-----Original Message-----
From: Martin Bjorklund [mailto:[email-masked]] 
Sent: Friday, January 13, 2017 1:26 AM
To: Alexander Clemm <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [Netconf] nested notifications

> but I guess we are free to define other encodings for other contexts 

Maybe a little of both...  The section is called "NETCONF XML Encoding Rules".  So clearly other contexts can have other rules.  But when it is time to send a notification over NETCONF, clients know how the notification will be encoded.  Now, suppose we obsolete 5277 and define a new <notfifcation> element.  In this case we should probably define a paragraph in the new RFC which "Updates: RFC 7950", with text that exaplains how YANG-defined notifications are encoded.

/martin

> > > individual notifications separately.  Clearly, compression schemes 
> > > can be devised, including a trivial compression scheme to apply one "bulk"
> > > specifically it is not clear what is really mandated as part of 
> > > the encoding.  The RFC states merely that the notification is 
> > > encoded as _a_ child XML element to the <notification> element.  
> > > The specification/definition of the <notification> element itself 
> > > is however not part of RFC 7950, neither is the definition of the 
> > > time stamp (event-time).  It seems that all that is specified is 
> > > the encoding of the event itself, i.e. the representation of the 
> > It seems that you are reading only the first paragraph of 7.16.2, 
> > the one that starts with "A notification node that is defined on the 
> > top level of a module...". Try the second one.:-)
> 
> > > contained in a <notification> element as defined in RFC 5277?  
> > > That would be a considerable limitation and issue at least in the 
> > > context of Netconf.  I guess one could always define other 
> > > encoding rules outside of Netconf.  I don't think defining a bulk 
> > > notification as a special notification, that itself needs to be 
> > > carried in a regular notification, is a good solution.  The 
> > > notification element is pure overhead at this point.  Allowing the 
> > > definition of a new bulk notification element, which can be used 
> > > in lieu of a notification element, would seem a lot more desirable.
> 
> > >> On Thu, Jan 12, 2017 at 4:59 AM, Martin Bjorklund 
> > >> <[email-masked]>
> > >> wrote:
> > >>
> > >>>>>>       subscriber is really a broker that may be 
> > >>>>>> pre-processing lots
> > >>> of
> > >>>>> "Any innermost"...?  And yes, this is a more significant 
> > >>>>> change on the client.  Beyond this, for use cases (1) & (2), 
> > >>>>> if you don't want to summarize the eventTime, the time should 
> > >>>>> be placed with each innermost event.  I am not suggesting we 
> > >>>>> do this, but like Andy I want to figure
> > >>> out
> > >>>> The client MAY request 'bulk-encoding' and if the server 
> > >>>> supports it, a more optimized structure would be sent instead 
> > >>>> of the normal message.
> > >>>
> > >> People will eventually think of lots of optimizations that we 
> > >> never imagined.  The protocol should be robust enough to allow 
> > >> this to happen.  e.g., send multiple subscription-id values in
> > >> Another obvious optimization is the ability to group similar 
> > >> events into a range like link-up for a port-range, representing 
> > >> the entire line card that was just plugged in.
> > >>
> > >>   <notification>