Subject: [Netconf] js comments on draft-ietf-netconf-system-notifications-03

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 29 Mar 2011 10:14:22 +0200

Hi,

I have reviewed this document and overall it seems to be a in a very
good shape.

a) I am not a big fan of the term "netconf system notifications" since
   system is rather ambiguous. I suggest to replace this phrase with
   "netconf server notifications". This seems to be also more inline
   with say 2.1.1, where the document says:

   [...] to notify a client application that the NETCONF server state
   has changed.

   I know, this causes a number of changes (include a name change of
   the module and of the title of the document) but I am even willing
   to help with the edits. ;-)

b) There are some terminology issue related to the terms 'event' and
   'notification'. In my preferred model, an 'event' is something that
   happens and that can lead to a 'notification'. This seems to be also
   the terminology used in RFC 5277.

   There are a number of places where changes are needed, e.g.:

      This module defines some events for the 'NETCONF' stream to notify a
      client application that the NETCONF server state has changed.

   A notification stream carries notifications, not events.

     "This module defines an YANG data model for use with the
      NETCONF protocol that allows the NETCONF client to
      receive common NETCONF system notification events.

   s/NETCONF system notification events./NETCONF server notifications./

     - or -

   s/NETCONF system notification events./notifications about common NETCONF server events/

      This document defines a YANG module for reporting of particular
      system events.

    s/of particular system events/NETCONF server events/

c) The security considerations obviously need some more text, likely
   pointing to the security considerations of 4741bis and RFC 5277. It
   might be useful to mention that the notifications can be used to
   detect unexpected NETCONF sessions and unexpected configuration
   changes.

   A statement such as "no specific information in this module is
   considered sensitive" might be problematic, given that the
   netconf-config-change for example tells you quite a bit about where
   in the config a change occured. Even session start and end times
   might be sensitive if you can associate sessions to people. I
   suggest to simple remove this statement.

/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: Martin Bjorklund <[email-masked]>
Date: Tue, 29 Mar 2011 12:36:10 +0200 (CEST)

Hi,

Juergen Schoenwaelder <[email-masked]> wrote:
>    "netconf server notifications".

I disagree.  I'd rather call it "system notifictions over NETCONF" or
something, to indicate that the notifications are related to more than
just the NETCONF server.  The way I see it is that (most of) these
*events* happen in the "system", and this document defines NETCONF
*notifications* representing these events.

[In fact, there's an embryo of a discussion about this in 
http://www.ietf.org/mail-archive/web/netconf/current/msg06576.html.
AFAIK, this was never resolved.  Maybe we should start by trying to
resolve this issue.]

Maybe the term "system" is ambigous, but it seems to have worked for
the system group in SNMP.

The only notification that is can be said to be tied to the NETCONF
server, and not the "system", is netconf-capability-change.  But even
this is not always true - if the new capability is a new data model,
that is not internal to the NETCONF server, is is really a function of
the system.  If the new capability is something like :xpath, then it
is a NETCONF server internal thing.

I also have some other comments on this document.

o  notification netconf-config-change

   I think the description should state if this notification is
   generated on a reboot or not.  E.g., if running and startup were
   different when the box rebooted, running has now changed.  Do we
   get a notification in this case?  What if a new startup file was
   used?

o  list edit in netconf-config-change

   State that it is ok to omit this list if the diff is not known.
   Also state that edit entries can be present even if the change is a
   result of something else than a NETCONF edit-config.

o  leaf killed-by in netconf-session-end

   This leaf exists only when the termination-reason is 'killed'
   (should it be mandatory?).

   enum killed says:

             "The session was terminated with
             the NETCONF <kill-session> operation.";

   and description of the leaf says:

         "Session ID that issued the <kill-session>
         if the session was terminated by this operation.";

   so the enum is 'killed' only if the session was killed with
   <kill-session>.  Thus the text that says "... if the session was
   terminated by this operation" is redundant.  We already know that
   the session was terminated by this operation.

   However, don't we want the termination-reason to be 'killed' if the
   session was killed from e.g. the CLI?

o  notification netconf-confirmed-commit

   s/confirm-commit/confirmed commit/g   (?)

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 29 Mar 2011 12:46:25 +0200

