netconfNetwork Working Group T. Goddard Internet-Draft Wind River SystemsICEsoft Technologies Inc. Expires: April 15,August 13, 2004 February 13, 2004 October 16, 2003NETCONF Over SOAP draft-ietf-netconf-soap-00draft-ietf-netconf-soap-01 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of 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. This Internet-Draft will expire on April 15,August 13, 2004. Copyright Notice Copyright (C) The Internet Society (2003).(2004). All Rights Reserved. Abstract The configurationdevice management protocol NETCONF is applicable to a wide range of devices in a variety of environments. The emergence of Web Services gives one such environment, and is presently characterized by the use of SOAP over HTTP. NETCONF finds many benefits in this environment: from the usere-use of existing standards, to ease of software development, to integration with deployed systems. Herein, we describe a SOAP over HTTP binding that, when used with multiplepersistent HTTP connections, yields an application protocol sufficient for NETCONF. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. SOAP Background for NETCONF . . . . . . . . . . . . . . . . 4 2.1 Use and Storage of WSDL and XSD . . . . . . . . . . . . . . 4 2.2 SOAP over HTTP . . . . . . . . . . . . . . . . . . . . . . . 5 2.3 HTTP Drawbacks . . . . . . . . . . . . . . . . . . . . . . . 5 2.4 BCP56: On the Use of HTTP as a Substrate . . . . . . . . . . 6 2.5 Important HTTP 1.1 Features . . . . . . . . . . . . . . . . 6 3. A2.6 SOAP Web Service for NETCONFImplementation Considerations . . . . . . . . . . . . . 7 2.6.1 SOAP Feature Exploitation . . . . 7 3.1 Fundamental Use Case. . . . . . . . . . . . . 7 2.6.2 SOAP Headers . . . . . . . 7 3.2 Mapping NETCONF Channels to HTTP Connections. . . . . . . . 7 3.2.1 Asynchronous Functionality. . . . . . . . . 7 3. A SOAP Web Service for NETCONF . . . . . . . . . . . . 7 3.3 NETCONF Sessions. . . 8 3.1 Fundamental Use Case . . . . . . . . . . . . . . . . . . . . 8 3.4 Capabilities Exchange3.2 NETCONF Sessions . . . . . . . . . . . . . . . . . . . 9 3.5 A NETCONF/SOAP example. . . 8 3.3 Capabilities Exchange . . . . . . . . . . . . . . . . 9 3.6 Managing Multiple Devices. . . 8 3.4 A NETCONF/SOAP example . . . . . . . . . . . . . . . . . 10. . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . 11 4.1 Integrity, Privacy, and Authentication . . . . . . . . . . . 11 4.2 Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . 11 4.3 Environmental Specifics . . . . . . . . . . . . . . . . . . 12 Normative References . . . . . . . . . . . . . . . . . . . . 13 Informative References . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . 15 A. WSDL Definitions . . . . . . . . . . . . . . . . . . . . . . 16 A.1 NETCONF SOAP Binding . . . . . . . . . . . . . . . . . . . . 16 A.2 Sample Service Definition . . . . . . . . . . . . . . . . . 17 Intellectual Property and Copyright Statements . . . . . . . 18 1. Introduction Given the use of XML  and the remote procedure call characteristics, it is natural to consider a binding of the NETCONF  operations to a SOAP  application protocol. This document proposes a binding of this form. Note that a SOAP binding for NETCONF is not necessarily intended only for managing individual devices. For instance, a server providing a SOAP interface can act as a proxy for multiple devices, possibly connecting to those devices over BEEP  or serial lines. In this case it is important to define a data model that appropriately aggregates the devices.In general, SOAP over HTTP is a natural application protocol for NETCONF (essentiallyNETCONF, essentially because both emphasize remote procedure calls) but there are three areas that require care: the <rpc-progress> operation, the mechanism for aborting operations, and the notification channel. The reason for this is that allof these functions are asynchronous (fromthe point of viewremote procedure call character of the manager) andboth, but care must be taken in some cases as HTTP is inherently synchronous and client-driven. Four basic topics are presented: SOAP specifics of interest to NETCONF, specifics on implementing NETCONF as a SOAP-based web service, security considerations, and an appendix with functional WSDL. In some sense, the most important part of the document is the brief WSDL document presented in the Appendix. With the right tools, the WSDL combined with the base NETCONF XML Schemas provide machine readable descriptions sufficient for the development of software applications using NETCONF. 2. SOAP Background for NETCONF Why introduce SOAP as yet another wrapper around what is already a remote procedure call message? There are, in fact, both technical and practical reasons. The technical reasons are perhaps less compelling, but let's examine them first. The use of SOAP does offer a few technical advantages. SOAP is fundamentally an XML messaging scheme (which is capable of supporting remote procedure call) and it defines a simple message format composed of a "header" and a "body" contained within an "envelope". The "header" contains meta-information relating to the message, and can be used to indicate such things as store-and-forward behaviour or transactional characteristics. In addition, SOAP specifies an optional encoding for the "body" of the message. However, this encoding is not applicable to NETCONF as one of the goals is to have highly readable XML, and SOAP-encoding is optimized instead for ease of automated deserialization. These benefits of the SOAP message structure are basic,simple, but worthwhile due to the fact that they are already standardized. It is the practical reasons that truly make SOAP over HTTP an interesting choice for device management. It is not difficult to invent a mechanism for exchanging XML messages over TCP, but what is difficult is getting that mechanism supported in a wide variety of tools and operating systems and having that mechanism understood by a great many developers. SOAP over HTTP (with WSDL) is seeing good success at this, and this means that a device management protocol making use of these technologies has advantages in being implemented and adopted. Admittedly, there are interoperability problems with SOAP and WSDL, but such problems have wide attention and can be expected to be resolved. 2.1 Use and Storage of WSDL and XSD One of the advantages of using machine readable formats such as Web Services Description Language (WSDL)  and XML Schemas  is that they can be used automatically in the software development process. With appropriate tools, WSDL and XSD can be used to generate classes that act as remote interfaces or application specific data structures. Other uses, such as document generation and service location, are also common. A great innovation found with many XML-based definition languages is the use of hyperlinks for referring to documents containing supporting definitions. For instance, in WSDL, the import statement <import namespace="http://iana.org/netconf/1.0/base" location="http://iana.org/netconf/1.0/base.xsd"/> imports the definitions of XML types and elements from the base NETCONF schema. Ideally, the file containing that schema is hosted on a web server under the authority of the standards body that defined the schema. In this way, dependent standards can be built up over time and all are accessible to automated software tools that ensure adherence to the standards. Thus, it will gradually become as important for iana.org to host documents like http://iana.org/netconf/1.0/base/base.xsd as the IETF now hosts documents such as http://www.ietf.org/rfc/rfc2616.txt 2.2 SOAP over HTTP While it is true that SOAP focuses on messages and can be bound to different underlying protocols such as HTTP, SMTP, or BEEP, most existing SOAP implementations support only HTTP or HTTP/TLS. For this discussion we will assume SOAP over HTTP or HTTP/TLS unless otherwise specified. (This also includes applications of IPSec to SOAP over HTTP.) Note that there are a number of advantages to considering SOAP over protocols other than HTTP, as HTTP assigns itsthe very distinct client and server roles by connection initiation. This causeswould cause difficulties in supporting asynchronous notification (possiblyand could be relieved in many ways by replacing SOAP/HTTP with SOAP/BEEP). However, it is also the case that the full potential ofHTTP is not currently used by SOAP. For instance, multiple SOAP replies to a single request could be contained in a multipart MIME  response. This would be a similar strategy to the use of multipart/relatedwith SOAP attachments .BEEP. 2.3 HTTP Drawbacks HTTP is not the ideal transport for messaging, but it is adequate for the most basic interpretation of "remote procedure call". HTTP is based on a communication pattern whereby the client (which initiates the TCP connection) makes a "request" to the server. The server returns a "response" and this process is continued (possibly over a persistent connection, as described below). This matches the basic idea of a remote procedure call where the caller invokes a procedure on a remote server and waits for the return value. Potential criticisms of HTTP could include the following: o server-initiated data flow is awkward o headers are verbose and text-based o idle connections may be closed by intermediate proxies o data encapsulation must adhere to MIME o bulk transfer relies on stream-based ordering In many ways these criticisms are directed at particular compromises 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 management protocol. 2.4 BCP56: On the Use of HTTP as a Substrate Best Current Practice 56  presents a number of important considerations on the use of HTTP in application protocols. In particular, it raises the following concerns: 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 A substantially new service should not re-use port 80 as assigned to HTTP Fundamentally, these concerns lie directly with SOAP over HTTP, rather than the application of SOAP over HTTP to NETCONF. As BCP 56 indicates, it is debatable whether HTTP is an appropriate protocol for SOAP at all, and it is likely that BEEP would be a superior protocol for most SOAP applications. Unfortunately, SOAP over HTTP is in common use and must be supported if the practical benefits of SOAP are to be realized. It is possible, however, to respond to the concern on the re-use of port 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 new standard port for NETCONF over SOAP (over HTTP) be defined. 2.5 Important HTTP 1.1 Features HTTP 1.1  includes two important features that provide for relatively efficient transport of SOAP messages. These features are "persistent connections" and "chunked transfer-coding". Persistent connections allow a single TCP connection to be used across multiple HTTP requests. This permits multiple SOAP request/ response message pairs to be exchanged without the overhead of 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 form of framing is necessary. For messages whose length is known in advance, this is handled by the HTTP header "Content-length". For messages of dynamic length, "Chunking" is required. HTTP "Chunking" or "chunked transfer-coding" allows the sender to send an indefinite amount of binary data. This is accomplished by informing the receiver of the size of each "chunk" (substring of the data) before the chunk is transmitted. The last chunk is indicated by a chunk of zero length. Chunking can be effectively used to transfer a large XML document where the document is generated on-line from a non-XML form in memory. In terms of application to SOAP message exchanges, persistent connections are clearly important for performance reasons, and are particularly important when it is the persistence of authenticated connections that is at stake. When one considers that messages of dynamic length are the rule rather than the exception for SOAP messages, it is also clear that Chunking is very useful. In some cases it is possible to buffer a SOAP response and determine its length before sending, but the storage requirements for this are prohibitive for many devices. Together, these two features provide a good foundation for device management using SOAP over HTTP. 3. A SOAP Web Service for NETCONF 3.1 Fundamental Use Case The fundamental use case for NETCONF over2.6 SOAP (NETCONF/SOAP) over HTTPImplementation Considerations It is thatnot the goal of a management console ("manager" role) managing one or more devices running NETCONF agents ("agent" role). The manager initiates one or more HTTP connectionsthis document to cover the agent and drives the NETCONF sessions through repeatedSOAP messages over HTTP requests. When the manager closes all HTTP connections associated with specification in detail. Instead, we provide a session, the NETCONF session is also closed. 3.2 Mapping NETCONF Channelsfew comments that may be of interest to HTTP Connections While the transportan implementor of NETCONF over SOAP. 2.6.1 SOAP Feature Exploitation NETCONF over BEEP  has been specified, the purposeSOAP does not make extensive use of this discussion is to describe how to map the channel semantics and performance characteristics already assumed by NETCONF onto (possibly persistent)SOAP over HTTP connections. This configuration is chosen because it is the one that benefits most from existingfeatures. For instance, NETCONF operations are not broken into SOAP toolsmessage parts, and implementations. It is true that BEEP has many advantages over HTTP forthe transport ofSOAP messages, but the fact remains that HTTPheader is currently more widely deployed than BEEP. At some point in the future, NETCONF/SOAP over BEEP may also be of interest. At that time it can be easily dealt withnot used to convey <rpc> metadata. This is a deliberate design decision as many ofit allows the issues already discussed in this document are pertinent. There would simply be a few enhancements regarding asynchronous notification.implementor to easily provide NETCONF employs potentially three channels per session: the management channel, the operation channel, and the notification channel. In the SOAPover HTTP binding, each of these channels can be mapped to an individual HTTP connection (although the notification channel may be a BEEP channel in a separate TCP connection). Thus, SOAP messages on one connection (corresponding tomultiple substrates while handling the management channel) must be able to refer to SOAPmessages on another connection (corresponding to the operation channel) as the "session" is potentially spread across multiple TCP connections. For instance, it may be necessary to abortover those different substrates in a time-extendedcommon way. 2.6.2 SOAP request on the "operation" HTTP connection by sending an "<rpc-abort>" message on the "management" HTTP connection. Distinct "operation" and "management" HTTP connections are not defined; the agent may limit the numberHeaders Implementors of HTTP connections in the same session, and each is capable those "management" and "operation" procedure calls supported byNETCONF over SOAP. 3.2.1 Asynchronous Functionality NETCONF uses two typesSOAP should be aware of asynchronous functionality, andthe mappingfollowing characteristic of these ontoSOAP over HTTP is somewhat problematic. The two asynchronous functions are <rpc-progress> and notifications on the notification channel, and these are not supported in theheaders: a SOAP over HTTP application protocol. Instead,header may have the client can periodically pollattribute "mustUnderstand" and, if so, the appropriate elements of via <get-state> (on a secondary HTTP connection) to obtain progress informationrecipient must either process the header block or notification log entries. Additionally,not process the notification mechanism for NETCONF is specified in an existing standard for reliable syslog SOAP message at all, and it is suggested that the same mechanisminstead generate a fault. A "mustUnderstand" header must not be used with thesilently discarded. 3. A SOAP binding (it is simply external). If notifications viaWeb Service for NETCONF 3.1 Fundamental Use Case The fundamental use case for NETCONF over SOAP (NETCONF/SOAP) over HTTP are desired, itis probably most effective ifthat of a management console ("manager" role) managing one or more devices running NETCONF agents ("agent" role). The manager initiates an HTTP connection is established from the agentto an agent and drives the management console. SuchNETCONF session via a connection could be established in response tosequence of SOAP messages over HTTP requests. When the manager connecting to the device. More sophisticated functionality, such as multiple SOAP replies to a single request, would require enhancements tocloses the SOAP overHTTP specification. 3.3connection, the NETCONF session is also closed. 3.2 NETCONF Sessions NETCONF sessions are persistent for both performance and semantic reasons. NETCONF session state contains the following: 1. Authentication Information 2. Capability Information 3. Locks 4. Pending Operations 5. Operation Sequence Numbers Authentication must be maintained throughout a session due to the fact that it is expensive to establish. Capability Information is maintained so that appropriate operations can be applied during a session. Locks are released upon termination of a session as this makes the protocol more robust. Pending operations come and go from existence during the normal course of RPC operations. Operation sequence numbers provide the small but necessary state information to refer to operations during the session. Since it is generally not possible to support a full NETCONF session with a single HTTP connection, it is necessary to identify the NETCONF session in a way that can span multiple HTTP connections. This can be performed with the HTTP request URI, as in the following POST request with the target session "sid-123": POST /netconf/sid-123 HTTP/1.0 Content-Type: text/xml; charset=utf-8 Content-Length: 470 Note that the session identifier must either be known by the manager (in order to attach to an existing session) or be communicated from the agent to the manager prior to the exchange of any significant NETCONF messages. For this,the fact that it is recommendedexpensive to establish. Capability Information is maintained so that the session identifierappropriate operations can be determined via <get-state>. An emptyapplied during a session. Locks are released upon termination of a session identifier may be used inas this makes the case where only anprotocol more robust. Pending operations channel is required (in this casecome and go from existence during the agent assigns a new sessionnormal course of RPC operations. Operation sequence numbers provide the small but necessary state information to that HTTP connection). Thus, inrefer to operations during the session. In the case of SOAP over HTTP, a NETCONF "session" is a collection ofsupported by an HTTP connectionsconnection with commonan authenticated users and a common session identifier as indicated in the HTTP reqest URI header.user. To support automated cleanup, a NETCONF over SOAP session is closed when all connections associated with that session arethe HTTP connection is closed. 3.43.3 Capabilities Exchange Capabilities exchange, if defined through a NETCONF RPC operation, can easily be accommodated in the SOAP binding. 3.53.4 A NETCONF/SOAP example Since the proposed WSDL (in Appendix A.1) uses document/literal 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 for simplicity. POST /netconf HTTP/1.0 Content-Type: text/xml; charset=utf-8 Accept: application/soap+xml, text/* Cache-Control: no-cache Pragma: no-cache Content-Length: 470 <?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Body> <rpc id="101" xmlns="http://ietf.org/netconf/1.0/base"> <get-config> <source> <running/> </source> <config xmlns="http://example.com/schema/1.2/config"> <users/> </config> <format>xml</format> </get-config> </rpc> </soapenv:Body> </soapenv:Envelope> The HTTP/1.0 response is also straightforward: HTTP/1.0 200 OK Content-Type: text/xml; charset=utf-8 <?xml version="1.0" encoding="UTF-8"?> <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"> <soapenv:Body> <rpc-reply id="101" xmlns="http://ietf.org/netconf/1.0/base"> <config xmlns="http://example.com/schema/1.2/config"> <users> <user> <name>root</name> <type>superuser</type> </user> <user> <name>fred</name> <type>admin</type> </user> <user> <name>barney</name> <type>admin</type> </user> </users> </config> </rpc-reply> </soapenv:Body> </soapenv:Envelope> 3.6 Managing Multiple Devices When a server is acting as a proxy for multiple devices, the URL for the HTTP POST can be used to indicate which device is the target. It may also be desirable to use the HTTP POST URL as a means for selecting from multiple virtual devices on a single device.4. Security Considerations NETCONF is used to access and modify configuration information, so the ability to access this protocol should be limited to users and systems that are authorized to view or modify the agent's configuration data. Because configuration information is sent in both directions, it is not sufficient for just the client or user to be authenticated with the server. The identity of the server should also be authenticated with the client. Configuration data may include sensitive information, such as user names or security keys. So, NETCONF should only be used over communications channels that provide strong encryption for data privacy. If the NETCONF server provides remote access through insecure protocols, such as HTTP, care should be taken to prevent execution of the NETCONF program when strong user authentication or data privacy is not available. 4.1 Integrity, Privacy, and Authentication The NETCONF SOAP binding relies on an underlying secure transport for integrity and privacy. Such transports are expected to include TLS  and IPSec. There are a number of options for authentication (some of which are deployment-specific): o within the transport (such as with TLS client certificates) o within HTTP (such as Digest Access Authentication )) o within SOAP (such as a digital signature in the header )) HTTP and SOAP level authentication can be integrated with RADIUS  to support remote authentication databases. 4.2 Vulnerabilities The above protocols may have various vulnerabilities, and these may be inherited by NETCONF/SOAP. NETCONF itself may have vulnerabilities due to the fact that an authorization model is not currently specified. It is important that device capabilities and authorization remain constant for the duration of any outstanding NETCONF session. In the case of NETCONF/SOAP, this constancy must be given particular attention as a sessionNETCONF, it is important to consider that device management may spanbe taking place over multiple HTTP connections.substrates (in addition to SOAP) and it is important that the different substrates have a common authentication model. 4.3 Environmental Specifics Some deployments of NETCONF/SOAP may choose to use HTTP without encryption. This presents vulnerabilities but may be selected for deployments involving closed networks or debugging scenarios. A device managed by NETCONF may interact (over protocols other than NETCONF) with devices managed by other protocols, all of differing security. Each point of entry brings with it a potential vulnerability. Normative References  Enns, R., "XMLCONF Configuration Protocol", draft-enns-xmlconf-spec-00 (work in progress), Feb 2003, <http://www.ietf.org/internet-drafts/ draft-enns-xmlconf-spec-00.txt>.  Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C REC REC-xml-20001006, October 2000, <http://www.w3.org/TR/2000/ REC-xml-20001006>.  Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, N., Nielsen, H., Thatte, S. and D. Winer, "Simple Object Access Protocol (SOAP) 1.1", W3C Note NOTE-SOAP-20000508, May 2000, <http://www.w3.org/TR/2000/NOTE-SOAP-20000508>.  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>.  Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML Schema Part 1: Structures", W3C Recommendation REC-xmlschema-1-20010502, May 2001, <http://www.w3.org/TR/2001/ REC-xmlschema-1-20010502/>.  Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996, <http://www.ietf.org/rfc/rfc2045.txt>.  Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996, <http://www.ietf.org/rfc/rfc2046.txt>.  Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999, <http://www.ietf.org/rfc/ rfc2616.txt>.  Moore, K., "On the use of HTTP as a Substrate", RFC 3205, February 2002, <http://www.ietf.org/rfc/rfc3205.txt>.  Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP: Digest Access Authentication", RFC 2069, January 1997, <http:// www.ietf.org/rfc/rfc2069.txt>.  Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997, <http://www.ietf.org/rfc/ rfc2119.txt>.  Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1999, <http://www.ietf.org/rfc/rfc2246.txt>.  Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 2000, <http://www.ietf.org/rfc/rfc2865.txt>.  Rose, M. and D. New, "Reliable Delivery for syslog", RFC 3195, November 2001, <http://www.ietf.org/rfc/rfc3195.txt>. Informative References  Enns, R., "NETCONF Configuration Protocol", draft-ietf-netconf-prot-00 (work in progress), Aug 2003, <http://www.ietf.org/internet-drafts/ draft-ietf-netconf-prot-00.txt>.  Barton, J., Nielsen, H. and S. Thatte, "SOAP Messages with Attachments", W3C Note NOTE-SOAP-attachments-20001211, Dec 2000, <http://www.w3.org/TR/2000/ NOTE-SOAP-attachments-20001211>.  Brown, A., Fox, B., Hada, S., LaMacchia, B. and H. Maruyama, "SOAP Security Extensions: Digital Signature", W3C Note NOTE-SOAP-dsig-20010206, Feb 2001, <http://www.w3.org/TR/2001/ NOTE-SOAP-dsig-20010206/>.  Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001, <http://www.ietf.org/rfc/rfc3080.txt>.  O'Tuathail, E. and M. Rose, "Using the Simple Object Access Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)", RFC 3288, June 2002, <http://www.ietf.org/rfc/rfc3288.txt>. Author's Address Ted Goddard Wind River Systems #180, 6815-8th Street NEICEsoft Technologies Inc. Suite 300, 1717 10th St. NW Calgary, AB T2E 7H7T2M 4S2 Canada Phone: (403) 730-7590663-3322 EMail: email@example.com@icesoft.com URI: http://www.windriver.comhttp://www.icesoft.com Appendix A. WSDL Definitions A.1 NETCONF SOAP Binding The following WSDL document assumes a hypothetical location for the NETCONF schema. <?xml version="1.0" encoding="UTF-8"?> <definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://ietf.org/netconf/1.0/soap" xmlns:xb="http://ietf.org/netconf/1.0/base" targetNamespace="http://ietf.org/netconf/1.0/soap" name="http://ietf.org/netconf/1.0/soap"> <import namespace="http://ietf.org/netconf/1.0/base" location="base.xsd"/> <message name="rpcRequest"> <part name="in" element="xb:rpc"/> </message> <message name="rpcResponse"> <part name="out" element="xb:rpc-reply"/> </message> <portType name="rpcPortType"> <operation name="rpc"> <input message="tns:rpcRequest"/> <output message="tns:rpcResponse"/> </operation> </portType> <binding name="rpcBinding" type="tns:rpcPortType"> <SOAP:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/> <operation name="rpc"> <SOAP:operation/> <input> <SOAP:body use="literal" namespace="http://ietf.org/netconf/1.0/base"/> </input> <output> <SOAP:body use="literal" namespace="http://ietf.org/netconf/1.0/base"/> </output> </operation> </binding> </definitions> A.2 Sample Service Definition The following WSDL document assumes a hypothetical location for the NETCONF/SOAP WSDL definitions. A typical deployment of a device manageable via NETCONF/SOAP would provide a service definition similar to the following to identify the address of the device. <?xml version="1.0" encoding="UTF-8"?> <definitions xmlns="http://schemas.xmlsoap.org/wsdl/" xmlns:SOAP="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:xs="http://ietf.org/netconf/1.0/soap" targetNamespace="urn:myNetconfService" name="myNetconfService.wsdl"> <import namespace="http://ietf.org/netconf/1.0/soap" location="soap.wsdl"/> <service name="netconf"> <port name="rpcPort" binding="xs:rpcBinding"> <SOAP:address location="http://localhost:8080/netconf"/> </port> </service> </definitions> Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003).(2004). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society.