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

Hi Andy,

Please see inline: 

-----Original Message-----
From: Andy Bierman [mailto:biermana@Brocade.com] 
Sent: Wednesday, March 09, 2011 4:58 PM
To: Muthumayan Madhayyan (muthu); Internet-Drafts@ietf.org;
i-d-announce@ietf.org
Cc: netconf@ietf.org
Subject: RE: [Netconf]
I-DAction:draft-ietf-netconf-system-notifications-03.txt

Hi,

answers inline.

Andy

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

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 ?

[ab: a config-false list does not need a key.
The server is free to retain and report as much detail as it wants.

[muthu > ] OK. 

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

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

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 ?

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

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 ? 

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

[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

-----Original Message-----
From: netconf-bounces@ietf.org [mailto:netconf-bounces@ietf.org] On
Behalf Of Internet-Drafts@ietf.org
Sent: Tuesday, March 08, 2011 3: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-notificati
ons-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