Dear ADs (and WG),
As new WG chairs, we have carefully studied
the current WG charter
http://www.ietf.org/html.charters/netconf-charter.htmlAlthough
the date on the charter page states that it was last updated
on 2008-01-09,
that update was only to list us as new WG chairs and
our new Security
Advisor. The base text is from a while ago, and
in the meanwhile, some
documents have completed, and some of the
text that has past tense or
(future tense) is now better read as
being the present. We also adopted a
set of WG documents which
were based on earlier individual I-Ds, and so we
have completed
posting of revision 00 documents for our chartered WG work
items.
We have clarified the text, cleaned it up a bit and we have
marked
a few items as DONE. We made no substantial change (of course,
because that would require WG consensus forming first).
ADs, can
you please approve that this cleanup charter text be posted
as our current
WG charter page. Will you forward it to iesg-secretary,
or do we need to
do so seperately (assuming you will approve)?
Bert and
Mehmet
Attached is the new charter and a rfcdiff of old and new
charter.
And here is the main body of the cleaned-up charter
text:
Configuration of networks of devices has become a critical
requirement
for operators in today's highly interoperable networks.
Operators from
large to small have developed their own mechanisms or used
vendor
specific mechanisms to transfer configuration data to and from a
device, and for examining device state information which may impact
the configuration. Each of these mechanisms may be different in
various aspects, such as session establishment, user authentication,
configuration data exchange, and error responses.
The NETCONF
Working Group is chartered to produce a protocol suitable
for network
configuration, with the following characteristics:
- Provides
retrieval mechanisms which can differentiate between
configuration
data and non-configuration data
- Is extensible enough so that vendors
will provide access to all
configuration data on the device using a
single protocol
- Has a programmatic interface (avoids screen scraping
and
formatting-related changes between releases)
- Uses a
textual data representation, that can be easily manipulated
using
non-specialized text manipulation tools.
- Supports integration with
existing user authentication methods
- Supports integration with existing
configuration database systems
- Supports network wide configuration
transactions (with features such
as locking and rollback capability)
- Is as transport-independent as possible
- Provides support for
asynchronous notifications.
The NETCONF protocol is using XML for data
encoding purposes, because
XML is a widely deployed standard which is
supported by a large number
of applications.
The NETCONF protocol
should be independent of the data definition
language and data models used
to describe configuration and state
data.
However, the
authorization model used in the protocol is dependent on
the data model.
Although these issues must be fully addressed to
develop standard data
models, only a small part of this work will be
initially addressed. This
group will specify requirements for standard
data models in order to fully
support the NETCONF protocol, such as:
- identification of principals,
such as user names or distinguished names
- mechanism to distinguish
configuration from non-configuration data
- XML namespace conventions
- XML usage guidelines
The initial work started in 2003 and has
already been completed and was
restricted to following items:
a) NETCONF Protocol Specification, which defines the
operational model,
protocol operations,
transaction model, data model requirements,
security requirements, and transport layer requirements.
b) NETCONF
over SSH Specification: Implementation Mandatory,
c) NETCONF over
BEEP Specification: Implementation Optional,
d) NETCONF over SOAP
Specification: Implementation Optional.
These documents define
how the NETCONF protocol is used with each
transport protocol
selected by the working group, and how it meets
the security and
transport layer requirements of the NETCONF Protocol
Specification.
e) NETCONF Notification Specification, which defines mechanisms
that
provide an asynchronous message notification
delivery service for
the NETCONF protocol.
NETCONF Notification is an optional
capability
built on top of the base NETCONF definition and
provides the capabilities and operations necessary to
support
this service.
In the current phase
of the incremental development of NETCONF the
workgroup will focus on
following items:
1. Fine-grain locking: The base NETCONF protocol only
provides a lock
for the entire configuration datastore, which
is not deemed to meet
important operational and security
requirements. The NETCONF working
group will produce a
standards-track RFC specifying a mechanism for
fine-grain
locking of the NETCONF configuration datastore.
2. NETCONF monitoring:
It is considered best practice for IETF working
groups to
include management of their protocols within the scope of
the
solution they are providing. The NETCONF working group will
produce a standards-track RFC with mechanisms allowing NETCONF
itself to be used to monitor some aspects of NETCONF operation.
3.
Schema advertisement: Currently the NETCONF protocol is able
to
advertise which protocol features are supported on a
particular
netconf-capable device. However, there is currently
no way to discover
which XML Schema are supported on the
device. The NETCONF working
group will produce a
standards-track RFC with mechanisms making this
discovery
possible (this item may be merged with "NETCONF monitoring"
into a single document).
4. NETCONF over TLS: Based on implementation
experience there is a
need for a standards track document to
define NETCONF over TLS as an
optional transport for the
NETCONF protocol.
The following items have been identified as important
but are currently
not considered in scope for re-chartering and may be
candidates for work
when there is community consensus to take them on:
- General improvements to the base protocol
- Access Control
requirements
- NETCONF access to SMI-based MIB data
Goals and
Milestones:
Done Working Group formed
Done Submit initial Netconf Protocol draft
Done Submit initial Netconf over (transport-TBD)
draft
Done Begin Working Group Last Call for the
Netconf Protocol draft
Done Begin Working Group
Last Call for the Netconf over
(transport-TBD)
draft
Done Submit final version of the Netconf
Protocol draft to the IESG
Done Submit final
version of the Netconf over SOAP draft to the IESG
Done
Submit final version of the Netconf over BEEP draft to the IESG
Done Submit final version of the Netconf over SSH
draft to the IESG
Done Update charter
Done Submit first version of NETCONF
Notifications document
Done Begin WGLC of NETCONF
Notifications document
Done Submit final version
of NETCONF Notifications document to
IESG
for
consideration as Proposed Standard
Done -00 draft
for fine Grain Locking
Done -00 draft for NETCONF
over TLS
Done -00 draft for NETCONF Monitoring
Feb 2008 -00 draft for Schema Advertisement
Mar 2008 Early
Review of client authentication approach (for NETCONF
over
TLS) with the
security community at IETF 71
Aug 2008 WG Last Call on NETCONF
Monitoring after IETF72
Aug 2008 WG Last Call on Schema
Advertisement after IETF72
Aug 2008 WG Last Call on Fine Grain
Locking after IETF72
Aug 2008 WG Last Call on NETCONF over TLS after
IETF72
Aug 2008 Send four documents to the IESG for consideration as
proposed
standards