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

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: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Andy Bierman
Sent: Wednesday, March 09, 2011 4:51 PM
To: Kent Watsen; netconf@ietf.org
Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-03.txt

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: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Kent Watsen
Sent: Wednesday, March 09, 2011 1:44 PM
To: netconf@ietf.org
Subject: Re: [Netconf] I-D Action:draft-ietf-netconf-system-notifications-03.txt

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>?

[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.]

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.")

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

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?

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

4. missing "Acknowledgements" section

[ab: OK]

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

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

Thanks,
Kent

-----Original Message-----
From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org
Sent: Tuesday, March 08, 2011 6:15 PM
To: i-d-announce@ietf.org
Cc: netconf@ietf.org
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-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.
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf
_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf