idnits 2.17.1 draft-ietf-netconf-soap-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 16, 2003) is 7496 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: '5' is defined on line 521, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 539, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 2616 (ref. '7') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2069 (ref. '8') (Obsoleted by RFC 2617) ** Obsolete normative reference: RFC 2246 (ref. '10') (Obsoleted by RFC 4346) == Outdated reference: A later version (-12) exists of draft-ietf-netconf-prot-00 -- Obsolete informational reference (is this intentional?): RFC 3288 (ref. '17') (Obsoleted by RFC 4227) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 netconf T. Goddard 3 Internet-Draft Wind River Systems 4 Expires: April 15, 2004 October 16, 2003 6 NETCONF Over SOAP 7 draft-ietf-netconf-soap-00 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at http:// 24 www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet-Draft will expire on April 15, 2004. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 The configuration protocol NETCONF is applicable to a wide range of 38 devices in a variety of environments. The emergence of Web Services 39 gives one such environment, and is presently characterized by the use 40 of SOAP over HTTP. NETCONF finds many benefits in this environment: 41 from the use of existing standards, to ease of software development, 42 to integration with deployed systems. Herein, we describe a SOAP 43 over HTTP binding that, when used with multiple persistent HTTP 44 connections, yields an application protocol sufficient for NETCONF. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. SOAP Background for NETCONF . . . . . . . . . . . . . . . . 4 50 2.1 Use and Storage of WSDL and XSD . . . . . . . . . . . . . . 4 51 2.2 SOAP over HTTP . . . . . . . . . . . . . . . . . . . . . . . 5 52 2.3 HTTP Drawbacks . . . . . . . . . . . . . . . . . . . . . . . 5 53 2.4 Important HTTP 1.1 Features . . . . . . . . . . . . . . . . 6 54 3. A SOAP Web Service for NETCONF . . . . . . . . . . . . . . . 7 55 3.1 Fundamental Use Case . . . . . . . . . . . . . . . . . . . . 7 56 3.2 Mapping NETCONF Channels to HTTP Connections . . . . . . . . 7 57 3.2.1 Asynchronous Functionality . . . . . . . . . . . . . . . . . 7 58 3.3 NETCONF Sessions . . . . . . . . . . . . . . . . . . . . . . 8 59 3.4 Capabilities Exchange . . . . . . . . . . . . . . . . . . . 9 60 3.5 A NETCONF/SOAP example . . . . . . . . . . . . . . . . . . . 9 61 3.6 Managing Multiple Devices . . . . . . . . . . . . . . . . . 10 62 4. Security Considerations . . . . . . . . . . . . . . . . . . 11 63 4.1 Integrity, Privacy, and Authentication . . . . . . . . . . . 11 64 4.2 Vulnerabilities . . . . . . . . . . . . . . . . . . . . . . 11 65 4.3 Environmental Specifics . . . . . . . . . . . . . . . . . . 12 66 Normative References . . . . . . . . . . . . . . . . . . . . 13 67 Informative References . . . . . . . . . . . . . . . . . . . 15 68 Author's Address . . . . . . . . . . . . . . . . . . . . . . 15 69 A. WSDL Definitions . . . . . . . . . . . . . . . . . . . . . . 16 70 A.1 NETCONF SOAP Binding . . . . . . . . . . . . . . . . . . . . 16 71 A.2 Sample Service Definition . . . . . . . . . . . . . . . . . 17 72 Intellectual Property and Copyright Statements . . . . . . . 18 74 1. Introduction 76 Given the use of XML [1] and the remote procedure call 77 characteristics, it is natural to consider a binding of the NETCONF 78 [13] operations to a SOAP [2] application protocol. This document 79 proposes a binding of this form. 81 Note that a SOAP binding for NETCONF is not necessarily intended only 82 for managing individual devices. For instance, a server providing a 83 SOAP interface can act as a proxy for multiple devices, possibly 84 connecting to those devices over BEEP [16] or serial lines. In this 85 case it is important to define a data model that appropriately 86 aggregates the devices. 88 In general, SOAP over HTTP is a natural application protocol for 89 NETCONF (essentially because both emphasize remote procedure calls) 90 but there are three areas that require care: the 91 operation, the mechanism for aborting operations, and the 92 notification channel. The reason for this is that all of these 93 functions are asynchronous (from the point of view of the manager) 94 and HTTP is inherently synchronous and client-driven. 96 Four basic topics are presented: SOAP specifics of interest to 97 NETCONF, specifics on implementing NETCONF as a SOAP-based web 98 service, security considerations, and an appendix with functional 99 WSDL. In some sense, the most important part of the document is the 100 brief WSDL document presented in the Appendix. With the right tools, 101 the WSDL combined with the base NETCONF XML Schemas provide machine 102 readable descriptions sufficient for the development of software 103 applications using NETCONF. 105 2. SOAP Background for NETCONF 107 Why introduce SOAP as yet another wrapper around what is already a 108 remote procedure call message? There are, in fact, both technical 109 and practical reasons. The technical reasons are perhaps less 110 compelling, but let's examine them first. 112 SOAP is fundamentally an XML messaging scheme (which is capable of 113 supporting remote procedure call) and it defines a simple message 114 format composed of a "header" and a "body" contained within an 115 "envelope". The "header" contains meta-information relating to the 116 message, and can be used to indicate such things as store-and-forward 117 behaviour or transactional characteristics. In addition, SOAP 118 specifies an optional encoding for the "body" of the message. 119 However, this encoding is not applicable to NETCONF as one of the 120 goals is to have highly readable XML, and SOAP-encoding is optimized 121 instead for ease of automated deserialization. These benefits of the 122 SOAP message structure are basic, but worthwhile due to the fact that 123 they are already standardized. 125 It is the practical reasons that make SOAP over HTTP an interesting 126 choice for device management. It is not difficult to invent a 127 mechanism for exchanging XML messages over TCP, but what is difficult 128 is getting that mechanism supported in a wide variety of tools and 129 operating systems and having that mechanism understood by a great 130 many developers. SOAP over HTTP (with WSDL) is seeing good success 131 at this, and this means that a device management protocol making use 132 of these technologies has advantages in being implemented and 133 adopted. Admittedly, there are interoperability problems with SOAP 134 and WSDL, but such problems have wide attention and can be expected 135 to be resolved. 137 2.1 Use and Storage of WSDL and XSD 139 One of the advantages of using machine readable formats such as Web 140 Services Description Language (WSDL) [3] and XML Schemas [4] is that 141 they can be used automatically in the software development process. 142 With appropriate tools, WSDL and XSD can be used to generate classes 143 that act as remote interfaces or application specific data 144 structures. Other uses, such as document generation and service 145 location, are also common. A great innovation found with many 146 XML-based definition languages is the use of hyperlinks for referring 147 to documents containing supporting definitions. For instance, in 148 WSDL, the import statement 150 153 imports the definitions of XML types and elements from the base 154 NETCONF schema. Ideally, the file containing that schema is hosted 155 on a web server under the authority of the standards body that 156 defined the schema. In this way, dependent standards can be built up 157 over time and all are accessible to automated software tools that 158 ensure adherence to the standards. Thus, it will gradually become as 159 important for iana.org to host documents like 161 http://iana.org/netconf/1.0/base/base.xsd 163 as the IETF now hosts documents such as 165 http://www.ietf.org/rfc/rfc2616.txt 167 2.2 SOAP over HTTP 169 While it is true that SOAP focuses on messages and can be bound to 170 different underlying protocols such as HTTP, SMTP, or BEEP, most 171 existing SOAP implementations support only HTTP or HTTP/TLS. For 172 this discussion we will assume SOAP over HTTP or HTTP/TLS unless 173 otherwise specified. (This also includes applications of IPSec to 174 SOAP over HTTP.) 176 Note that there are a number of advantages to considering SOAP over 177 protocols other than HTTP, as HTTP assigns its very distinct client 178 and server roles by connection initiation. This causes difficulties 179 in supporting asynchronous notification (possibly relieved by 180 replacing SOAP/HTTP with SOAP/BEEP). However, it is also the case 181 that the full potential of HTTP is not currently used by SOAP. For 182 instance, multiple SOAP replies to a single request could be 183 contained in a multipart MIME [6] response. This would be a similar 184 strategy to the use of multipart/related with SOAP attachments [14]. 186 2.3 HTTP Drawbacks 188 HTTP is not the ideal transport for messaging, but it is adequate for 189 the most basic interpretation of "remote procedure call". HTTP is 190 based on a communication pattern whereby the client (which initiates 191 the TCP connection) makes a "request" to the server. The server 192 returns a "response" and this process is continued (possibly over a 193 persistent connection, as described below). This matches the basic 194 idea of a remote procedure call where the caller invokes a procedure 195 on a remote server and waits for the return value. 197 Potential criticisms of HTTP could include the following: 199 o server-initiated data flow is awkward 200 o headers are verbose and text-based 202 o idle connections may be closed by intermediate proxies 204 o data encapsulation must adhere to MIME 206 o bulk transfer relies on stream-based ordering 208 In many ways these criticisms are directed at particular compromises 209 in the design of HTTP. As such, they are important to consider, but 210 it is not clear that they result in fatal drawbacks for a device 211 management protocol. 213 2.4 Important HTTP 1.1 Features 215 HTTP 1.1 [7] includes two important features that provide for 216 relatively efficient transport of SOAP messages. These features are 217 "persistent connections" and "chunked transfer-coding". 219 Persistent connections allow a single TCP connection to be used 220 across multiple HTTP requests. This permits multiple SOAP request/ 221 response message pairs to be exchanged without the overhead of 222 creating a new TCP connection for each request. Given that a single 223 stream is used for both requests and responses, it is clear that some 224 form of framing is necessary. For messages whose length is known in 225 advance, this is handled by the HTTP header "Content-length". For 226 messages of dynamic length, "Chunking" is required. 228 HTTP "Chunking" or "chunked transfer-coding" allows the sender to 229 send an indefinite amount of binary data. This is accomplished by 230 informing the receiver of the size of each "chunk" (substring of the 231 data) before the chunk is transmitted. The last chunk is indicated 232 by a chunk of zero length. Chunking can be effectively used to 233 transfer a large XML document where the document is generated on-line 234 from a non-XML form in memory. 236 In terms of application to SOAP message exchanges, persistent 237 connections are clearly important for performance reasons, and are 238 particularly important when it is the persistence of authenticated 239 connections that is at stake. When one considers that messages of 240 dynamic length are the rule rather than the exception for SOAP 241 messages, it is also clear that Chunking is very useful. In some 242 cases it is possible to buffer a SOAP response and determine its 243 length before sending, but the storage requirements for this are 244 prohibitive for many devices. Together, these two features provide a 245 good foundation for device management using SOAP over HTTP. 247 3. A SOAP Web Service for NETCONF 249 3.1 Fundamental Use Case 251 The fundamental use case for NETCONF over SOAP (NETCONF/SOAP) over 252 HTTP is that of a management console ("manager" role) managing one or 253 more devices running NETCONF agents ("agent" role). The manager 254 initiates one or more HTTP connections to the agent and drives the 255 NETCONF sessions through repeated SOAP messages over HTTP requests. 256 When the manager closes all HTTP connections associated with a 257 session, the NETCONF session is also closed. 259 3.2 Mapping NETCONF Channels to HTTP Connections 261 While the transport of SOAP over BEEP [17] has been specified, the 262 purpose of this discussion is to describe how to map the channel 263 semantics and performance characteristics already assumed by NETCONF 264 onto (possibly persistent) SOAP over HTTP connections. This 265 configuration is chosen because it is the one that benefits most from 266 existing SOAP tools and implementations. It is true that BEEP has 267 many advantages over HTTP for the transport of SOAP messages, but the 268 fact remains that HTTP is currently more widely deployed than BEEP. 269 At some point in the future, NETCONF/SOAP over BEEP may also be of 270 interest. At that time it can be easily dealt with as many of the 271 issues already discussed in this document are pertinent. There would 272 simply be a few enhancements regarding asynchronous notification. 274 NETCONF employs potentially three channels per session: the 275 management channel, the operation channel, and the notification 276 channel. In the SOAP over HTTP binding, each of these channels can 277 be mapped to an individual HTTP connection (although the notification 278 channel may be a BEEP channel in a separate TCP connection). Thus, 279 SOAP messages on one connection (corresponding to the management 280 channel) must be able to refer to SOAP messages on another connection 281 (corresponding to the operation channel) as the "session" is 282 potentially spread across multiple TCP connections. For instance, it 283 may be necessary to abort a time-extended SOAP request on the 284 "operation" HTTP connection by sending an "" message on 285 the "management" HTTP connection. 287 Distinct "operation" and "management" HTTP connections are not 288 defined; the agent may limit the number of HTTP connections in the 289 same session, and each is capable those "management" and "operation" 290 procedure calls supported by NETCONF over SOAP. 292 3.2.1 Asynchronous Functionality 294 NETCONF uses two types of asynchronous functionality, and the mapping 295 of these onto SOAP over HTTP is somewhat problematic. The two 296 asynchronous functions are and notifications on the 297 notification channel, and these are not supported in the SOAP over 298 HTTP application protocol. Instead, the client can periodically poll 299 the appropriate elements of via (on a secondary HTTP 300 connection) to obtain progress information or notification log 301 entries. 303 Additionally, the notification mechanism for NETCONF is specified in 304 an existing standard for reliable syslog [12] and it is suggested 305 that the same mechanism be used with the SOAP binding (it is simply 306 external). If notifications via SOAP over HTTP are desired, it is 307 probably most effective if an HTTP connection is established from the 308 agent to the management console. Such a connection could be 309 established in response to the manager connecting to the device. 310 More sophisticated functionality, such as multiple SOAP replies to a 311 single request, would require enhancements to the SOAP over HTTP 312 specification. 314 3.3 NETCONF Sessions 316 NETCONF sessions are persistent for both performance and semantic 317 reasons. NETCONF session state contains the following: 319 1. Authentication Information 321 2. Capability Information 323 3. Locks 325 4. Pending Operations 327 5. Operation Sequence Numbers 329 Authentication must be maintained throughout a session due to the 330 fact that it is expensive to establish. Capability Information is 331 maintained so that appropriate operations can be applied during a 332 session. Locks are released upon termination of a session as this 333 makes the protocol more robust. Pending operations come and go from 334 existence during the normal course of RPC operations. Operation 335 sequence numbers provide the small but necessary state information to 336 refer to operations during the session. 338 Since it is generally not possible to support a full NETCONF session 339 with a single HTTP connection, it is necessary to identify the 340 NETCONF session in a way that can span multiple HTTP connections. 341 This can be performed with the HTTP request URI, as in the following 342 POST request with the target session "sid-123": 344 POST /netconf/sid-123 HTTP/1.0 345 Content-Type: text/xml; charset=utf-8 346 Content-Length: 470 348 Note that the session identifier must either be known by the manager 349 (in order to attach to an existing session) or be communicated from 350 the agent to the manager prior to the exchange of any significant 351 NETCONF messages. For this, it is recommended that the session 352 identifier be determined via . An empty session identifier 353 may be used in the case where only an operations channel is required 354 (in this case the agent assigns a new session to that HTTP 355 connection). 357 Thus, in the case of SOAP over HTTP, a NETCONF "session" is a 358 collection of HTTP connections with common authenticated users and a 359 common session identifier as indicated in the HTTP reqest URI header. 360 To support automated cleanup, a NETCONF over SOAP session is closed 361 when all connections associated with that session are closed. 363 3.4 Capabilities Exchange 365 Capabilities exchange, if defined through a NETCONF RPC operation, 366 can easily be accommodated in the SOAP binding. 368 3.5 A NETCONF/SOAP example 370 Since the proposed WSDL (in Appendix A.1) uses document/literal 371 encoding, the use of a SOAP header and body has little impact on the 372 representation of a NETCONF operation. This example shows HTTP/1.0 373 for simplicity. 375 POST /netconf HTTP/1.0 376 Content-Type: text/xml; charset=utf-8 377 Accept: application/soap+xml, text/* 378 Cache-Control: no-cache 379 Pragma: no-cache 380 Content-Length: 470 382 383 385 386 387 388 389 390 391 392 393 394 xml 395 396 397 398 400 The HTTP/1.0 response is also straightforward: 402 HTTP/1.0 200 OK 403 Content-Type: text/xml; charset=utf-8 405 406 408 409 410 411 412 413 root 414 superuser 415 416 417 fred 418 admin 419 420 421 barney 422 admin 423 424 425 426 427 428 430 3.6 Managing Multiple Devices 432 When a server is acting as a proxy for multiple devices, the URL for 433 the HTTP POST can be used to indicate which device is the target. It 434 may also be desirable to use the HTTP POST URL as a means for 435 selecting from multiple virtual devices on a single device. 437 4. Security Considerations 439 NETCONF is used to access and modify configuration information, so 440 the ability to access this protocol should be limited to users and 441 systems that are authorized to view or modify the agent's 442 configuration data. 444 Because configuration information is sent in both directions, it is 445 not sufficient for just the client or user to be authenticated with 446 the server. The identity of the server should also be authenticated 447 with the client. 449 Configuration data may include sensitive information, such as user 450 names or security keys. So, NETCONF should only be used over 451 communications channels that provide strong encryption for data 452 privacy. 454 If the NETCONF server provides remote access through insecure 455 protocols, such as HTTP, care should be taken to prevent execution of 456 the NETCONF program when strong user authentication or data privacy 457 is not available. 459 4.1 Integrity, Privacy, and Authentication 461 The NETCONF SOAP binding relies on an underlying secure transport for 462 integrity and privacy. Such transports are expected to include TLS 463 [10] and IPSec. There are a number of options for authentication 464 (some of which are deployment-specific): 466 o within the transport (such as with TLS client certificates) 468 o within HTTP (such as Digest Access Authentication [8]) 470 o within SOAP (such as a digital signature in the header [15]) 472 HTTP and SOAP level authentication can be integrated with RADIUS [11] 473 to support remote authentication databases. 475 4.2 Vulnerabilities 477 The above protocols may have various vulnerabilities, and these may 478 be inherited by NETCONF/SOAP. 480 NETCONF itself may have vulnerabilities due to the fact that an 481 authorization model is not currently specified. 483 It is important that device capabilities and authorization remain 484 constant for the duration of any outstanding NETCONF session. In the 485 case of NETCONF/SOAP, this constancy must be given particular 486 attention as a session may span multiple HTTP connections. 488 4.3 Environmental Specifics 490 Some deployments of NETCONF/SOAP may choose to use HTTP without 491 encryption. This presents vulnerabilities but may be selected for 492 deployments involving closed networks or debugging scenarios. 494 A device managed by NETCONF may interact (over protocols other than 495 NETCONF) with devices managed by other protocols, all of differing 496 security. Each point of entry brings with it a potential 497 vulnerability. 499 Normative References 501 [1] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 502 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C 503 REC REC-xml-20001006, October 2000, . 506 [2] Box, D., Ehnebuske, D., Kakivaya, G., Layman, A., Mendelsohn, 507 N., Nielsen, H., Thatte, S. and D. Winer, "Simple Object Access 508 Protocol (SOAP) 1.1", W3C Note NOTE-SOAP-20000508, May 2000, 509 . 511 [3] Christensen, E., Curbera, F., Meredith, G. and S. Weerawarana, 512 "Web Services Description Language (WSDL) 1.1", W3C Note 513 NOTE-wsdl-20010315, March 2001, . 516 [4] Thompson, H., Beech, D., Maloney, M. and N. Mendelsohn, "XML 517 Schema Part 1: Structures", W3C Recommendation 518 REC-xmlschema-1-20010502, May 2001, . 521 [5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 522 Extensions (MIME) Part One: Format of Internet Message Bodies", 523 RFC 2045, November 1996, . 525 [6] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 526 Extensions (MIME) Part Two: Media Types", RFC 2046, November 527 1996, . 529 [7] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., 530 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 531 HTTP/1.1", RFC 2616, June 1999, . 534 [8] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., 535 Luotonen, A., Sink, E. and L. Stewart, "An Extension to HTTP: 536 Digest Access Authentication", RFC 2069, January 1997, . 539 [9] Bradner, S., "Key words for use in RFCs to Indicate Requirement 540 Levels", RFC 2119, March 1997, . 543 [10] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 544 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 545 1999, . 547 [11] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote 548 Authentication Dial In User Service (RADIUS)", RFC 2865, June 549 2000, . 551 [12] Rose, M. and D. New, "Reliable Delivery for syslog", RFC 3195, 552 November 2001, . 554 Informative References 556 [13] Enns, R., "NETCONF Configuration Protocol", 557 draft-ietf-netconf-prot-00 (work in progress), Aug 2003, 558 . 561 [14] Barton, J., Nielsen, H. and S. Thatte, "SOAP Messages with 562 Attachments", W3C Note NOTE-SOAP-attachments-20001211, Dec 563 2000, . 566 [15] Brown, A., Fox, B., Hada, S., LaMacchia, B. and H. Maruyama, 567 "SOAP Security Extensions: Digital Signature", W3C Note 568 NOTE-SOAP-dsig-20010206, Feb 2001, . 571 [16] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 572 3080, March 2001, . 574 [17] O'Tuathail, E. and M. Rose, "Using the Simple Object Access 575 Protocol (SOAP) in Blocks Extensible Exchange Protocol (BEEP)", 576 RFC 3288, June 2002, . 578 Author's Address 580 Ted Goddard 581 Wind River Systems 582 #180, 6815-8th Street NE 583 Calgary, AB T2E 7H7 584 Canada 586 Phone: (403) 730-7590 587 EMail: ted.goddard@windriver.com 588 URI: http://www.windriver.com 590 Appendix A. WSDL Definitions 592 A.1 NETCONF SOAP Binding 594 The following WSDL document assumes a hypothetical location for the 595 NETCONF schema. 597 598 606 609 610 611 612 613 614 616 617 618 619 620 621 623 624 626 627 628 629 631 632 633 635 636 637 639 641 A.2 Sample Service Definition 643 The following WSDL document assumes a hypothetical location for the 644 NETCONF/SOAP WSDL definitions. A typical deployment of a device 645 manageable via NETCONF/SOAP would provide a service definition 646 similar to the following to identify the address of the device. 648 649 656 659 660 661 662 663 665 667 Intellectual Property Statement 669 The IETF takes no position regarding the validity or scope of any 670 intellectual property or other rights that might be claimed to 671 pertain to the implementation or use of the technology described in 672 this document or the extent to which any license under such rights 673 might or might not be available; neither does it represent that it 674 has made any effort to identify any such rights. Information on the 675 IETF's procedures with respect to rights in standards-track and 676 standards-related documentation can be found in BCP-11. Copies of 677 claims of rights made available for publication and any assurances of 678 licenses to be made available, or the result of an attempt made to 679 obtain a general license or permission for the use of such 680 proprietary rights by implementors or users of this specification can 681 be obtained from the IETF Secretariat. 683 The IETF invites any interested party to bring to its attention any 684 copyrights, patents or patent applications, or other proprietary 685 rights which may cover technology that may be required to practice 686 this standard. Please address the information to the IETF Executive 687 Director. 689 Full Copyright Statement 691 Copyright (C) The Internet Society (2003). All Rights Reserved. 693 This document and translations of it may be copied and furnished to 694 others, and derivative works that comment on or otherwise explain it 695 or assist in its implementation may be prepared, copied, published 696 and distributed, in whole or in part, without restriction of any 697 kind, provided that the above copyright notice and this paragraph are 698 included on all such copies and derivative works. However, this 699 document itself may not be modified in any way, such as by removing 700 the copyright notice or references to the Internet Society or other 701 Internet organizations, except as needed for the purpose of 702 developing Internet standards in which case the procedures for 703 copyrights defined in the Internet Standards process must be 704 followed, or as required to translate it into languages other than 705 English. 707 The limited permissions granted above are perpetual and will not be 708 revoked by the Internet Society or its successors or assignees. 710 This document and the information contained herein is provided on an 711 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 712 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 713 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 714 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 715 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 717 Acknowledgment 719 Funding for the RFC Editor function is currently provided by the 720 Internet Society.