draft-ietf-netconf-soap-04.txt   draft-ietf-netconf-soap-05.txt 
Network Working Group T. Goddard Network Working Group T. Goddard
Internet-Draft ICEsoft Technologies Inc. Internet-Draft ICEsoft Technologies Inc.
Expires: July 2, 2005 January 2005 Expires: October 24, 2005 April 25, 2005
Using the Network Configuration Protocol (NETCONF) Over the Simple Using the Network Configuration Protocol (NETCONF) Over the Simple
Object Access Protocol (SOAP) Object Access Protocol (SOAP)
draft-ietf-netconf-soap-04 draft-ietf-netconf-soap-05
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of section 3 of RFC 3667. By submitting this Internet-Draft, each of section 3 of RFC 3667. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of which he or she is aware have been or will be disclosed, and any of
which he or she become aware will be disclosed, in accordance with which he or she become aware will be disclosed, in accordance with
RFC 3668. RFC 3668.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on July 2, 2005. This Internet-Draft will expire on October 24, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2005).
Abstract Abstract
The Network Configuration Protocol (NETCONF) is applicable to a wide The Network Configuration Protocol (NETCONF) is applicable to a wide
range of devices in a variety of environments. The emergence of Web range of devices in a variety of environments. The emergence of Web
Services gives one such environment, and is presently characterized Services gives one such environment, and is presently characterized
skipping to change at page 2, line 29 skipping to change at page 2, line 29
2.7.3 SOAP Faults . . . . . . . . . . . . . . . . . . . . . 8 2.7.3 SOAP Faults . . . . . . . . . . . . . . . . . . . . . 8
3. A SOAP Service for NETCONF . . . . . . . . . . . . . . . . . . 10 3. A SOAP Service for NETCONF . . . . . . . . . . . . . . . . . . 10
3.1 Fundamental Use Case . . . . . . . . . . . . . . . . . . . 10 3.1 Fundamental Use Case . . . . . . . . . . . . . . . . . . . 10
3.2 NETCONF Session Establishment . . . . . . . . . . . . . . 10 3.2 NETCONF Session Establishment . . . . . . . . . . . . . . 10
3.3 NETCONF Capabilities Exchange . . . . . . . . . . . . . . 10 3.3 NETCONF Capabilities Exchange . . . . . . . . . . . . . . 10
3.4 NETCONF Session Usage . . . . . . . . . . . . . . . . . . 10 3.4 NETCONF Session Usage . . . . . . . . . . . . . . . . . . 10
3.5 NETCONF Session Teardown . . . . . . . . . . . . . . . . . 11 3.5 NETCONF Session Teardown . . . . . . . . . . . . . . . . . 11
3.6 A NETCONF Over SOAP example . . . . . . . . . . . . . . . 11 3.6 A NETCONF Over SOAP example . . . . . . . . . . . . . . . 11
3.7 NETCONF SOAP WSDL . . . . . . . . . . . . . . . . . . . . 12 3.7 NETCONF SOAP WSDL . . . . . . . . . . . . . . . . . . . . 12
3.8 Sample Service Definition WSDL . . . . . . . . . . . . . . 14 3.8 Sample Service Definition WSDL . . . . . . . . . . . . . . 14
4. Security Considerations . . . . . . . . . . . . . . . . . . . 16 4. Security Considerations . . . . . . . . . . . . . . . . . . . 15
4.1 Integrity, Privacy, and Authentication . . . . . . . . . . 16 4.1 Integrity, Privacy, and Authentication . . . . . . . . . . 15
4.2 Vulnerabilities . . . . . . . . . . . . . . . . . . . . . 16 4.2 Vulnerabilities . . . . . . . . . . . . . . . . . . . . . 15
4.3 Environmental Specifics . . . . . . . . . . . . . . . . . 17 4.3 Environmental Specifics . . . . . . . . . . . . . . . . . 16
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6.1 Normative References . . . . . . . . . . . . . . . . . . . . 19 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 18
6.2 Informative References . . . . . . . . . . . . . . . . . . . 20 6.2 Informative References . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 20
Intellectual Property and Copyright Statements . . . . . . . . 22 Intellectual Property and Copyright Statements . . . . . . . . 21
1. Introduction 1. Introduction
Given the use of XML [2] and the remote procedure call Given the use of XML [2] and the remote procedure call
characteristics, it is natural to consider a binding of the NETCONF characteristics, it is natural to consider a binding of the NETCONF
[1] operations to a SOAP [3] application protocol. This document [1] operations to a SOAP [3] application protocol. This document
proposes a binding of this form. proposes a binding of this form.
In general, SOAP is a natural messaging scheme for NETCONF, In general, SOAP is a natural messaging scheme for NETCONF,
essentially because of the remote procedure call character of both. essentially because of the remote procedure call character of both.
However, care must be taken with SOAP over HTTP as it is inherently However, care must be taken with SOAP over HTTP as it is inherently
synchronous and client-driven. SOAP over BEEP [15] is technically synchronous and client-driven. SOAP over BEEP [14] is technically
superior, but is not as widely adopted. superior, but is not as widely adopted.
Four basic topics are presented: SOAP specifics of interest to Four basic topics are presented: SOAP specifics of interest to
NETCONF, specifics on implementing NETCONF as a SOAP-based web NETCONF, specifics on implementing NETCONF as a SOAP-based web
service, security considerations, and an appendix with functional service, security considerations, and an appendix with functional
WSDL. In some sense, the most important part of the document is the WSDL. In some sense, the most important part of the document is the
brief WSDL document presented in Section 3.7. With the right tools, brief WSDL document presented in Section 3.7. With the right tools,
the WSDL combined with the base NETCONF XML Schemas provide machine the WSDL combined with the base NETCONF XML Schemas provide machine
readable descriptions sufficient for the development of software readable descriptions sufficient for the development of software
applications using NETCONF. applications using NETCONF.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [11] document are to be interpreted as described in RFC 2119 [10]
2. SOAP Background for NETCONF 2. SOAP Background for NETCONF
Why introduce SOAP as yet another wrapper around what is already a Why introduce SOAP as yet another wrapper around what is already a
remote procedure call message? There are, in fact, both technical remote procedure call message? There are, in fact, both technical
and practical reasons. The technical reasons are perhaps less and practical reasons. The technical reasons are perhaps less
compelling, but let's examine them first. compelling, but let's examine them first.
The use of SOAP does offer a few technical advantages. SOAP is The use of SOAP does offer a few technical advantages. SOAP is
fundamentally an XML messaging scheme (which is capable of supporting fundamentally an XML messaging scheme (which is capable of supporting
skipping to change at page 4, line 41 skipping to change at page 4, line 41
many developers. SOAP over HTTP (with WSDL) is seeing good success many developers. SOAP over HTTP (with WSDL) is seeing good success
at this, and this means that a device management protocol making use at this, and this means that a device management protocol making use
of these technologies has advantages in being implemented and of these technologies has advantages in being implemented and
adopted. Admittedly, there are interoperability problems with SOAP adopted. Admittedly, there are interoperability problems with SOAP
and WSDL, but such problems have wide attention and can be expected and WSDL, but such problems have wide attention and can be expected
to be resolved. to be resolved.
2.1 Use and Storage of WSDL and XSD 2.1 Use and Storage of WSDL and XSD
One of the advantages of using machine readable formats such as Web One of the advantages of using machine readable formats such as Web
Services Description Language (WSDL) [4] and XML Schemas [5] is that Services Description Language (WSDL) [17] and XML Schemas [4] is that
they can be used automatically in the software development process. they can be used automatically in the software development process.
With appropriate tools, WSDL and XSD can be used to generate classes With appropriate tools, WSDL and XSD can be used to generate classes
that act as remote interfaces or application specific data that act as remote interfaces or application specific data
structures. Other uses, such as document generation and service structures. Other uses, such as document generation and service
location, are also common. A great innovation found with many location, are also common. A great innovation found with many
XML-based definition languages is the use of hyperlinks for referring XML-based definition languages is the use of hyperlinks for referring
to documents containing supporting definitions. to documents containing supporting definitions.
<import namespace="urn:ietf:params:xml:ns:netconf:base:1.0" <import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
location="http://www.iana.org/assignments/xml-registry/ location="http://www.iana.org/assignments/xml-registry/
schema/netconf-base_1.0.xsd" /> schema/netconf-base_1.0.xsd" />
For instance, in WSDL, the above import statement imports the For instance, in WSDL, the above import statement imports the
definitions of XML types and elements from the base NETCONF schema. definitions of XML types and elements from the base NETCONF schema.
Ideally, the file containing that schema is hosted on a web server Ideally, the file containing that schema is hosted on a web server
under the authority of the standards body that defined the schema. under the authority of the standards body that defined the schema.
In this way, dependent standards can be built up over time and all In this way, dependent standards can be built up over time and all
are accessible to automated software tools that ensure adherence to are accessible to automated software tools that ensure adherence to
the standards. The IANA maintained registry for this purpose is the standards. The IANA maintained registry for this purpose is
described in The IETF XML Registry [17]. described in The IETF XML Registry [16].
Note that WSDL declarations for SOAP over BEEP bindings are not yet Note that WSDL declarations for SOAP over BEEP bindings are not yet
standardized. standardized.
2.2 SOAP over HTTP 2.2 SOAP over HTTP
While it is true that SOAP focuses on messages and can be bound to While it is true that SOAP focuses on messages and can be bound to
different underlying protocols such as HTTP, SMTP, or BEEP, most different underlying protocols such as HTTP, SMTP, or BEEP, most
existing SOAP implementations support only HTTP or HTTP/TLS. existing SOAP implementations support only HTTP or HTTP/TLS.
skipping to change at page 6, line 7 skipping to change at page 6, line 7
o data encapsulation must adhere to MIME o data encapsulation must adhere to MIME
o bulk transfer relies on stream-based ordering o bulk transfer relies on stream-based ordering
In many ways these criticisms are directed at particular compromises In many ways these criticisms are directed at particular compromises
in the design of HTTP. As such, they are important to consider, but in the design of HTTP. As such, they are important to consider, but
it is not clear that they result in fatal drawbacks for a device it is not clear that they result in fatal drawbacks for a device
management protocol. management protocol.
2.4 BCP56: On the Use of HTTP as a Substrate 2.4 BCP56: On the Use of HTTP as a Substrate
Best Current Practice 56 [9] presents a number of important Best Current Practice 56 [8] presents a number of important
considerations on the use of HTTP in application protocols. In considerations on the use of HTTP in application protocols. In
particular, it raises the following concerns: particular, it raises the following concerns:
o HTTP may be more complex than is necessary for the application o HTTP may be more complex than is necessary for the application
o The use of HTTP may mask the application from some firewalls o The use of HTTP may mask the application from some firewalls
o A substantially new service should not re-use port 80 as assigned o A substantially new service should not re-use port 80 as assigned
to HTTP to HTTP
o HTTP caching may mask connection state o HTTP caching may mask connection state
Fundamentally, these concerns lie directly with SOAP over HTTP, Fundamentally, these concerns lie directly with SOAP over HTTP,
rather than the application of SOAP over HTTP to NETCONF. As BCP 56 rather than the application of SOAP over HTTP to NETCONF. As BCP 56
skipping to change at page 6, line 43 skipping to change at page 6, line 43
o Use HTTPS o Use HTTPS
It is also possible to respond to the concern on the re-use of port It is also possible to respond to the concern on the re-use of port
80. A NETCONF SOAP service can be offered on any desired port, and 80. A NETCONF SOAP service can be offered on any desired port, and
it is recommended that a new standard port for SOAP over HTTP, or a it is recommended that a new standard port for SOAP over HTTP, or a
new standard port for NETCONF over SOAP (over HTTP) be defined, as new standard port for NETCONF over SOAP (over HTTP) be defined, as
requested in the IANA considerations of this document. requested in the IANA considerations of this document.
2.5 Important HTTP 1.1 Features 2.5 Important HTTP 1.1 Features
HTTP 1.1 [8] includes two important features that provide for HTTP 1.1 [7] includes two important features that provide for
relatively efficient transport of SOAP messages. These features are relatively efficient transport of SOAP messages. These features are
"persistent connections" and "chunked transfer-coding". "persistent connections" and "chunked transfer-coding".
Persistent connections allow a single TCP connection to be used Persistent connections allow a single TCP connection to be used
across multiple HTTP requests. This permits multiple SOAP request/ across multiple HTTP requests. This permits multiple SOAP request/
response message pairs to be exchanged without the overhead of response message pairs to be exchanged without the overhead of
creating a new TCP connection for each request. Given that a single creating a new TCP connection for each request. Given that a single
stream is used for both requests and responses, it is clear that some stream is used for both requests and responses, it is clear that some
form of framing is necessary. For messages whose length is known in form of framing is necessary. For messages whose length is known in
advance, this is handled by the HTTP header "Content-length". For advance, this is handled by the HTTP header "Content-length". For
skipping to change at page 7, line 30 skipping to change at page 7, line 30
messages, it is also clear that Chunking is very useful. In some messages, it is also clear that Chunking is very useful. In some
cases it is possible to buffer a SOAP response and determine its cases it is possible to buffer a SOAP response and determine its
length before sending, but the storage requirements for this are length before sending, but the storage requirements for this are
prohibitive for many devices. Together, these two features provide a prohibitive for many devices. Together, these two features provide a
good foundation for device management using SOAP over HTTP. HTTP good foundation for device management using SOAP over HTTP. HTTP
chunking and persistent connections SHOULD be used. chunking and persistent connections SHOULD be used.
2.6 SOAP Over BEEP 2.6 SOAP Over BEEP
Although not widely adopted by the Web Services community, BEEP is an Although not widely adopted by the Web Services community, BEEP is an
excellent substrate for SOAP [16]. In particular, it provides for excellent substrate for SOAP [15]. In particular, it provides for
request/response message exchanges initiated by either BEEP peer and request/response message exchanges initiated by either BEEP peer and
allows the number of response messages to be arbitrary (including allows the number of response messages to be arbitrary (including
zero). The BEEP profile for SOAP simply makes use of a single BEEP zero). The BEEP profile for SOAP simply makes use of a single BEEP
channel for exchanging SOAP messages and benefits from BEEP's channel for exchanging SOAP messages and benefits from BEEP's
inherent strengths for message exchange over a single transport inherent strengths for message exchange over a single transport
connection. connection.
2.7 SOAP Implementation Considerations 2.7 SOAP Implementation Considerations
It is not the goal of this document to cover the SOAP [3] It is not the goal of this document to cover the SOAP [3]
skipping to change at page 8, line 26 skipping to change at page 8, line 26
use of SOAP headers. use of SOAP headers.
2.7.3 SOAP Faults 2.7.3 SOAP Faults
A SOAP Fault is returned in the event of a NETCONF <rpc-error>. It A SOAP Fault is returned in the event of a NETCONF <rpc-error>. It
is constructed essentially as a wrapper for the <rpc-error>, but is constructed essentially as a wrapper for the <rpc-error>, but
allow SOAP processors to propagate the <rpc-error> to application allow SOAP processors to propagate the <rpc-error> to application
code using a language-appropriate exception mechanism. code using a language-appropriate exception mechanism.
A SOAP Fault is constructed from an <rpc-error> as follows: the SOAP A SOAP Fault is constructed from an <rpc-error> as follows: the SOAP
Fault faultcode is "Client" in the SOAP envelope namespace, the SOAP Fault Code Value is "Reciever" in the SOAP envelope namespace, the
Fault faultstring is the contents of the NETCONF <rpc-error> SOAP Fault Reason Text is the contents of the NETCONF <rpc-error>
"error-tag", and the SOAP Fault detail is the original <rpc-error> "error-tag", and the SOAP Fault detail is the original <rpc-error>
structure. structure.
For instance, given the following <rpc-error>, For instance, given the following <rpc-error>,
<rpc-error xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> <rpc-error xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<error-type>rpc</error-type> <error-type>rpc</error-type>
<error-tag>MISSING_ATTRIBUTE</error-tag> <error-tag>MISSING_ATTRIBUTE</error-tag>
<error-severity>error</error-severity> <error-severity>error</error-severity>
<error-info> <error-info>
<bad-attribute>message-id</bad-attribute> <bad-attribute>message-id</bad-attribute>
<bad-element>rpc</bad-element> <bad-element>rpc</bad-element>
</error-info> </error-info>
</rpc-error> </rpc-error>
the associated SOAP Fault message is the associated SOAP Fault message is
<soapenv:Envelope <soapenv:Envelope
xmlns:SOAP-ENV= xmlns:soapenv "http://www.w3.org/2003/05/soap-envelope"
"http://schemas.xmlsoap.org/soap/envelope/"> xmlns:xml="http://www.w3.org/XML/1998/namespace">
<soapenv:Body> <soapenv:Body>
<soapenv:Fault> <soapenv:Fault>
<faultcode>soapenv:Client</faultcode> <soapenv:Code>
<faultstring>MISSING_ATTRIBUTE</faultstring> <soapenv:Value>env:Receiver</soapenv:Value>
</soapenv:Code>
<soapenv:Reason>
<soapenv:Text
xml:lang="en">MISSING_ATTRIBUTE</soapenv:Text>
</soapenv:Reason>
<detail> <detail>
<rpc-error xmlns= <rpc-error xmlns "urn:ietf:params:xml:ns:netconf:base:1.0">
"urn:ietf:params:xml:ns:netconf:base:1.0">
<error-type>rpc</error-type> <error-type>rpc</error-type>
<error-tag>MISSING_ATTRIBUTE</error-tag> <error-tag>MISSING_ATTRIBUTE</error-tag>
<error-severity>error</error-severity> <error-severity>error</error-severity>
<error-info> <error-info>
<bad-attribute>message-id</bad-attribute> <bad-attribute>message-id</bad-attribute>
<bad-element>rpc</bad-element> <bad-element>rpc</bad-element>
</error-info> </error-info>
</rpc-error> </rpc-error>
</detail> </detail>
</soapenv:Fault> </soapenv:Fault>
skipping to change at page 11, line 4 skipping to change at page 11, line 4
maintained so that appropriate operations can be applied during a maintained so that appropriate operations can be applied during a
session. Locks are released upon termination of a session as this session. Locks are released upon termination of a session as this
makes the protocol more robust. Pending operations come and go from makes the protocol more robust. Pending operations come and go from
existence during the normal course of RPC operations. Operation existence during the normal course of RPC operations. Operation
sequence numbers provide the small but necessary state information to sequence numbers provide the small but necessary state information to
refer to operations during the session. refer to operations during the session.
In the case of SOAP over HTTP, a NETCONF session is supported by an In the case of SOAP over HTTP, a NETCONF session is supported by an
HTTP connection with an authenticated user. For SOAP over BEEP, a HTTP connection with an authenticated user. For SOAP over BEEP, a
NETCONF session is supported by a BEEP channel operating according to NETCONF session is supported by a BEEP channel operating according to
the BEEP profile for SOAP [16]. the BEEP profile for SOAP [15].
3.5 NETCONF Session Teardown 3.5 NETCONF Session Teardown
To allow automated cleanup, NETCONF over SOAP session teardown takes To allow automated cleanup, NETCONF over SOAP session teardown takes
place when the underlying connection (in the case of HTTP) or channel place when the underlying connection (in the case of HTTP) or channel
(in the case of BEEP) is closed. Note that the root cause of such (in the case of BEEP) is closed. Note that the root cause of such
teardown may be the closure of the TCP connection under either HTTP teardown may be the closure of the TCP connection under either HTTP
or BEEP as the case may be. NETCONF managers and agents must be or BEEP as the case may be. NETCONF managers and agents must be
capable of programatically closing the transport connections capable of programatically closing the transport connections
associated with NETCONF sessions, such as in response to a associated with NETCONF sessions, such as in response to a
<close-session> operation; thus, the HTTP or BEEP substrate <close-session> operation; thus, the HTTP or BEEP substrate
implementation must expose this appropriately. implementation must expose this appropriately.
3.6 A NETCONF Over SOAP example 3.6 A NETCONF Over SOAP example
Since the proposed WSDL (in Section 3.7) uses document/literal Since the proposed WSDL (in Section 3.7) uses document/literal
encoding, the use of a SOAP header and body has little impact on the encoding, the use of a SOAP header and body has little impact on the
representation of a NETCONF operation. This example shows HTTP/1.0 representation of a NETCONF operation. This example shows HTTP/1.1
for simplicity. Examples for HTTP/1.1 and BEEP would be similar. for simplicity. An example for BEEP would be similar.
C: POST /netconf HTTP/1.0 C: POST /netconf HTTP/1.1
C: Host: netconfdevice
C: Content-Type: text/xml; charset=utf-8 C: Content-Type: text/xml; charset=utf-8
C: Accept: application/soap+xml, text/* C: Accept: application/soap+xml, text/*
C: Cache-Control: no-cache C: Cache-Control: no-cache
C: Pragma: no-cache C: Pragma: no-cache
C: Content-Length: 467 C: Content-Length: 465
C: C:
C: <?xml version="1.0" encoding="UTF-8"?> C: <?xml version="1.0" encoding="UTF-8"?>
C: <soapenv:Envelope C: <soapenv:Envelope
C: xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> C: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
C: <soapenv:Body> C: <soapenv:Body>
C: <rpc message-id="101" C: <rpc message-id="101"
C: xmlns="xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> C: xmlns="xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
C: <get-config> C: <get-config>
C: <filter type="subtree"> C: <filter type="subtree">
C: <top xmlns="http://example.com/schema/1.2/config"> C: <top xmlns="http://example.com/schema/1.2/config">
C: <users/> C: <users/>
C: </top> C: </top>
C: </filter> C: </filter>
C: </get-config> C: </get-config>
C: </rpc> C: </rpc>
C: </soapenv:Body> C: </soapenv:Body>
C: </soapenv:Envelope> C: </soapenv:Envelope>
The HTTP/1.0 response is also straightforward: The HTTP/1.1 response is also straightforward:
S: HTTP/1.0 200 OK S: HTTP/1.1 200 OK
S: Content-Type: text/xml; charset=utf-8 S: Content-Type: application/soap+xml; charset=utf-8
S: Content-Length: 917
S: S:
S: <?xml version="1.0" encoding="UTF-8"?> S: <?xml version="1.0" encoding="UTF-8"?>
S: <soapenv:Envelope S: <soapenv:Envelope
S: xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> S: xmlns:soapenv="http://www.w3.org/2003/05/soap-envelope">
S: <soapenv:Body> S: <soapenv:Body>
S: <rpc-reply message-id="101" S: <rpc-reply message-id="101"
S: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"> S: xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
S: <data> S: <data>
S: <top xmlns="http://example.com/schema/1.2/config"> S: <top xmlns="http://example.com/schema/1.2/config">
S: <users> S: <users>
S: <user> S: <user>
S: <name>root</name> S: <name>root</name>
S: <type>superuser</type> S: <type>superuser</type>
S: <full-name>Charlie Root</full-name> S: <full-name>Charlie Root</full-name>
skipping to change at page 13, line 10 skipping to change at page 13, line 11
xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/"
xmlns:tns="urn:ietf:params:xml:ns:netconf:soap:1.0" xmlns:tns="urn:ietf:params:xml:ns:netconf:soap:1.0"
xmlns:netb="urn:ietf:params:xml:ns:netconf:base:1.0" xmlns:netb="urn:ietf:params:xml:ns:netconf:base:1.0"
targetNamespace="urn:ietf:params:xml:ns:netconf:soap:1.0" targetNamespace="urn:ietf:params:xml:ns:netconf:soap:1.0"
name="netconf-soap_1.0.wsdl"> name="netconf-soap_1.0.wsdl">
<import namespace="urn:ietf:params:xml:ns:netconf:base:1.0" <import namespace="urn:ietf:params:xml:ns:netconf:base:1.0"
location="http://www.iana.org/assignments/xml-registry/ location="http://www.iana.org/assignments/xml-registry/
schema/netconf-base_1.0.xsd"/> schema/netconf-base_1.0.xsd"/>
<types>
<xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"
targetNamespace="urn:ietf:params:xml:ns:netconf:soap:1.0" >
<xsd:element name="capability" type="xsd:anyURI" />
<xsd:element name="capabilities">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="tns:capability"
maxOccurs="unbounded" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
<xsd:element name="hello">
<xsd:complexType>
<xsd:sequence>
<xsd:element ref="tns:capabilities"
maxOccurs="1" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>
</xsd:schema>
</types>
<message name="helloRequest"> <message name="helloRequest">
<part name="in" element="tns:hello"/> <part name="in" element="netb:hello"/>
</message> </message>
<message name="helloResponse"> <message name="helloResponse">
<part name="out" element="tns:hello"/> <part name="out" element="netb:hello"/>
</message> </message>
<message name="rpcRequest"> <message name="rpcRequest">
<part name="in" element="netb:rpc"/> <part name="in" element="netb:rpc"/>
</message> </message>
<message name="rpcResponse"> <message name="rpcResponse">
<part name="out" element="netb:rpc-reply"/> <part name="out" element="netb:rpc-reply"/>
</message> </message>
<portType name="netconfPortType"> <portType name="netconfPortType">
skipping to change at page 16, line 31 skipping to change at page 15, line 31
If the NETCONF server provides remote access through insecure If the NETCONF server provides remote access through insecure
protocols, such as HTTP, care should be taken to prevent execution of protocols, such as HTTP, care should be taken to prevent execution of
the NETCONF program when strong user authentication or data privacy the NETCONF program when strong user authentication or data privacy
is not available. is not available.
4.1 Integrity, Privacy, and Authentication 4.1 Integrity, Privacy, and Authentication
The NETCONF SOAP binding relies on an underlying secure transport for The NETCONF SOAP binding relies on an underlying secure transport for
integrity and privacy. Such transports are expected to include TLS integrity and privacy. Such transports are expected to include TLS
[12] and IPSec. There are a number of options for authentication [11] and IPSec. There are a number of options for authentication
(some of which are deployment-specific): (some of which are deployment-specific):
o within the transport (such as with TLS client certificates) o within the transport (such as with TLS client certificates)
o within HTTP (such as Digest Access Authentication [10]) o within HTTP (such as Digest Access Authentication [9])
o within SOAP (such as a digital signature in the header [19]) o within SOAP (such as a digital signature in the header [19])
HTTP, BEEP, and SOAP level authentication can be integrated with HTTP, BEEP, and SOAP level authentication can be integrated with
RADIUS [13] to support remote authentication databases. RADIUS [12] to support remote authentication databases.
4.2 Vulnerabilities 4.2 Vulnerabilities
The above protocols may have various vulnerabilities, and these may The above protocols may have various vulnerabilities, and these may
be inherited by NETCONF over SOAP. be inherited by NETCONF over SOAP.
NETCONF itself may have vulnerabilities due to the fact that an NETCONF itself may have vulnerabilities due to the fact that an
authorization model is not currently specified. authorization model is not currently specified.
It is important that device capabilities and authorization remain It is important that device capabilities and authorization remain
skipping to change at page 19, line 10 skipping to change at page 18, line 10
The IANA will assign TCP ports for NETCONF for SOAP over HTTP and The IANA will assign TCP ports for NETCONF for SOAP over HTTP and
SOAP over BEEP. SOAP over BEEP.
The IANA will place netconf-soap_1.0.wsdl in the IANA XML registry. The IANA will place netconf-soap_1.0.wsdl in the IANA XML registry.
6. References 6. References
6.1 Normative References 6.1 Normative References
[1] Enns, R., "NETCONF Configuration Protocol", [1] Enns, R., "NETCONF Configuration Protocol",
draft-ietf-netconf-prot-03 (work in progress), June 2004, draft-ietf-netconf-prot-05 (work in progress), Feb 2005,
<http://www.ietf.org/internet-drafts/ <http://www.ietf.org/internet-drafts/
draft-ietf-netconf-prot-03.txt>. draft-ietf-netconf-prot-05.txt>.
[2] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, [2] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler,
"Extensible Markup Language (XML) 1.0 (Second Edition)", W3C "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C
REC REC-xml-20001006, October 2000, REC REC-xml-20001006, October 2000,
<http://www.w3.org/TR/2000/REC-xml-20001006>. <http://www.w3.org/TR/2000/REC-xml-20001006>.
[3] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, [3] Gudgin, M., Hadley, M., Moreau, JJ. and H. Nielsen, "SOAP
N., Nielsen, H., Thatte, S. and D. Winer, "Simple Object Access Version 1.2 Part 1: Messaging Framework", W3C Recommendation
Protocol (SOAP) 1.1", W3C Note NOTE-SOAP-20000508, May 2000, REC-soap12-part1-20030624, June 2002,
<http://www.w3.org/TR/2000/NOTE-SOAP-20000508>. <http://www.w3.org/TR/soap12-part1/>.
[4] Christensen, E., Curbera, F., Meredith, G. and S. Weerawarana,
"Web Services Description Language (WSDL) 1.1", W3C Note
NOTE-wsdl-20010315, March 2001,
<http://www.w3.org/TR/2001/NOTE-wsdl-20010315>.
[5] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML [4] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML
Schema Part 1: Structures", W3C Recommendation Schema Part 1: Structures", W3C Recommendation
REC-xmlschema-1-20010502, May 2001, REC-xmlschema-1-20010502, May 2001,
<http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/>. <http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/>.
[6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies", Extensions (MIME) Part One: Format of Internet Message Bodies",
RFC 2045, November 1996, <http://www.ietf.org/rfc/rfc2045.txt>. RFC 2045, November 1996, <http://www.ietf.org/rfc/rfc2045.txt>.
[7] Freed, N. and N. Borenstein, "Multipurpose Internet Mail [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part Two: Media Types", RFC 2046, November Extensions (MIME) Part Two: Media Types", RFC 2046, November
1996, <http://www.ietf.org/rfc/rfc2046.txt>. 1996, <http://www.ietf.org/rfc/rfc2046.txt>.
[8] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., [7] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L.,
Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol --
HTTP/1.1", RFC 2616, June 1999, HTTP/1.1", RFC 2616, June 1999,
<http://www.ietf.org/rfc/rfc2616.txt>. <http://www.ietf.org/rfc/rfc2616.txt>.
[9] Moore, K., "On the use of HTTP as a Substrate", RFC 3205, [8] Moore, K., "On the use of HTTP as a Substrate", RFC 3205,
February 2002, <http://www.ietf.org/rfc/rfc3205.txt>. February 2002, <http://www.ietf.org/rfc/rfc3205.txt>.
[10] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., [9] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P.,
Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP: Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP:
Digest Access Authentication", RFC 2069, January 1997, Digest Access Authentication", RFC 2069, January 1997,
<http://www.ietf.org/rfc/rfc2069.txt>. <http://www.ietf.org/rfc/rfc2069.txt>.
[11] Bradner, S., "Key words for use in RFCs to Indicate Requirement [10] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, March 1997, Levels", RFC 2119, March 1997,
<http://www.ietf.org/rfc/rfc2119.txt>. <http://www.ietf.org/rfc/rfc2119.txt>.
[12] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and [11] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and
P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January
1999, <http://www.ietf.org/rfc/rfc2246.txt>. 1999, <http://www.ietf.org/rfc/rfc2246.txt>.
[13] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote [12] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000, <http://www.ietf.org/rfc/rfc2865.txt>. 2000, <http://www.ietf.org/rfc/rfc2865.txt>.
[14] Rose, M. and D. New, "Reliable Delivery for syslog", RFC 3195, [13] Rose, M. and D. New, "Reliable Delivery for syslog", RFC 3195,
November 2001, <http://www.ietf.org/rfc/rfc3195.txt>. November 2001, <http://www.ietf.org/rfc/rfc3195.txt>.
[15] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC [14] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
3080, March 2001, <http://www.ietf.org/rfc/rfc3080.txt>. 3080, March 2001, <http://www.ietf.org/rfc/rfc3080.txt>.
[16] O'Tuathail, E. and M. Rose, "Using the Simple Object Access [15] O'Tuathail, E. and M. Rose, "Using the Simple Object Access
Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)", Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)",
RFC 3288, June 2002, <http://www.ietf.org/rfc/rfc3288.txt>. RFC 3288bis, March 2005, <http://www.ietf.org/internet-drafts/
draft-mrose-rfc3288bis-00.txt>.
[17] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004, [16] Mealling, M., "The IETF XML Registry", RFC 3688, January 2004,
<http://www.ietf.org/rfc/rfc3688.txt>. <http://www.ietf.org/rfc/rfc3688.txt>.
6.2 Informative References 6.2 Informative References
[17] Christensen, E., Curbera, F., Meredith, G. and S. Weerawarana,
"Web Services Description Language (WSDL) 1.1", W3C Note
NOTE-wsdl-20010315, March 2001,
<http://www.w3.org/TR/2001/NOTE-wsdl-20010315>.
[18] Barton, J., Nielsen, H. and S. Thatte, "SOAP Messages with [18] Barton, J., Nielsen, H. and S. Thatte, "SOAP Messages with
Attachments", W3C Note NOTE-SOAP-attachments-20001211, Dec Attachments", W3C Note NOTE-SOAP-attachments-20001211, Dec
2000, 2000,
<http://www.w3.org/TR/2000/NOTE-SOAP-attachments-20001211>. <http://www.w3.org/TR/2000/NOTE-SOAP-attachments-20001211>.
[19] Brown, A., Fox, B., Hada, S., LaMacchia, B. and H. Maruyama, [19] Brown, A., Fox, B., Hada, S., LaMacchia, B. and H. Maruyama,
"SOAP Security Extensions: Digital Signature", W3C Note "SOAP Security Extensions: Digital Signature", W3C Note
NOTE-SOAP-dsig-20010206, Feb 2001, NOTE-SOAP-dsig-20010206, Feb 2001,
<http://www.w3.org/TR/SOAP-dsig/>. <http://www.w3.org/TR/SOAP-dsig/>.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/