2.4.11 Network Configuration (netconf)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Addiotional NETCONF Web Page

Last Modified: 2004-09-22

Chair(s):

Simon Leinen <simon@switch.ch>
Andy Bierman <abierman@cisco.com>

Operations and Management Area Director(s):

Bert Wijnen <bwijnen@lucent.com>
David Kessens <david.kessens@nokia.com>

Operations and Management Area Advisor:

Bert Wijnen <bwijnen@lucent.com>

Technical Advisor(s):

Wesley Hardaker <hardaker@tislabs.com>

Mailing Lists:

General Discussion: netconf@ops.ietf.org
To Subscribe: netconf-request@ops.ietf.org
In Body: in msg body: subscribe
Archive: http://ops.ietf.org/lists/netconf

Description of Working Group:

Wes Hardaker is Technical Advisor for Security Matters

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 mechanims 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 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 will use XML for data encoding purposes,
because XML is a widely deployed standard which is supported
by a large number of applications. XML also supports hierarchical data
structures.

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

It should be possible to transport the Netconf protocol using several
different protocols. The group will select at least one suitable
transport mechanism, and define a mapping for the selected protocol(s).

The initial work will be restricted to the following items:

  - Netconf Protocol Specification, which defines the operational
    model, protocol operations, transaction model, data model
    requirements, security requirements, and transport layer
    requirements.

  - Netconf over <Transport-TBD> Specification, which defines how
    the Netconf protocol is used with the transport protocol
    selected by the group, and how it meets the security and
    transport layer requirements of the Netconf Protocol
    Specification.. There will be a document of this type for
    each selected transport protocol.

The working group will take the XMLCONF Configuration Protocol
<draft-enns-xmlconf-spec-00.txt> as a starting point.

Goals and Milestones:

Done  Working Group formed
Done  Submit initial Netconf Protocol draft
Done  Submit initial Netconf over (transport-TBD) draft
Dec 03  Begin Working Group Last Call for the Netconf Protocol draft
Jan 04  Begin Working Group Last Call for the Netconf over (transport-TBD) draft
Mar 04  Submit final version of the Netconf Protocol draft to the IESG
Apr 04  Submit final version of the Netconf over (transport-TBD) draft to the IESG

Internet-Drafts:

  • draft-ietf-netconf-prot-04.txt
  • draft-ietf-netconf-beep-02.txt
  • draft-ietf-netconf-soap-03.txt
  • draft-ietf-netconf-ssh-02.txt

    No Request For Comments

    Current Meeting Report

    OPS Area
    NETCONF WG Meeting Minutes
    IETF #61
    November 11, 2004
    Minutes by Juergen Schoenwaelder, edited by Andy Bierman

    Agenda

    - NETCONF WG Document Discussion
    - AOB

    Minutes

    1. Status

    The meeting started with a review of changes in the Protocol I-D since the last 03 draft. See the slides for the detailed list of changes. No questions were raised regarding the changes.

    Working group last call is running so people interested should carefully read the documents. Last call deadline is November 28, 2004.

    2. Data Models

    The group agreed to defer all data model issues to future work. This basically affects the mechanism to retrieve session ids. One proposal was to just do the instance document, others wanted to leave the definition in with a big warning that the definition is non-normative and subject to be replaced in the future. Yet others believed leaving it in casts this into stone forever. Another suggestion was to use a separate namespace so that this can be changed later on without loosing backwards compatibility.

    The group discussed the need for a minimal data model in the document, and was polled on whether to contain a minimal data model or no data model at all. Rough consensus in the room seemed to be to have the minimal data model (session-id element) specified. Andy Bierman will check on the list with a concrete proposal.

    After the meeting, a proposal was made on the mailing list to remove the netconf-state data model completely, since the session-id of the lock owner is returned in an <rpc-error> element.

    Any other netconf-state data model issues? None were raised.

    3. Lock semantics

    Wes Hardaker asks the question whether the lock should prevent read access. Interaction between copy-config and locking. Wes wants to have a recommendation that you should lock both configs if you do a copy-config. Wes really wanted to have a statement that locks should be raised together at the beginning of a transaction. Wes says that this affects also the behavior of get-config while there is someone modifying a configuration. The document should probably spell out these issues so that NETCONF users do not make false assumptions. Phil Shafer also suggests that there might be cases where one want to get access to configuration data, even if there is an existing lock.

    Wes says this is an instance of the general problem that the IETF does a poor job in documenting how something is being used. How much policy does belong in the mechanism specification? People are encouraged to write how to use NETCONF guides.

    4. XSD vs. Relax NG

    The question was raised whether the XSD in the protocol I-D should be converted to RELAX NG. The conclusion was that XSD for the protocol specification is fine as it is read by protocol implementors, which is different from data models which have a much larger audience of readers/writers.

    5. Data Modeling Standards Efforts

    The question was raised whether this is the right time for work to begin on standard data modeling for NETCONF (done by the IETF). Several organizations are currently looking at this area. There was concern raised regarding multiple data models. Andy says that there were always multiple data models and NETCONF won't change that, since standards work usually trails proprietary work. [ed. - Some people believe that basing standards on existing practice is a Good Thing.] There is a need to have common data models, the question is to do bottom up or top down. The real hard part is to identify and agree on the semantics. A bottom-up approach allows agreement to be reached on basic building blocks in a reasonable time-frame, but there is some risk of poor data organization and consistency across modules.

    Bert Wijnen raises the question whether this session turns into a BOF. He suggests to close the NETCONF session and move this to an informal discussion. Dave Harrington remarks that the question whether NETCONF wants to be re-chartered is a WG discussion item. However, since this topic was not on the agenda, the Bert suggested to close the meeting and continue with an informal discussion.

    WG meeting closed. Please read the drafts.


    Slides

    Introduction and Agenda
    Update on the NETCONF Protocol draft