Concepts and Requirements for XML Network Configuration
From: http://www.ietf.org/internet-drafts/draft-wasserman-xmlconf-req-00.txt
Internet-Draft M. Wasserman
Document: draft-wasserman-xmlconf-req-00.txt Wind River
Expires: December 2002 June 2002
Concepts and Requirements for XML Network Configuration
1 Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [RFC2026].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
2 Abstract
This document defines basic concepts and describes the requirements
for a standard network configuration protocol, which could be used
to manage the configuration of networks and networking equipment.
The document also discusses a phased approach to developing an XML-
based configuration protocol that could provide tangible benefits
in the short term, while working towards an XML-based configuration
protocol that meets the full requirements.
3 Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
4 Conventions Used In This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119
[RFC2119].
Wasserman Expires December 2002 1
Requirements for Network Configuration June 2002
5 Table of Contents
1 Status of this Memo.......................................1
2 Abstract..................................................1
3 Copyright Notice..........................................1
4 Conventions Used In This Document.........................1
5 Table of Contents.........................................2
6 Introduction..............................................3
7 Terminology...............................................3
8 Components of a Configuration Protocol....................4
9 General Requirements......................................5
9.1 Fits Modern Configuration Systems.........................5
9.2 Easy to Extend and Implement..............................6
9.3 Easy to Develop Client-Side Tools.........................8
9.4 Security..................................................8
9.5 Internationalization......................................9
10 Data Model Requirements...................................9
11 Data Modeling Language Requirements......................10
12 Data Representation Requirements.........................11
13 Protocol Operations Requirements.........................11
13.1 Operations on Configuration Blocks.......................12
13.1.1 Operations on Whole Configurations.......................12
13.1.2 Operations on Partial Configurations.....................13
13.2 Operations on Configuration Data Objects.................13
13.3 Validating Configurations................................13
13.4 Transaction Handling.....................................14
13.4.1 Single-Device Transactions...............................14
13.4.2 Multiple-Device Transactions.............................14
14 Protocol Messaging Requirements..........................15
14.1 Protocol Message Types...................................15
14.2 Authentication of Protocol Messages......................15
14.3 Privacy of Protocol Messages.............................15
15 Protocol Transport Requirements..........................16
16 Approach to XML Configuration............................16
16.1 Phase Zero: Investigate Technical Options...............16
16.2 Phase One: XML over Secure Transport....................17
16.3 Phase Two: XML Operations on Configuration Blocks.......17
16.4 Phase Three: XML Operations on Data Objects.............17
16.5 Phase Four: Multi-System Transactions using XML.........18
17 Security Considerations..................................18
18 References...............................................18
19 Acknowledgements.........................................18
20 Author's Contact Information.............................18
Wasserman, Editor Expires May 2002 2
Requirements for Network Configuration June 2002
6 Introduction
This document contains a set of requirements for a standard, XML-
based protocol to manage the configuration of networks and
networking equipment. These technical requirements have been
derived from several sources, including public and private
discussions with network operators regarding their requirements,
discussions with networking equipment vendors regarding the
configuration properties of networking equipment, and my own
opinions on the subject.
These requirements are listed in logical order. No prioritization
should be inferred from the structure of this document.
This document also proposes a staged approach to the development of
XML configuration technology within the IETF. The early stages
will provide tangible benefits to the Internet community, while
building towards a protocol that will meet the requirements
outlined in this document.
This version of the document is a rough first draft, and is
intended to serve as a strawman for a discussion of configuration
requirements at an XML Configuration BOF, to be held at IETF54 in
Yokohama, Japan in July 2002.
It is understood that this document will require significant
modification and enhancement to represent the full set of
requirements for an XML configuration protocol. This document
should be updated and completed later, if there is sufficient
interest to continue this work within the IETF.
7 Terminology
ASN.1 Abstract Syntax Notation One
BER Basic Encoding Rules
DTD Document Type Declaration
MIB Management Information Base
PDU Protocol Data Unit
SNMP Simple Network Management Protocol
SOAP Simple Object Access Protocol
SSH Secure Shell
XML Extended Markup Language
[This section will be completed in a later draft. Right now, it is
just a placeholder for the acronyms that ought to be defined and
have references added.]
Wasserman, Editor Expires May 2002 3
Requirements for Network Configuration June 2002
8 Components of a Configuration Protocol
A configuration protocol can be broken down into several major
components:
- Data Model
The data model is the set of configuration information that
can be accessed via the configuration protocol. For
example, the SNMP data model defines a string of 7-bit ASCII
octets that contains human-readable contact information for
the owner or operator of a piece of networking equipment
(sysContact).
- Data Modeling Language
A data modeling language is used to define the data model.
For example, the SNMP data modeling language is a subset of
ASN.1, defined as SMIv2.
A single data model might be represented in more than one
data modeling language. However, data modeling languages do
restrict the data types and structure types that can be used
to define the data model. So it may be possible to
construct a data model in one data modeling language that
cannot be fully represented in another data modeling
language.
It is a base assumption that an XML configuration protocol
will use some form of XML as a data modeling language.
- Data Representation
A well-defined data representation is used to pass data
between systems in a system-independent fashion. For
example, ASN.1 BER encoding is used as the data
representation for SNMP.
It is a base assumption that an XML configuration protocol
will use XML for data representation.
- Protocol Operations
A configuration protocol largely consists of a set of
operations that can be performed on configuration data. For
instance, SNMP supports the following operations: GET, SET,
GET-NEXT, GET-BULK, NOTIFY. Other management protocols
support additional operations, such as ADD and DELETE.
- Protocol Messages
Protocol operations and their results are communicated
between two systems in protocol messages (operation
Wasserman, Editor Expires May 2002 4
Requirements for Network Configuration June 2002
requests, operation responses, etc.). Different types of
protocol messages may have different formats, and protocol
messages may include configuration data, represented using
the data representation.
For example, SNMP PDUs are protocol messages, and there are
several defined PDU types.
- Protocol Transport
Protocol messages will be transmitted using a set of
underlying transport protocols. In the case of SNMP, PDUs
are transported over UDP/IP. It is also possible to use a
higher-level protocol, such as SSH or BEEP, as a protocol
transport.
This document outlines the general requirements for a configuration
protocol, and the requirements for each of the components described
above.
9 General Requirements
This section contains general requirements for a configuration
protocol. These requirements must be met in order for a new
configuration protocol to achieve acceptance among operators and
vendors.
9.1 Fits Modern Configuration Systems
To be useful to operators, a configuration protocol must fit into
modern systems for managing configuration data. These systems
typically include a database that contains the canonical
configuration information for the entire network. Mechanisms
exist to:
- Generate the expected configuration of each piece of
networking equipment from the database in a common form.
- Post-process the database output into configuration
information that matches the configuration syntax of a piece
of networking equipment based on equipment type, vendor,
model and version.
- Periodically check the configuration of each piece of
networking equipment to make sure that it matches the
database. This involves dumping the configuration of the
device and comparing it to the processed database output.
- Update the configuration of a piece of networking equipment
when the database changes, or when its configuration no
longer matches the database. This involves determining the
difference between the current and target configurations and
constructing commands to move from the current configuration
to the target configuration with minimal changes.
Wasserman, Editor Expires May 2002 5
Requirements for Network Configuration June 2002
- Report configuration changes and updates to operators via a
logging mechanism, including full information about the
change. There should be no need to perform successive
queries to understand what was changed.
This type of system could be simplified and improved by the
existence of a widely implemented, standard configuration protocol
to manage the configuration of networking equipment. This document
discussed the requirements for that protocol.
This type of system places several high-level requirements on a
configuration protocol:
1. MUST be possible to query and modify all of the
configuration data on a device using a single mechanism.
Today, many network equipment vendors only support full
configuration through a proprietary command-line interface
(CLI).
2. MUST be possible to easily transform database output into a
set of configuration commands that the device will
understand. It must be possible to configure a replacement
device entirely from information held in the database.
3. MUST be possible to query the full configuration of a device
in a single transaction, such as the "config dump" support
included in the CLIs of most backbone routers.
4. MUST be possible to compare sets of configuration data, and
to generate the configuration commands needed to move from
one configuration to another, with minimal disruption of
state on the running device.
5. MUST include a mechanism to send full information about
configuration updates, suitable for inclusion in a log.
Many vendors currently use vendor-defined syslog messages
for this purpose.
6. MUST include a mechanism to generate detailed reports when a
change is made to the configuration.
9.2 Easy to Extend and Implement
As indicated above, a configuration protocol will only be useful if
it can be used to manage all of the configuration information on a
device.
Today, SNMP is available on many devices, and we have an extensive
data model described in the SNMP Management Information Base (MIB).
However, SNMP can only be used to manage a subset of the
configuration information available on most networking equipment.
Vendors develop CLI commands concurrent with the development of new
features, and SNMP is implemented later, if at all. Often,
Wasserman, Editor Expires May 2002 6
Requirements for Network Configuration June 2002
configuration data is implemented as read-only in vendor SNMP MIB
implementations, even when the standard MIB indicates read-write
access.
In discussion with vendors, three reasons emerge why SNMP is not
implemented, with full read-write support, for all new features in
a timely manner:
- Standard MIBs are not usually available for new protocols
when they are standardized by the IETF.
- It is difficult and time-consuming to develop proprietary
MIB extensions, because the SNMP data model does not map
easily onto the data structures used in most
implementations.
- Even when standard MIBs are available, it is difficult and
time-consuming to instrument SNMP MIBs, particularly GET-
NEXT and SET processing.
So, it is clear that a new configuration protocol will not be
successful unless it meets the following requirements:
1. Easily Extensible Data Model
It must be so simple to extend the data model that it will
be practical to require IETF working groups to define data
model extensions for configuration at the same time that
they standardize a new protocol, or a new version of a
protocol.
It must also be easy enough to extend the data model that it
is practical for vendors to provide proprietary extensions
to cover all of the proprietary configuration information in
their systems. This should include the ability to add new
fields to standard-defined structures, as well as the
ability to add new sets of configuration information to the
data model.
2. Easy to Instrument
SNMP was successfully optimized to allow for a very small,
simple, stateless agent. However, this required the MIB
instrumentation to handle complex transaction-related
issues, such as atomicity, locking and transaction
processing (test/commit/undo).
Any new configuration protocol should be optimized to make
it easy to instrument data model extensions on networking
equipment. To accomplish this, the protocol should deal
with as many of the complex transaction-related issues as
possible.
Wasserman, Editor Expires May 2002 7
Requirements for Network Configuration June 2002
9.3 Easy to Develop Client-Side Tools
Operators require the freedom to develop their own tools in their
favorite text-oriented scripting languages (Perl, awk, sed, etc.).
To avoid having to learn things twice, the same interface that is
available at the command-line MUST be callable from scripts.
Operators do not want to run specialized applications on the
client-side to access configuration data and process it into a form
that is accessible from scripts or the command-line. It must be
possible to directly access the configuration protocol using a
secure, text-oriented transport, such as SSH.
These needs impose several technical requirements on a
configuration protocol:
1. Human-Friendly Data Representation
The data representation used for configuration protocol
input and output (queries, responses, help messages, etc.)
MUST be human-readable and MUST contain information that is
useful to an operator who is using the configuration
protocol from the command-line.
2. Computer-Friendly Data Representation
The data representation MUST include well-defined
formatting, to allow for easy parsing by text processors and
scripting languages.
3. Textual Data Representation
In order to generate configuration input and to parse
configuration output using text-oriented scripting
languages, the data representation MUST be in a textual
form.
There is interest in using XML as the data representation for a
configuration protocol, because XML is a textual data
representation that provides a good compromise between a human-
friendly representation and a computer-friendly representation,
largely achieving both goals.
4. Secure, Text-Oriented Protocol Transport
The configuration protocol MUST be defined to use a secure,
text-oriented protocol transport.
9.4 Security
Security is a vitally important attribute for any management
protocol. The XML configuration protocol should provide both
security and privacy. The requirements in this area include:
1. Protocol operations MUST be authenticated.
2. Protocol operations MUST be protected against replay.
Wasserman, Editor Expires May 2002 8
Requirements for Network Configuration June 2002
3. Protocol messages MUST be encrypted.
4. Protocol messages MUST be protected against corruption or
intentional modification en route.
[Security requirements will be specified in more detail in a future
draft, hopefully by someone who understands security better than I
do.]
It is not necessary for the configuration protocol, itself, to meet
all of the security requirements. It is acceptable for some or all
of these requirements to be met by the protocol transport (i.e. TCP
could be leveraged to protect against accidental corruption en
route, SSH could be used to provide encryption, etc.).
9.5 Internationalization
The data model and data representation for text strings MUST
support international character sets. For instance, it should be
possible for operators to set the system contact information to
include their actual names and addresses.
[The requirements in this area should be improved by someone who
understands these issues much better than I do.]
10 Data Model Requirements
One of the most complex issues surrounding the definition of an
XML-based configuration protocol within the IETF will be the data
model.
The IETF has considerable effort invested in the SNMP data model,
represented in the standard MIBs. It is vital to leverage the SNMP
data model for any new configuration protocol, and it would be wise
to avoid the definition of an entirely new data model. However, it
would be hard to accept the limitations that the SNMP data
representation, SMIv2, has imposed on the data model.
Although further work is needed to determine our actual
requirements in this area, some requirements are clear in theory,
although perhaps mutually exclusive in practice:
1. An IETF-defined data model MUST leverage the existing SNMP
data model.
2. The data model MUST make a clear distinction between
configuration information and state information, and it MUST
be possible to query the full configuration of a device,
without retrieving all of the dynamic state information held
on the device. For example, it should be possible to query
the full configuration of a router, including static routing
and forwarding entries, without retrieving all of the
Wasserman, Editor Expires May 2002 9
Requirements for Network Configuration June 2002
dynamic entries in the router's routing and forwarding
tables.
3. The data model MUST support a wider range of types than the
SNMP data model. For example, it MUST support international
character sets in text strings and SHOULD support structured
data types (aggregates of basic data types).
4. The data model MUST be easy to extend. This includes the
ability to extend standards-defined data structures and the
ability to add new sets of configuration data to the data
model.
Fortunately, the earliest stages of the phased approach outlined
below will allow us to defer standardization of a data model for
configuration. The popularity of CLI-based configuration tools
demonstrates that it is possible to have a useful, widely deployed
configuration mechanism that does not include a standardized data
model.
11 Data Modeling Language Requirements
By definition, an XML configuration protocol would use an XML-based
data modeling language. Further exploration is required to
determine whether it would be better to use an XML schema or a DTD
to define configuration data.
There are some basic requirements for a data modeling language:
1. The data modeling language MUST, at a minimum, be capable of
representing the SNMP data model. This include the ability
to represent:
A. All SMIv2 data types and textual conventions,
B. Scalar variables, and
C. List of objects (i.e. one-dimensional arrays)
This requirement allows SNMP MIBs to be fully represented in the
XML-based data modeling language, so the XML configuration protocol
could potentially access all SNMP MIB data.
Some work has already been done on programmatic conversions from
SMIv2 to XML, and this work will be discussed at the XML
Configuration BOF in Yokohama.
2. In order to conveniently express the data included in most
complex programs, the data modeling language MUST support:
A. Basic object types (i.e. integers, and strings)
B. Basic objects with added semantics (i.e. counters)
Wasserman, Editor Expires May 2002 10
Requirements for Network Configuration June 2002
C. Structure types (aggregates of basic types)
D. Lists of basic objects
E. Lists of structured objects
3. The data modeling language MAY also support more complex
data structures than simple aggregates and lists, such as:
A. Complex table or tree representations
B. Singly-linked or doubly-linked lists
C. Lists within lists
4. In order to validate configurations (see below), the data
modeling language MUST support the ability to define a
function that can be invoked on a piece of networking
equipment, including input parameters and return values.
An important issue to resolve will be whether it should also be
possible to represent the XML configuration protocol's data model
in SNMP MIBs. This would allow all configuration data to be
monitored using SNMP. If required, this generates an additional
requirement for the data modeling language:
5. The data modeling language MUST be isomorphic to SMIv2.
Unfortunately, this requirement would severely restrict the
capabilities of an XML configuration protocol, and might be
mutually incompatible with other requirements, such as the ability
to easily extend the data model and represent a wider range of
types than can be represented in SMIv2.
Further effort is needed to resolve these trade-offs and to
determine the requirements for a data modeling language. However,
the early stages of the phase approach described below do not
require a standard data modeling language for XML configuration, so
it may not be necessary to immediately address these issues.
Ongoing work on a next generation SMI (in the SMIng WG) may
eliminate some of the restrictions associated with SMIv2.
12 Data Representation Requirements
By definition, an XML-based configuration protocol would use an
XML-based data representation. There is no requirement that the
data representation for an XML configuration protocol maps, in any
way, to the data representation used by other management protocols.
Detailed requirements for the data representation can also be
deferred to later stages, if the phased approach is adopted.
13 Protocol Operations Requirements
Wasserman, Editor Expires May 2002 11
Requirements for Network Configuration June 2002
A set of protocol operations defines the fundamental capabilities
of a configuration protocol. Some configuration operations deal
with opaque blocks of configuration information, representing whole
or partial device configurations. Other configuration operations
are performed on specific pieces of configuration data.
The approach described in this document suggests that a useful
configuration protocol could be defined that deals only with opaque
blocks of configuration information. The actual configuration
information could be represented in a form that is vendor-
proprietary.
Later work would define protocol operations to deal with specific
pieces of configuration data.
13.1 Operations on Configuration Blocks
An XML protocol should support a set of operations that deal with
opaque blocks of configuration data. These operations will allow
configuration data to be queried and modified, without requiring
the protocol to deal with individual pieces of configuration
information.
13.1.1 Operations on Whole Configurations
The XML configuration protocol MUST, at a minimum, support two
operations on whole configurations:
1. Dump Whole Configuration
The protocol MUST support a mechanism to dump the entire
configuration of a running piece of networking equipment.
It MUST be possible to dump configuration information
without dumping dynamic state information.
2. Restore Whole Configuration
The protocol MUST also support the ability to send a full
set of configuration data to a piece of networking
equipment. This information could be used to fully
configure a system, when first deployed or after a
catastrophic failure.
In addition to these two functions, there is a further requirement
for the server running on the networking equipment:
3. A piece of networking equipment SHOULD be able to update
its running configuration to match a downloaded
configuration block, with minimal disruption of state.
Essentially, this requires that an XML configuration server
include the ability to do a logical "diff" between two
configurations, and move from the current configuration to a
new configuration by executing the minimal set of
configuration changes required.
Wasserman, Editor Expires May 2002 12
Requirements for Network Configuration June 2002
13.1.2 Operations on Partial Configurations
It may also be useful to support operations on opaque blocks of
configuration data that represent partial system configurations.
For instance, it might be useful to dump and restore the
configuration for a single protocol or sub-system.
Further thought is required to determine how partial configurations
could be named and referenced. It might not be meaningful to
perform operations on blocks of data without a defined format for
configuration blocks. This may be as simple as stating that
configuration blocks consist of data in name/type/value triplets.
13.2 Operations on Configuration Data Objects
In addition to operations on blocks of data, the XML configuration
protocol will include operations to manipulate individual
configuration objects.
There are several basic requirements for operations on data
objects:
1. The protocol MUST include operations to access basic objects
(integers, strings, etc.).
2. The protocol MUST include operations to access structured
objects (aggregates of basic types).
3. The protocol MUST include operations to access lists of
objects.
4. Operations MUST be provided to get and set objects.
5. Operations MUST be provided to add and delete basic objects
from object lists.
13.3 Validating Configurations
It should be possible to use the XML configuration protocol to
validate the configuration of a piece of networking equipment.
This will typically involve invoking a special purpose function on
a device and checking the return from that function. For example,
it should be possible to verify a forwarding table configuration by
calling a forwarding function with an IP address. The return value
would indicate the next-hop information that would be used to
forward the packet.
Support for configuration validation implies several requirements
for an XML configuration protocol:
1. It MUST be possible to identify and invoke a function that
will run on the networking equipment.
Wasserman, Editor Expires May 2002 13
Requirements for Network Configuration June 2002
2. It MUST be possible to pass parameters to the function.
3. It MUST be possible to receive return values from the
function.
13.4 Transaction Handling
The transaction handling features of the XML configuration protocol
should be carefully considered and well defined. This includes
concepts such as locking, atomicity and roll-back.
Transaction processing generally consists of several steps:
- Test: Determines whether or not an operation is valid for
each piece of data.
- Perform: Actually performs the operation, saving
information that may be required for roll-back.
- Complete: Operation completed successfully, roll-back
information can be freed.
- Roll-Back: Return the configuration to its previous state.
This step is invoked when an error occurs after an operation
is partially completed, or when a timeout occurs before the
complete step is invoked.
13.4.1 Single-Device Transactions
An internal transaction occurs within a single device. Externally,
a single operation (i.e. a set operation) is invoked on a group of
objects. Single-device transaction handling controls locking the
affected data structures during the operation, and performing the
operation atomically for the group of objects. This includes the
ability to roll-back partial changes when an error occurs.
The XML configuration protocol MUST support single-device
transaction handling for any operations that modify the
configuration of a device. At a minimum, this would include
restore, set, add and delete operations.
13.4.2 Multiple-Device Transactions
An external transaction can be performed, in an atomic fashion,
across multiple pieces of networking equipment. For example, it
should be possible to renumber the routers at both ends of a point-
to-point link in a single, atomic transaction. In order to support
external transactions, it must be possible for the client to invoke
the individual transaction steps (test, perform, complete and roll-
back).
The XML configuration protocol SHOULD support multiple-device
transaction handling. This should include the ability to roll-back
configuration changes when indicated.
Wasserman, Editor Expires May 2002 14
Requirements for Network Configuration June 2002
14 Protocol Messaging Requirements
This section discusses the requirements for protocol messaging.
Protocol messaging is, essential, an RPC mechanism that can be used
to exchange operations and data objects (as operation input
parameters or as return values). It is quite possible that a
currently available protocol, such as SOAP, could be used as the
protocol messaging portion of the XML configuration protocol.
14.1 Protocol Message Types
It is likely that an XML configuration protocol will include
several message types. Further thought is required to determine
what types of protocol messages should be supported.
14.2 Authentication of Protocol Messages
It is vital that protocol messages are both authenticated and
authorized before any operations contained within the message are
performed. At a minimum, the XML configuration protocol must meet
the following requirements:
1. All protocol messages MUST be authenticated and authorized
before any protocol operations contained within the message
are performed.
2. The XML configuration protocol MAY rely on authentication
features of the underlying protocol transport.
14.3 Privacy of Protocol Messages
Configuration messages will often contain private information, such
as security keys and user information. The XML configuration
protocol is expected to include dump and restore operations that
move blocks of human-readable configuration information, without
the protocol being aware of the contents. In order to protect
sensitive configuration information, the following requirements
must be met:
1. All protocol messages that contain opaque blocks of
configuration data MUST be encrypted.
2. The protocol MAY include a mechanism to tag private and non-
private data.
If a tagging mechanism is included, all protocol
messages containing private data MUST be encrypted.
If a tagging mechanism is not included, all protocol
messages containing any configuration data MUST be
encrypted.
Wasserman, Editor Expires May 2002 15
Requirements for Network Configuration June 2002
3. The protocol MAY rely on encryption capabilities of the
underlying protocol transport to meet the privacy
requirements.
15 Protocol Transport Requirements
As indicated in the General Requirements section, the XML
configuration protocol should use a secure, text-oriented protocol
transport, such as SSH. Requirements for the protocol transport
include:
1. It MUST be possible and practical for a human to view and
modify configuration information from a command-line.
2. It MUST be possible to view and modify configuration
information using scripts written in text-oriented scripting
languages.
3. The XML configuration protocol MUST NOT require a
specialized application, such as an SNMP MIB browser, on the
client-side. The protocol MUST be transported over a widely
available, general-purpose protocol, such as SSHv2 or HTTP.
4. The protocol transport SHOULD provide basic security
features such as authentication and encryption, to avoid the
need to define basic security mechanisms specifically for
the XML configuration protocol.
16 Approach to XML Configuration
This section offers thoughts on how the IETF could approach the
development of an XML-based configuration protocol. The protocol
could be developed in a set of discrete phases that would each
offer tangible benefits to the Internet community, while building
towards a protocol that would meet the full set of requirements
outlined in this document.
This approach would also allow the IETF to commit to a limited set
of XML-related work, and to determine the usefulness and industry
acceptance of that work before committing to later phases.
A more aggressive plan could combine multiple phases into a single
block of work.
16.1 Phase Zero: Investigate Technical Options
During this phase we would explore existing XML-based technologies
and determine their applicability to an XML configuration. The
goal would be to emerge from this phase with a basic understanding
of the technical approach that we would pursue.
Output from this phase should include a greatly enhanced concepts
and requirements document, and a detailed plan for later phases of
protocol development.
Wasserman, Editor Expires May 2002 16
Requirements for Network Configuration June 2002
Until this phase has been completed, we should not begin work on
any of the later phases of this effort.
16.2 Phase One: XML over Secure Transport
The first standardization task of a working group focused on XML
configuration should be to standardize how XML data can be
transmitted over a secure protocol transport. This would include
an explanation of how XML should be encapsulated within the secure
transport, and the assignment of a new port number for XML
transport connections. It might be possible to base this work on
current industry practice.
This phase would basically define the protocol transport for later
XML configuration work.
16.3 Phase Two: XML Operations on Configuration Blocks
For the second phase, an XML configuration WG should focus on
defining how operations on blocks of configuration information,
representing whole or partial system configurations, could be
transferred over the secure transport defined in the first phase.
This would include a basic RPC-like mechanism for specifying
operations on configuration blocks.
This phase would involve developing a basic framework for protocol
messaging and the definition of some protocol message types. It
would also require specification of a set of protocol operations to
manipulate configuration blocks, and authentication and
authorization mechanisms to secure those operations. A rudimentary
data representation would be required, to represent chunks of
opaque XML configuration data.
The contents of the configuration blocks would be vendor-
proprietary, and no attempt would be made in this phase to define
an XML-specific data model, a data modeling language or a full data
representation for XML configuration.
It might be possible to base some of the work in this phase on an
existing proprietary or standard XML RPC mechanism, such as SOAP.
16.4 Phase Three: XML Operations on Data Objects
In phase three, it would become necessary to define a data model,
data modeling language and complete data representation for the XML
configuration protocol. In this phase, we would define operations
to manipulate individual configuration data objects.
At this phase, the protocol would still be restricted to operations
between a management system (i.e. workstation) and a single piece
of networking equipment (i.e. router or switch).
Wasserman, Editor Expires May 2002 17
Requirements for Network Configuration June 2002
16.5 Phase Four: Multi-System Transactions using XML
Phase four would involve the addition of multi-system transaction
support to the XML configuration protocol. After the completion of
phase four, it would be possible to use the XML configuration
protocol to configure entire networks, not just individual pieces
of networking equipment.
17 Security Considerations
[This section will be completed in a future version of this draft.]
18 References
[RFC2026]
S. Bradner, "The Internet Standards Process -- Revision 3",
RFC 2026, BCP9, October 1996
[RFC2119]
S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP14, March 1999.
[This section will be completed in a later draft.]
19 Acknowledgements
Ran Atkinson made several useful suggestions that have been
incorporated into this document. Andy Bierman, Randy Bush and Ted
Goddard provided feedback to a preliminary version of the document.
20 Author's Contact Information
Comments or questions regarding this document should be sent to:
Margaret Wasserman
Wind River
10 Tara Blvd., Suite 330 Phone: (603) 897-2067
Nashua, NH 03062 USA Email: mrw@windriver.com
Wasserman, Editor Expires May 2002 18