> *notifications* representing these events.

But I think this is not true for the notifications the document
actually defines.

    netconf-config-change:

	Generated when the NETCONF server detects that the
        <running> or <startup> configuration datastore has changed.

    netconf-capability-change

	Generated when a <capability> is added, deleted,
        or modified.

    notification netconf-session-start

	Generated when a new NETCONF session is started.

    notification netconf-session-end

	Generated when a NETCONF session is terminated.

    netconf-confirmed-commit

	Generated when a confirmed-commit event occurs.

They _all_ seem to be NETCONF server related notifications.

> is a NETCONF server internal thing.

You consider netconf-session-start/netconf-session-end is not NETCONF
server specific? You consider netconf-confirmed-commit is not NETCONF
server specific? A capability change notification says the
capabilities supported by the NETCONF server have changed. The newly
announced capability may be a system feature change.

Perhaps this discussion is just more evidence that we should avoid
the word system. ;-)

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 29 Mar 2011 13:42:28 +0200 (CEST)

>         <running> or <startup> configuration datastore has changed.

This text clearly says that the notification is generated when the
NETCONF server detects the event, which presumably means that the
event happens outside the server.

> 	Generated when a <capability> is added, deleted,

As I said, the capability addition is the way to report that the
system e.g. loaded a new module.  The event is that the system for
example supports a new feature (maybe a licence was installed for
'routing').

> 	Generated when a NETCONF session is terminated.

I would like these to have broader scope.  I think we've discussed this
in the past.  I think these notifications could be generated also when a
CLI session starts/ends, or a Web session, or whatever.  

> 	Generated when a confirmed-commit event occurs.

Devices that support this likely support this in the native system,
not just in the NETCONF server.  In fact, I don't think you can
implement this correctly w/o support from the underlying system (data
store etc).  I'm pretty sure that the feature is also available in the
CLI for such devices.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Tue, 29 Mar 2011 16:14:51 +0200

> event happens outside the server.

So you agree that this notification carries the event that the server
detected the change, not the change event of the system's configuration
itself. Good we agree that this is a NETCONF server notification. ;-)
 
> example supports a new feature (maybe a licence was installed for

The event carries forward that the NETCONF server supports a new
capability or lost a capability. This might be related to a change of
the system's features, but it does not necessarily have to be.  Nor
can you be sure that changes of the system's features always lead to a
change of the NETCONF capabilities.

> CLI session starts/ends, or a Web session, or whatever.  

I doubt it is workable nor desirable to make this an open ended "some
interesting transport session started/ended" notification.

> store etc).  I'm pretty sure that the feature is also available in the

You have not convinced me yet. ;-)

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 29 Mar 2011 16:37:03 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> itself.

No, it states the obvious that the notification is generated when the
NETCONF server detects the event (it would be interesting if it was
generated _before_ the event was detected :).  I think the
notification represents the change event of the system's
configuration.

> Good we agree that this is a NETCONF server notification. ;-)

Sorry, no :)

> change of the NETCONF capabilities.

I agree that this notification represents two events - both that the
system's features has changed, and that the netconf server's internal
capabilities have changed (altough my guess is that this is not that
common, since it probably implies a software change of the netconf
server).

> interesting transport session started/ended" notification.

I don't see the point in having multiple lists for different mgmt
protocols.  Why list CLI, Web, SNMP (over ssh or something) in
separate lists?  Some devices might not support this, but that is
fine.

I want to avoid having N versions of this exact data model -
cli-session-start, cli-config-change, web-config-change,
snmp-config-change, etc.  This just makes it more difficult for the
client.  What is the advantage this approach?

/martin

---

From: Kent Watsen <[email-masked]>
Date: Tue, 29 Mar 2011 10:27:09 -0700

I view this capability (along with netconf:base and netconf-monitoring) as the first of a set of capabilities enabling basic element-level device management:

  - system management
  - hardware management
  - software management
  - license management
  - configuration management
  - user management
  - etc.

In general, I see each of these "capabilities" defining RPCs and notifications and, in very rare circumstances, configuration (abstract data-models).  So, for instance, the ":hardware" capability would define an RPC to fetch physical inventory on the device as well as define notifications for when hardware has been physically added/removed.

Now, back to this capability, it provides notifications for both "configuration management" (see above list) as well as for the netconf server itself (not listed above).  Both of these make sense, given that they reflect what the NetConf RFC defines, but I wouldn't name it "netconf system", "netconf server" or "system notifications over netconf", as none of them seem to accurately reflect its nature.   I might call it "netconf base notifications", since it mostly defines notifications that reflect the "netconf:base" protocol, or "netconf monitoring notifications", since it seems to provide notifications for when the various "monitoring" subtrees change.   [note: in the latter case, we might consider rev-ing the ietf-netconf-monitoring capability instead as notifications are for monitoring...]

Regarding notifications on netconf-sessions, I can accept them as needed in order to reflect the netconf-monitoring "/sessions" subtree, but I strongly resists the idea of expanding the scope to user sessions in general (i.e. cli, webui, etc.), as I believe that these notifications should be pushed out to a distinct "system" or "user" capability specific to the purpose.

Thanks,
Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Martin Bjorklund
Sent: Tuesday, March 29, 2011 10:37 AM
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] js comments on draft-ietf-netconf-system-notifications-03

Sorry, no :)

> You have not convinced me yet. ;-)

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

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 30 Mar 2011 09:30:31 +0200 (CEST)

Hi,

Kent Watsen <[email-masked]> wrote:
> Regarding notifications on netconf-sessions, I can accept them as needed in
> order to reflect the netconf-monitoring "/sessions" subtree, but I strongly
> resists the idea of expanding the scope to user sessions in general (i.e. cli,
> webui, etc.), as I believe that these notifications should be pushed out to a
> distinct "system" or "user" capability specific to the purpose.

So maybe we agree here.  I don't think a special notification for just
NETCONF user sessions is that useful, since that means we'd have to
define special notifications for CLI user sessions, Web user sessions,
etc.  I think this notif was originally called sys-session-start,
which is in line with what you suggested.

This argument is even stronger for things like config-change and
confirmed-commit.

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 30 Mar 2011 01:10:17 -0700

On 03/30/2011 12:30 AM, Martin Bjorklund wrote:
> Hi,
>
> Kent Watsen<[email-masked]>  wrote:

I don't agree with expanding the scope of this draft.

I could agree to allowing a server to optionally report external events
if it wants to do that (MAY, not SHOULD or MUST), but I do not want to
spend any effort on it (e.g., know the user name for session 0; all CLI sessions
show up as session 0; knowing exactly what happened in a config-change
done externally -- a server may report N external changes as 1 detected change,
which may lose some intermediate changes; a server may completely miss an
external CLI session start and/or CLI session end).

So this would mean the text will change to say the foo-event is generated if and when
the NETCONF server detects the foo-event, instead of directly coupling the foo-event
to a specific NETCONF operation.

> /martin

Andy

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 Mar 2011 11:38:58 +0200

> client.  What is the advantage this approach?

Lets not mix session-start with config-change. The config-change
wording is fine - you get a notification when the NC server detects a
config change. That is cool.

For session start/end, despite questions what an SNMP session
start/end really is, for tightly integrated implementations, it might
be easy to generate notifications for all management interfaces
(although not sure where "all" starts and ends). For loosely
integrated implementations, a requirement to report all will be hard
or close to impossible to implement.

So the solution could be to require that all NC session starts/ends
are reported and additional MGMT session starts/ends MAY be reported
at the discretion of the device. But forcing this would likely be a
failure. (And for SNMP, we lived so far with a session start/end
notification - so this is probably not even needed.)

/js

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 30 Mar 2011 11:40:15 +0200

> Now, back to this capability, it provides notifications for both "configuration management" (see above list) as well as for the netconf server itself (not listed above).  Both of these make sense,…

I think the term "NETCONF base notifications" is a reasonable way to
resolve this terminology issue.

/js

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 30 Mar 2011 11:45:16 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> failure.

MAY be reported is fine with me.  I agree that this cannot be a MUST
or SHOULD.

> (And for SNMP, we lived so far with a session start/end

One reason could be that there really are no sessions when UDP is
used...   But removing this notif would of course also make the
problem go away ;)

/martin