Subject: [Netconf] Should Default Event Stream contain really all the notifications ?

From: Boris Pilka <[email-masked]>
Date: Wed, 04 Jun 2014 14:56:46 +0200

Hi,

could you, please, clarify the following for me:

RFC5277 section 3.2.3.
'A NETCONF server implementation supporting the notification
    capability MUST support the "NETCONF" notification event stream.
    This stream contains all NETCONF XML event notifications supported by
    the NETCONF server.  The exact string "NETCONF" is used during the
    advertisement of stream support during the <get> operation on
    <streams> and during the <create-subscription> operation.  Definition
    of the event notifications and their contents, beyond the inclusion
    of <eventTime>, for this event stream is outside the scope of this
    document.'

Imagine 20 streams being present on Netconf Server apart from NETCONF 
stream.

Does the section above suggests, that notifications from all 20 streams 
should be also be sent in a NETCONF stream ?

Thank you very much,

Boris Pilka

---

From: Andy Bierman <[email-masked]>
Date: Wed, 4 Jun 2014 09:20:05 -0700

> Imagine 20 streams being present on Netconf Server apart from NETCONF
kind of hard, unless you are adding filtering into the stream definition.

> should be also be sent in a NETCONF stream ?
No, but this probably needs clarification.
The standard notifications defined in YANG (e.g., RFC 6470)
are expected to show up on the NETCONF stream.  You can put whatever
content on whatever stream you want, but for standard notification
definitions,
they must at (at least) be in the NETCONF stream.

Thank you very much,
> Boris Pilka

Andy

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

---

From: Kent Watsen <[email-masked]>
Date: Wed, 4 Jun 2014 17:37:07 +0000

Does the section above suggests, that notifications from all 20 streams should be also be sent in a NETCONF stream ?

> No, but this probably needs clarification.

[KENT] really?  I always thought that "all" meant "all"?   Wasn't the motivation to guarantee access all the events?

> content on whatever stream you want, but for standard notification definitions,

[KENT] Right, assuming the server advertises "ietf-netconf-notifications"...

Thanks,
Kent

---

From: Andy Bierman <[email-masked]>
Date: Wed, 4 Jun 2014 10:58:02 -0700

On Wed, Jun 4, 2014 at 10:37 AM, Kent Watsen <[email-masked]> wrote:

>
>     Does the section above suggests, that notifications from all 20
>> streams should be also be sent in a NETCONF stream ?
>>
>>
>  [KENT] really?  I always thought that "all" meant "all"?   Wasn't the
> motivation to guarantee access all the events?
>
>
   the NETCONF server.

It says "NETCONF XML".
Does this imply that a SYSLOG text stream also needs to be wrapped in XML
and sent as a <notification> element on the NETCONF stream?  I hope not.

Probably needs clarification. ;-)

Andy

> "ietf-netconf-notifications"...
I was pointing out that the RFC explicitly requires NETCONF stream support.
I suppose all YANG notification-stmts advertised by the NETCONF server
need to be in the NETCONF stream.

Andy

---

From: Giles Heron <[email-masked]>
Date: Wed, 4 Jun 2014 19:30:00 +0100

Hi Andy,

> and sent as a <notification> element on the NETCONF stream?  I hope not.

agreed.

but would you ever send a syslog text stream in using NETCONF notifications?  I thought all NETCONF notifications were XML-formatted?  So if you were sending SYSLOG over NETCONF presumably you'd wrap it in XML first?  So then it'd be "NETCONF XML" :)

> Probably needs clarification. ;-)

yup.

Giles

---

From: Kent Watsen <[email-masked]>
Date: Wed, 4 Jun 2014 18:31:12 +0000

> and sent as a <notification> element on the NETCONF stream?  I hope not.

My interpretation is that the NETCONF stream contains all notifications defined by all YANG modules advertised by the device.    Only problem is the RFC5277 doesn't mention YANG anywhere...

That reading would exclude SYSLOG messages, thankfully.

> Probably needs clarification. ;-)

Right, e.g., what is "NETCONF XML" ?

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 04 Jun 2014 21:42:03 +0200 (CEST)

Andy Bierman <[email-masked]> wrote:
> are expected to show up on the NETCONF stream.

RFC 6470 is explicit about this:

   This module defines the following notifications for the 'NETCONF'
   stream ...

> You can put whatever

There's nothing in 6020 that says in which stream a YANG-defined
notification is sent.  I don't agree that all YANG-defined
notifications MUST be sent over the "NETCONF" stream.

I do agree that this text in 5277 is unclear:

  This stream contains all NETCONF XML event notifications supported
  by the NETCONF server

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 4 Jun 2014 13:38:29 -0700

On Wed, Jun 4, 2014 at 12:42 PM, Martin Bjorklund <[email-masked]> wrote:

> by
So you are suggesting the RFC that defines the notification-stmts
should decide the appropriate streams?  OK

> notifications MUST be sent over the "NETCONF" stream.

OK -- but each RFC that defines any notifications MUST be explicit about
which streams are mandatory to support.  (we only have 1 to choose from now
but that may not be true forever).

>   This stream contains all NETCONF XML event notifications supported

It certainly does suggest all notifications sent in the NETCONF protocol
that are encoded in XML.  As pointed out, that could all of them
since the <notification> element encoded in XML is the only official message
allowed.

A NETCONF notification has to conform to this XSD:

     <!-- <Notification> operation -->
     <xs:complexType name="NotificationContentType"/>

    <xs:element name="notificationContent"
        type="NotificationContentType" abstract="true"/>

    <xs:complexType name="NotificationType">
        <xs:sequence>
            <xs:element name="eventTime" type="xs:dateTime">
              <xs:annotation>
                <xs:documentation>
                The time the event was generated by the event source.
                </xs:documentation>
              </xs:annotation>
            </xs:element>
            <xs:element ref="notificationContent"/>
        </xs:sequence>
    </xs:complexType>

    <xs:element name="notification" type="NotificationType"/>

Note the child <eventTime> element followed by a single element that
conforms to the "notificationContent" complex type?

  notification foo;

  <notification>
     <eventTime>...</eventTime>
     <foo>
        .... could be anything; empty, string, or complex node
     </foo>
  </notification>

All notifications from any stream could conform to this schema.
But what is the intent of the NETCONF WG wrt/ usage of streams?
My recollection is that for other usage  "syslog" was used as the
use-case, but never actually defined in any way.

There is no intent to create duplicate events (I hope).
If 2 streams are just different encodings (of the <foo> element)
then it makes no sense to add them to the NETCONF stream.
It would be nice if the client had some way of knowing what
notification events to expect on which stream (after parsing all
the YANG modules in the server <hello> message).

Without further notification work, IMO the "all" means everything.
There is only 1 standard stream. Until there are more than 1,
any new standards work would just constrain vendors.

Andy

---

From: t.petch <[email-masked]>
Date: Thu, 5 Jun 2014 09:46:04 +0100

----- Original Message -----
From: "Kent Watsen" <[email-masked]>
To: "Andy Bierman" <[email-masked]>
Cc: "Boris Pilka" <[email-masked]>; "Netconf" <[email-masked]>
Sent: Wednesday, June 04, 2014 7:31 PM
by
> and sent as a <notification> element on the NETCONF stream?  I hope
not.

My interpretation is that the NETCONF stream contains all notifications
defined by all YANG modules advertised by the device.    Only problem is
the RFC5277 doesn't mention YANG anywhere...

<tp>
No reason why it should!  NETCONF came first, and RFC4741 makes no
mention of any modelling language, so there is no reason for RFC5277 to
do so either.

Recall that YANG is an afterthought, formally introduced only in
RFC6241.

XML is required, YANG, I hope, not.

Tom Petch

---

From: Radek Krejčí <[email-masked]>
Date: Thu, 05 Jun 2014 11:13:05 +0200

Dne 4.6.2014 20:31, Kent Watsen napsal(a):
> My interpretation is that the NETCONF stream contains all
> notifications defined by all YANG modules advertised by the device.  
>  Only problem is the RFC5277 doesn't mention YANG anywhere...

I understand the text the same way and libnetconf implements it this
way. RFC says "all NETCONF XML event notifications supported by the
NETCONF server", not "all standard event notifications".

Radek

-- 
Radek Krejci
mobile  : +420 732 212 714
office  : +420 234 680 256
e-mail  : [email-masked]
LinkedIn: http://www.linkedin.com/in/radekkrejci

CESNET
Association of Legal Entities
160 00 Praha 6, Zikova 4
Czech Republic

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 05 Jun 2014 11:18:27 +0200 (CEST)

> NETCONF server", not "all standard event notifications".

But this indicates that *all* notifications are always sent over the
'NETCONF' stream.  I.e., you cannot have a notification sent on some
stream, but not on 'NETCONF'.

I don't think this was the intention with the 'NETCONF' stream.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 5 Jun 2014 11:24:11 +0200

On 05 Jun 2014, at 11:13, Radek Krejčí <[email-masked]> wrote:

> I understand the text the same way and libnetconf implements it this way. RFC says "all NETCONF XML event notifications supported by the NETCONF server", not "all standard event notifications”.

I wonder, isn’t it another conformance-related issue? A simple server may implement a YANG module but not its notifications, perhaps because it doesn’t implement notifications in the first place. Then, a server implementing only the NETCONF stream might send all notifications in it but another server may use a more fine-grained approach.

So probably there should be a way for the server to declare to the client how notifications are organised.

