Subject: Re: [netmod] Modeling NETCONF Event Notifications

From: Randy Presuhn <[email-masked]>
Date: Thu, 5 Jul 2012 21:49:57 -0700 (GMT-07:00)

Hi -

More lessons learned with CMIP and SNMP: There are some real
advantages to making some generic pieces of notifications
effectively mandatory *and* encoding them at an outer level.

Specifically:
   - doing so makes very basic notification discrimination (both
     at sender and receiver) easier.  This is an especially
     big win for generic logging facilities that need to figure
     out what to do with a notification when they're not able
     to fetch the necessary schema at the moment
   - this in turn makes basic throttling easier
   - it allows basic and "fancy" filtering / logging / etc. to
     be handled as distinct sets of conformance requirements
   - extensibility at the outer level can end up being more trouble
     than it's worth
   - the choice of things to include in the outer level needs
     to be made very carefully

Randy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 6 Jul 2012 09:05:04 +0200

>      to be made very carefully

Well, this is what we have. The problem is that there is not way to
add stuff to it, things that go into every notification. Can you
elaborate why "extensibility at the outer level can end up being more
trouble than it's worth"?

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 6 Jul 2012 10:21:11 -0700

Hi -

> From: "Juergen Schoenwaelder" <[email-masked]>
> To: "Randy Presuhn" <[email-masked]>
> Cc: <[email-masked]>
> Sent: Friday, July 06, 2012 12:05 AM
> Subject: Re: [netmod] Modeling NETCONF Event Notifications
...
> The problem is that there is not way to
> add stuff to it, things that go into every notification.

>From a compatibility perspective, this is a feature,
not a bug, IMO.

> Can you

Netconf and CMIP are similar in effectively requiring a generic notification
receiver to be able to dynamically learn schemas to *understand* payloads
from hitherto unheard-of devices.  Even if the entity processing a notification
has the necessary code in place,  network connectivity issues (for example)
may prevent it from acquiring those schema definitions in a timely manner.
This is the core of the argument for separating the "outer" stuff from the
"inner" stuff syntactically.  Adding an extensibility requirement to the "outer"
stuff negates the advantages of the separation.

Randy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 6 Jul 2012 10:36:49 -0700

> trouble than it's worth"?

I agree.   It was probably an oversight that the XSD is not extensible.
Some header fields like sequence-id, severity, class, etc. were considered
at the time, but the WG only agreed on 1 timestamp.

The original issue is still the key -- no matter how the notification
content is defined,
the client needs some way of knowing what content to expect.  That could be done
with a hard-wired capability URI, like notification:1.1.  The
notification format
to use would need to be negotiated in the <hello>, similar to base:1.0
and base:1.1.

It would be much more work to extend YANG to support augmentation of
the notification element.  IMO, there is no rush to update YANG to support
this, but it should be considered in the future.  This approach would break
the contract implied by the notification:1.0 capability, so it doesn't
really work
unless a notification:1.1 capability is also defined.

> /js

Andy

---

From: "Randy Presuhn" <[email-masked]>
Date: Fri, 6 Jul 2012 11:28:17 -0700

Hi -

> From: "Andy Bierman" <[email-masked]>
...
> at the time, but the WG only agreed on 1 timestamp.

The experience reported so far suggests that timestamp is not enough.
Otherwise we wounldn't be having this discussion.

> to use would need to be negotiated in the <hello>, similar to base:1.0

An alternative (too late now, though) is for the syntax of those mandatory
"outer" elements to be part of the base protocol.  One of the subtler
consequences (something SNMP got mostly right and CMIP got slightly less
right) is that the base protocol needs to knw about the naming architecture
(structure and syntax, not necessarily the semantics of instance names,
unless you add ad hoc matching rules, the latter being a big mistake IMO).

Randy