Subject: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-03.txt

From: [email-masked]
Date: Tue, 08 Mar 2011 15:15:01 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Configuration Working Group of the IETF.

	Title           : Network Configuration Protocol System Notifications
	Author(s)       : A. Bierman
	Filename        : draft-ietf-netconf-system-notifications-03.txt
	Pages           : 13
	Date            : 2011-03-08

The NETCONF protocol provides mechanisms to manipulate configuration
datastores.  However, client applications often need to be aware of
common NETCONF system events such as a change in NETCONF
capabilities, which may impact management applications.  Standard
mechanisms are needed to support the monitoring of the NETCONF system
events within the NETCONF server.  This document defines a YANG
module which allows a NETCONF client to receive notifications for
some common events.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netconf-system-notifications-03.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Kent Watsen <[email-masked]>
Date: Wed, 9 Mar 2011 13:43:38 -0800

This I-D doesn't quite meet my needs and I'm wondering if it's because the I-D's scope isn't broad enough or because the plan is to have a complementary set of I-Ds fill in the void.  To clarify, our current NMS application is interested in the following kinds of events:

  - FRU added/removed
  - Software added/removed
  - Configuration changed
  - Interface up/down

I don't imagine every NMS to have the same interests and I even imagine ours will have new interests over time (i.e. user/policy/license added/removed, etc.).  So this makes me wonder what the plan is to accommodate these other events.  Will we continually update this RFC or will we lets other RFCs define their own events?  For instance, a RFC for managing hardware defines hardware-oriented notifications, a RFC for managing software defines software-oriented notifications, etc.

NITS
----

1. the "netconf-config-change" description says "An edit record will be present for each distinct edit operation on the target datastore."   How does this relate to implicit changes?  Can we be sure to indicate that the list of "distinct edit operations" reflects the final state of the target datastore and not necessarily what was passed in <edit-config>?

2. The description for modified-capability says "The new modified value of the complete URI is returned", but the description for added-capability and deleted-capability don't indicate if the complete or base URI are returned.  Assuming that it is intended that the complete uri is always returned, I suggest that the description for the top-level netconf-capability-change says that and we remove the word "complete" from the modified-capability description (i.e. should now read "The new modified value of the URI is returned.")

3. I'm still twisted about the "netconf-config-change" event not identifying *which* startup/running datastore was modified.  (i.e. Juniper's Dual REs or Yuma's "--startup" parameter).  Even though, as Martin points out, NetConf doesn't officially support more than one instance of a datastore and that a vendor-specific augmentation can be used, it's such a PITA.  Or maybe, to turn this around, should we now start defining an ability for NetConf to support more than one instance of datastores?

4. missing "Acknowledgements" section

5. s/parms/params/g  ---or--- s/parms/parameters/g

Thanks,
Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, March 08, 2011 6:15 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-03.txt

The NETCONF protocol provides mechanisms to manipulate configuration datastores.  However, client applications often need to be aware of common NETCONF system events such as a change in NETCONF capabilities, which may impact management applications.  Standard mechanisms are needed to support the monitoring of the NETCONF system events within the NETCONF server.  This document defines a YANG module which allows a NETCONF client to receive notifications for some common events.

Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.

---

From: "Muthumayan Madhayyan (muthu)" <[email-masked]>
Date: Wed, 9 Mar 2011 15:30:30 -0800

Hi:

1. In netconf-config-change notification, there is a list element called
'edit'. Is that really meant to be a list ? Is so, what is the key for
this list ? Also where is the type instance-identifier defined (would
that be in ietf-netconf ?). I presume that the motivation for sending
this instance information is for the NMS to do a partial retrieval of
config ?

2. Seems like the netconf-session-start and netconf-session-end is
primarily meant to track netconf user sessions. The prefix
netconf-session-* and the use of netconf specific enumerations like
'bad-hello' etc. seems to suggest that. However, the session-id in
common-session-parms seems to suggest that this notification can be sent
for non-NETCONF sessions as well. If so, some of the enumerations for
termination-reason don't really make sense. Would it help to state that
non-NETCONF terminations would be tracked under 'other' enum ?

3. In the grouping changed-by-parms, one of the choice is 'server'. What
is the use case where server can initiate a configuration change without
user intervention ? 

Thanks,
- muthu

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of [email-masked]
Sent: Tuesday, March 08, 2011 3:15 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Netconf] I-D
Action:draft-ietf-netconf-system-notifications-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Network Configuration Working Group of
the IETF.

	Title           : Network Configuration Protocol System
Notifications
	Author(s)       : A. Bierman
	Filename        : draft-ietf-netconf-system-notifications-03.txt
	Pages           : 13
	Date            : 2011-03-08

The NETCONF protocol provides mechanisms to manipulate configuration
datastores.  However, client applications often need to be aware of
common NETCONF system events such as a change in NETCONF capabilities,
which may impact management applications.  Standard mechanisms are
needed to support the monitoring of the NETCONF system events within the
NETCONF server.  This document defines a YANG module which allows a
NETCONF client to receive notifications for some common events.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netconf-system-notificati
ons-03.txt

---

