[Netconf] FW: Protocol Action: 'Partial Lock RPC for NETCONF' toProposed Standard
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Netconf] FW: Protocol Action: 'Partial Lock RPC for NETCONF' toProposed Standard
Congratulations to the editors, chairs, and the whole WG for achieving
this milestone.
Regards,
Dan
-----Original Message-----
From: netconf-bounces at ietf.org [mailto:netconf-bounces at ietf.org] On
Behalf Of The IESG
Sent: Monday, October 26, 2009 5:46 PM
To: IETF-Announce
Cc: Internet Architecture Board; netconf mailing list; netconf chair;
RFC Editor
Subject: [Netconf] Protocol Action: 'Partial Lock RPC for NETCONF'
toProposed Standard
The IESG has approved the following document:
- 'Partial Lock RPC for NETCONF '
<draft-ietf-netconf-partial-lock-11.txt> as a Proposed Standard
This document is the product of the Network Configuration Working Group.
The IESG contact persons are Dan Romascanu and Ron Bonica.
A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-netconf-partial-lock-11.t
xt
Technical Summary
The NETCONF protocol defines the lock and unlock RPCs, used to lock
entire configuration datastores. In some situations, a way to lock only
parts of a configuration datastore is required. This document defines a
capability-based extension to the NETCONF protocol for locking portions
of a configuration datastore.
Working Group Summary
The working group went over several versions of the document. The
comments and reviews helped improve the document a lot and brought us to
consensus on the 7th revision of the docuemnt.
Document Quality
There are preliminary implementations of this protocol and updates to
comply with this spec are in plan. Others are planning to implement this
spec too.
Personnel
Bert Wijnen is the document shepherd, Dan Romascanu is the shepherding
AD.
_______________________________________________
Netconf mailing list
Netconf at ietf.org
https://www.ietf.org/mailman/listinfo/netconf
Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.