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

[Martin Bjorklund <[e-mail]>]

Hi,

"Muthumayan Madhayyan (muthu)" <[e-mail]> wrote:
> [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. 

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
> in this YANG module ?

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

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

I agree.

> In any case, there is a use-case for
> 'server' triggered configuration change.

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


/martin