From: Andy Bierman <[email-masked]>
Date: Wed, 9 Mar 2011 16:51:01 -0800

Hi,

Events other than config-change (on your) list are out of scope.
You can post a new I-D to the netmod WG I guess, proposing new work.

Nits answered inline.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: Wednesday, March 09, 2011 1:44 PM
To: [email-masked]
Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-03.txt

  - FRU added/removed
  - Software added/removed
  - Configuration changed
  - Interface up/down

NITS
----

[ab: the server is free to decide how to describe the
edits that took place and how much detail is preserved.
There is no canonical form of an edit defined.]

[ab: good point -- the full form of the URI is always given]

[ab: the target-datastore enum says it is running or startup.]

[ab: OK]

[ab: OK -- will use 2nd one]

Thanks,
Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Tuesday, March 08, 2011 6:15 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-03.txt

Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft.
_______________________________________________
Netconf mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/netconf

---

From: Andy Bierman <[email-masked]>
Date: Wed, 9 Mar 2011 16:57:55 -0800

Hi,

answers inline.

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Muthumayan Madhayyan (muthu)
Sent: Wednesday, March 09, 2011 3:31 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-03.txt

Hi:

[ab: a config-false list does not need a key.
The server is free to retain and report as much detail as it wants.
E.g.
Add to candidate:
   merge new /mylist[id=1] entry
   merge new /mylist[id=2] entry
Then <commit>.
A server may report this as 1 merge on /mylist or 2 merges
(1 on /mylist[id=1] and 1 on /mylist[id=2]).]

[ab: I can add a note stating that non-NETCONF sessions are
terminated as 'other'.]

[ab: a server may create config as a result of hardware change,
on initially when a fresh running config is created as the
factory default config.  The server may get some OOB request
to add a new VLAN for example, and could create non-default config.]

Thanks,
- muthu

---

From: Andy Bierman <[email-masked]>
Date: Wed, 9 Mar 2011 17:02:55 -0800

oops -- did not see your 'which' running or 'which' startup.

does not compute.  Clearly not supported by the standard.
There are only 1 of each datastore type, except N of <url>.
Without a rewrite of the protocol, architecture, partial-lock,
and every other protocol extension, there is no point adding
support for multiple (candidate, running, startup) datastores.

You can augment the notification with vendor leafs providing
this information about a vendor feature.

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Andy Bierman
Sent: Wednesday, March 09, 2011 4:51 PM
To: Kent Watsen; [email-masked]
Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-03.txt

Hi,

Nits answered inline.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Kent Watsen
Sent: Wednesday, March 09, 2011 1:44 PM
To: [email-masked]
Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-03.txt

  - FRU added/removed
  - Software added/removed
  - Configuration changed
  - Interface up/down

NITS
----

[ab: OK]

Thanks,
Kent

---

From: "Muthumayan Madhayyan (muthu)" <[email-masked]>
Date: Thu, 10 Mar 2011 12:09:19 -0800

Hi Andy,

Please see inline: 

-----Original Message-----
From: Andy Bierman [mailto:[email-masked]] 
Sent: Wednesday, March 09, 2011 4:58 PM
To: Muthumayan Madhayyan (muthu); [email-masked];
[email-masked]
Cc: [email-masked]
Subject: RE: [Netconf]
I-DAction:draft-ietf-netconf-system-notifications-03.txt

Hi,

answers inline.

Andy

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Muthumayan Madhayyan (muthu)
Sent: Wednesday, March 09, 2011 3:31 PM
To: [email-masked]; [email-masked]
Cc: [email-masked]
Subject: Re: [Netconf] I-D
Action:draft-ietf-netconf-system-notifications-03.txt

Hi:

[muthu > ] OK. 

E.g.
Add to candidate:

[muthu > ] Wouldn't it make sense to send some sort of identifier that
tags every commit operation (commit-id) ? If the NMS ever loses
connectivity with the server and regains connectivity later, it can
chose to sync up based on the commit-id. 

[muthu > ] Were you planning on defining the typedef instance-identifier
in this YANG module ?

[muthu > ] Ok.

[muthu > ] The factory default config makes sense. The OOB request I
presume is still a user request, coming in from some other manageability
interface (snmp perhaps?) - so shouldn't that be just considered
non-NETCONF config user request. In any case, there is a use-case for
'server' triggered configuration change.

Thanks,
- muthu

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 10 Mar 2011 22:04:07 +0100 (CET)

Hi,

> chose to sync up based on the commit-id. 

I agree that this would be very useful.  It has been discussed before,
when we did RFC 6022.  However, in order to be useful, a solution to
this would require more than just a "commit-id" in the notification.
The commit-id should also be available in the datastore list in RFC
6022.  And maybe even reported back in the reply to <commit>,
<edit-config>, and <copy-config> (depending on data store).  All this
could be done in a separate document (and YANG module) (hint, hint ;)

> [muthu > ] Were you planning on defining the typedef instance-identifier

instance-identifier is a built-in type in YANG.

> non-NETCONF config user request.

I agree.

> In any case, there is a use-case for

An example of a server initiated change is when the user sets "foo",
but as a result also "bar" is changed.

/martin