Lada 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Radek Krejčí <[email-masked]>
Date: Thu, 05 Jun 2014 11:27:19 +0200

> I don't think this was the intention with the 'NETCONF' stream.

ok, but what was the intention? Because I don't get the other
interpretation from the text :)

Radek

---

From: "Matus Fabian -X (matfabia - Pantheon Technologies SRO at Cisco)" <[email-masked]>
Date: Thu, 5 Jun 2014 09:44:54 +0000

Hi,

If we extend stream list data which is described in RFC-6277 (reply of get operation for the list of available event streams) client will be able to see notification associated with  stream.
I suggest add following into /netconf/streams/stream

  list module {
    description "List of modules and notifications associated with this stream.";
    key module-name;
    leaf module-name {
      type string;
      description "Name of the module.";
    }
    leaf-list notification {
      type string;
      description "Name of the notification.";
    }

Regards,
Matus

-----Original Message-----
From: Netconf [mailto:[email-masked]] On Behalf Of Ladislav Lhotka
Sent: Thursday, June 05, 2014 11:24 AM
To: Radek Krejčí
Cc: Boris Pilka -X (bpilka - Pantheon Technologies SRO at Cisco); Netconf
Subject: Re: [Netconf] Should Default Event Stream contain really all the notifications ?

On 05 Jun 2014, at 11:13, Radek Krejčí <[email-masked]> wrote:

>> > Does this imply that a SYSLOG text stream also needs to be wrapped 
>> > in XML and sent as a <notification> element on the NETCONF stream?  I hope not.
>> 

Lada

---

From: Giles Heron <[email-masked]>
Date: Thu, 5 Jun 2014 12:43:16 +0100

Agreed, and I think while we're at it perhaps we should change the XML schemas in the doc to YANG?

And I suspect it's also worth changing the wording in RFC5277 to make it explicit that the NETCONF stream is only used for "meta-notifications" (i.e. notifications about the operation of NETCONF such as the base notifications defined in RFC6470).

Also it may also be worth considering adding the ability to change filters without dropping the session and starting again (section 6.5 currently states that you can't modify subscriptions or create multiple subscriptions on the same session).  In fact given that there's an option to interleave subscriptions with other NETCONF operations it might also be worth having the ability to delete a subscription.  One option for modifying a subscription could then be to delete it and create a new one - though I guess there's a risk of missing any notifications sent between the delete and the create.

Chairs - is it worth kicking off an "RFC5277-bis" effort?

Giles

---

From: Andy Bierman <[email-masked]>
Date: Thu, 5 Jun 2014 07:45:36 -0700

On Thu, Jun 5, 2014 at 2:24 AM, Ladislav Lhotka <[email-masked]> wrote:

> way. RFC says "all NETCONF XML event notifications supported by the NETCONF
> server", not "all standard event notifications”.
>
> I wonder, isn’t it another conformance-related issue? A simple server may
> implement a YANG module but not its notifications, perhaps because it
> doesn’t implement notifications in the first place. Then, a server
> implementing only the NETCONF stream might send all notifications in it but
> another server may use a more fine-grained approach.
>
>

The conformance model seems clear enough:

  1)  :notification:1.0 capability MUST be advertised or else
notification-stmt
       is not relevant for this server

  2) if YANG module capability "foo" advertised then all notification-stmts
      that are in the "base" module MUST be supported in the NETCONF stream

  3)  if YANG module capability "foo" advertised then all notification-stmts
      that are conditional via YANG features MUST be supported in the
NETCONF stream
      if all if-feature-stmts within the notification-stmt are true.

  4) Not clear if notifications not defined in YANG must be supported.
 Since our standard
      conformance model is for YANG only, this seems out of scope (up to
vendor to use
      NETCONF stream or not)

> how notifications are organised.
When we get a 2nd standard notification stream, then I will agree with this
effort.
Until then, we have 1 stream called NETCONF that contains every event.

I think it helps to have an architecture for notifications.

  1) an event occurs in the system
  2) the NETCONF server detects the event
  3) the NETCONF server generates an internal event notification
  4) the NETCONF server picks 1 or more streams for the event notification
      and renders a message for each stream.  For NETCONF stream that means
      use XML encoding and honor replay-buffer requirements.

In this interpretation, it makes no sense at all to talk about combining
streams
because each stream contains different representations of the same events.

Lada
Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 06 Jun 2014 11:42:04 +0200

>        is not relevant for this server

This should be stated somewhere because the other interpretation may be that a server has to support notification in order to be able to implement a module that defines notification(s).

> Until then, we have 1 stream called NETCONF that contains every event.

Currently, there probably isn't any mechanism for the client to discover in which stream a particular YANG-defined notification is sent, unless the streams are user-configurable.

It might be useful to extend the "stream" subtree/resource with this info.

Lada