Subject: [Netconf] Confirmed commit timeout

From: Jonathan Hansford <[email-masked]>
Date: Thu, 05 Sep 2013 11:56:15 +0100

Hi, 

RFC 6241 appears to be quiet about notifying the client if a
confirmed commit times out. Is it a server implementation detail to
determine whether to send a notification to the client? I know event
notifications are an optional capability and may not be supported by
either the client or the server, but its seems odd that the appropriate
behaviour is not defined as, if the client is performing a series of
confirmed commits, how will it know whether previous confirmed commits
have timed out and been reverted? 

Thanks 

Jonathan

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Thu, 5 Sep 2013 13:02:10 +0200

> have timed out and been reverted? 

I think one of the really missing pieces in NETCONF is a config
revision number or a timestamp that can uniquely identify a certain
configuration. If such a thing would be available (as part of the
standards), I guess it would be much easier to address your questions
even without having to have notifications.

/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: Thu, 05 Sep 2013 13:06:51 +0200 (CEST)

Hi,

> have timed out and been reverted? 

The notification "netconf-confirmed-commit" in RFC 6470 does this.

This was standardized after 6241, which is the reason it is not
mentioned in 6241.  If we revise 6241, it would make sense to mention
this; even if notifications are still an optional capability.

/martin

---

From: Jonathan Hansford <[email-masked]>
Date: Thu, 05 Sep 2013 12:13:11 +0100

Hansford <[email-masked]> wrote:
>> Hi, RFC 6241 appears to
be quiet about notifying the client if a
>> notifications are an
optional capability and may not be supported by
>> either the client or
the server, but its seems odd that the appropriate
>> behaviour is not
defined as, if the client is performing a series of
>> confirmed
commits, how will it know whether previous confirmed commits
> The notification
"netconf-confirmed-commit" in RFC 6470 does this.
> This was
standardized after 6241, which is the reason it is not
> mentioned in
6241. If we revise 6241, it would make sense to mention
> this; even if
notifications are still an optional capability.

That's exactly what
I was looking for; I obviously just hadn't looked far
enough! Thanks.