Network Working Group T. Iijima Internet-Draft Y. Atarashi Intended status: Informational H. Kimura Expires: May 22, 2008 M. Kitani Alaxala Networks Corp. H. Okita Central Research Laboratory, Hitachi, Ltd. November 19, 2007 Experience of implementing NETCONF over SOAP draft-iijima-netconf-soap-implementation-04 Status of this Memo By submitting this Internet-Draft, each 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 becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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 May 22, 2008. Copyright Notice Copyright (C) The IETF Trust (2007). Iijima, et al. Expires May 22, 2008 [Page 1] Internet-Draft SOAP implementation November 2007 Abstract NETCONF protocol is standardized to be exchanged over SSH, SOAP, or BEEP. We developed a network management system based on NETCONF protocol. For several reasons, we chose the SOAP protocol as a transport protocol of NETCONF. This document describes why we chose SOAP as a transport protocol and the insight gained from actual development. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. NETCONF over SOAP . . . . . . . . . . . . . . . . . . . . 3 1.2. Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 1.3. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Framework of Web service . . . . . . . . . . . . . . . . . . . 4 2.1. SOAP as a Transport Protocol . . . . . . . . . . . . . . . 4 2.2. WSDL as an Interface Description Language . . . . . . . . 5 3. Architecture of NETCONF over SOAP implementation . . . . . . . 6 3.1. SOAP implementation in NMS . . . . . . . . . . . . . . . . 7 3.1.1. SOAP Engine in NMS . . . . . . . . . . . . . . . . . . 7 3.1.2. Session maintenance in NMS . . . . . . . . . . . . . . 7 3.2. SOAP implementation in network equipment . . . . . . . . . 8 3.2.1. SOAP Engine in network equipment . . . . . . . . . . . 8 3.2.2. Session maintenance in network equipment . . . . . . . 8 4. Guideline of developing NETCONF client and server . . . . . . 9 4.1. Procedures of development of NETCONF client . . . . . . . 9 4.1.1. Developing NETCONF client without Eclipse . . . . . . 10 4.1.2. Developing NETCONF client with Eclipse . . . . . . . . 10 4.2. Procedures of development of NETCONF server . . . . . . . 12 4.2.1. Developing NETCONF server without Eclipse . . . . . . 13 4.2.2. Developing NETCONF server with Eclipse . . . . . . . . 14 4.2.3. Developing NETCONF server by C programming . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.1. Normative References . . . . . . . . . . . . . . . . . . . 19 7.2. Informative References . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 22 Iijima, et al. Expires May 22, 2008 [Page 2] Internet-Draft SOAP implementation November 2007 1. Introduction 1.1. NETCONF over SOAP In order to enable network equipment configuration automatically from network systems, NETCONF is designed to use XML as its description language since XML is easy for systems to understand. XML is a suitable technology to cope with flexible specification changes and frequent functional extensions, and it enables automatic operation. SOAP is also designed to use XML and is expected to become an indispensable technology of Web service. For this reason, SOAP is a prospective technology and well suited to the NETCONF protocol. 1.2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC2119 [3]. 1.3. Motivation This document describes why SOAP is practical as a transport protocol of NETCONF in developing a network management system. This document also describes the experience of implementing NETCONF over SOAP. Iijima, et al. Expires May 22, 2008 [Page 3] Internet-Draft SOAP implementation November 2007 2. Framework of Web service SOAP is considered to be an indispensable technology of Web service. So if we use SOAP as a transport protocol of NETCONF, network configuration by NETCONF is achieved on a framework of Web service. In this section, we describe the overall architecture of the Web service. +---+ +-----------+ +----------------+ +--------------+ +--------+ | | | Security | |Reliable Message| | Transaction | | Search | |XML| | | | | | | | | | | |WS-Security| | WS-Reliability | |WS-Transaction| | UDDI | | | | | | | | | +--------+ | | | | | | | | +--------+ +---------+ | | | | | | | | |language| | API | | | | | | | | | | | | | | | | | | | | | | WSDL | | JAXM | | | +-----------+ +----------------+ +--------------+ +--------+ | JAX-RPC | | | +----------------------------------------------------------+ | .NET | | | | Fundamental Messaging | | | | | | | | | | | | SOAP | | | +---+ +----------------------------------------------------------+ +---------+ +----------------------------------------------------------+ | Transport | | | | HTTP, HTTPS... | +----------------------------------------------------------+ Figure 1: Overall architecture of Web service As depicted in figure 1, peripheral technologies around SOAP/HTTP are well developed, including security technology. For instance, WS- Security and WS-Transaction technology are installed on SOAP only by inserting particular messages in the SOAP Header. If we do not choose SOAP/HTTP as a transport layer of the NETCONF protocol, we have to develop each surrounding technology from scratch. Hence, when introducing additional technologies around SOAP, the development of a NETCONF-based network management system is relatively easy when we choose SOAP as a transport protocol of NETCONF. 2.1. SOAP as a Transport Protocol SOAP is basically designed to use distributed objects scattered around the Internet regardless of platform. Therefore, SOAP is developed as a messaging technology that uses standardized internet Iijima, et al. Expires May 22, 2008 [Page 4] Internet-Draft SOAP implementation November 2007 technologies such as HTTP and XML. In addition, SOAP is so flexible that it is easy to incorporate other technologies. For instance, the notion of session can be easily incorporated in SOAP by inserting a message ID into a SOAP Header. 2.2. WSDL as an Interface Description Language WSDL is designed so as to bind easily with SOAP. WSDL is an innovative technology for Web service since the development tool automatically generates interfaces to Web service by simply importing WSDL into the development tool. Developers only need to customize the programs by putting the generated interfaces together. Regarding development tools that understand WSDL, useful technologies are available with SOAP. For instance, Apache Axis is an interface generator from WSDL as well as a widely used SOAP implementation written in Java. If we choose SOAP as a transport protocol, we do not need to develop interfaces to Web service by ourselves owing to the development tool. Iijima, et al. Expires May 22, 2008 [Page 5] Internet-Draft SOAP implementation November 2007 3. Architecture of NETCONF over SOAP implementation In this section, we describe the architecture of NETCONF implementation using SOAP as its transport protocol. Figure 2 is the architecture of the NETCONF implementation using SOAP. SOAP implementation is implemented on both a network management system and network equipment. And each SOAP implementation exchanges SOAP messages based on the WSDL which is provided by [2]. If Java library which is generated from the WSDL are provided on the network management system, engineers can develop NETCONF application, which can configure network equipment via the NETCONF protocol, by utilizing the Java library. Engineers don't need to write neither SOAP nor XML directly by hands. NETCONF application developed in network management system works as a NETCONF client while network equipment acts as a NETCONF server. +-------------------------------------------------------+ | Network Management System | | | | +--------------------------------------------+ | | | NETCONF application | | | +--------------------------------------------+ | | +--------------------------------------------+ | | | Java library | | | +--------------------------------------------+ | | +--------------------------------------------+ | | | SOAP Implementation | | | | | | | | Apache Axis | | | +--------------------------------------------+ | +---------------------|----------^----------------------+ | | rpc-request | | rpc-reply / SOAP | | / SOAP / HTTP(S) | | / HTTP(S) | | +---------------------v----------|----------------------+ | +--------------------------------------------+ | | | SOAP Implementation | | | +--------------------------------------------+ | | | | Network Equipment | +-------------------------------------------------------+ Figure 2: Architecture of NETCONF implementation using SOAP Iijima, et al. Expires May 22, 2008 [Page 6] Internet-Draft SOAP implementation November 2007 In the following section, we explain the SOAP implementation in detail in both NMS (Network Management System) and network equipment. 3.1. SOAP implementation in NMS Several SOAP implementations capable of being installed on NMS are available today. For instance, Apache Axis is a practical free software implementation of SOAP when we choose SOAP as a transport protocol. Rapid parsing in the NMS is achieved by Axis since it uses SAX as its parser. Also, Axis is not only a SOAP implementation but a useful tool to develop a NMS. For instance, WSDL2Java, one of Axis's tools, can generate Java's class file from WSDL file. Another tool called Java2WSDL does the opposite. We can generate WSDL file from Java's class file. Conclusively, various kinds of benefits can be acquired if we introduce Axis as a SOAP implementation. In order to develop NETCONF-capable applications, Java library, which is generated by Apache Axis tool and run over SOAP implementation, has to be extended to incorporate such functions as session management and releasing of log messages. By utilizing these Java library, engineers can easily develop NETCONF applications. 3.1.1. SOAP Engine in NMS The function of SOAP Engine is totally left to a SOAP implementation such as Apache Axis. 3.1.2. Session maintenance in NMS When exchanging NETCONF messages between NMS and network equipment, implementation of session maintenance function is necessary in both sides. We used Cookie field in a HTTP header as a session identifier and implemented a session maintenance function which manages the Cookie field. After NMS sends a NETCONF hello message to network equipment, NMS receives a newly allocated session identifier which is written in the Cookie field of a replying hello message. NMS preserves the Cookie paired with the network equipment's MAC address and uses it for the subsequent NETCONF messages exchange as a session identifier. When NMS sets the Cookie for the following NETCONF messages, the network equipment recognize it and maintains sessions. The stored Cookie is erased when the NMS sends a close session message and received a response message from network equipment. Iijima, et al. Expires May 22, 2008 [Page 7] Internet-Draft SOAP implementation November 2007 3.2. SOAP implementation in network equipment SOAP must also be implemented in the network equipment in order to accept SOAP messages sent from the NMS. Like the case of NMS, some free SOAP implementations to be installed on network equipment are available today. However, in the case of network equipment, memory capacity might be limited. Therefore, SOAP implementation have to be chosen taking memory capacity into consideration, and memory saving method might be required when implementing SOAP engine in the network equipment. 3.2.1. SOAP Engine in network equipment When we choose HTTP as an underlying protocol over which SOAP is sent, the SOAP message consists of HTTP header and a SOAP Envelope. The SOAP Envelope is a necessary part of every SOAP message. But in regard to the SOAP encodingStyle attribute inside the Envelope elements, it is not required to be specified. In such a case, default encodingStyle of "http://schema.xmlsoap.org/soap/encoding" is applied. So if there's a memory constraint, we can omit a function of parsing encodingStyle. Similarly, SOAP Header inside the SOAP Envelope is defined as optional. So, when memory capacity in network equipment is insufficient, the module that processes SOAP Header can be omitted. After all, a SOAP engine in network equipment is allowed to act only as a SOAP Envelope and Body parser. 3.2.2. Session maintenance in network equipment In order to maintain sessions with the NMS, SOAP implementation in network equipment must provide session identifier to the NMS. When network equipment receives NETCONF hello message from the NMS, SOAP implementation in network equipment sets session identifier paired with network equipment's MAC address in a Cookie field of the HTTP header and sends it back as a response message. The session identifier is used when locking the configuration of the network equipment. When network equipment receives a NETCONF close message from the NMS, the network equipment erases the Cookie identifier. Iijima, et al. Expires May 22, 2008 [Page 8] Internet-Draft SOAP implementation November 2007 4. Guideline of developing NETCONF client and server NETCONF implementations running on SOAP implementation in NMS and in network equipment acts as NETCONF client and NETCONF server respectively. By making full use of various tools such as Apache Axis, Apache Ant, Eclipse and so on, it becomes easier to develop SOAP-based NETCONF client and server. 4.1. Procedures of development of NETCONF client In order to develop SOAP-based NETCONF client, stub codes is necessary. Stub is a library, which is generated automatically from WSDL by a Web service tool and shows interfaces toward Web service as methods available in local package. When using Apache Axis as a Web service tool, generated stub is in a form of Java library. WSDL file named "netconf-soap_1.0.wsdl" extracted from [2] is specifying NETCONF messages to be exchanged between NETCONF client and server. However, the file is not enough for generating stub code since service element is not specified. By adding service element of, for example, "NetconfService" to "netconf-soap_1.0.wsdl", stub files such as "NetconfService.java", "NetconfServiceLocator.java", and "NetconfBindingStub.java" are generated. In addition, as for interfaces of how to configure network equipment such as "get- config", "edit-config", [2] is importing XML schema file named "netconf.xsd" of [1]. In regards to interfaces of what network functions to be configured, however, data models have to be defined in a style of XML schema and be imported to [2]. The connection between NETCONF schema and data model should be done by inserting , which is defined in NETCONF schema [1], into each data model's elements. From the "netconf-soap_1.0.wsdl" importing NETCONF schema and data model, we can generate stub files containing interfaces to configure network equipment. Before generating stub codes, development environment needs to be arranged. When developing Java-based NETCONF client, JDK (Java Development Kit), and Apache Axis are necessary. In addition, some IDE (Integrated Development Environment) such as Eclipse, NetBeans and hopefully Apache Ant would reduce developers workload significantly. When using Eclipse as an IDE, first of all, library (*.jar files) of Apache Axis have to be added to development project's build path as an external library. Since library of Apache Axis acts as SOAP library, we don't need to be aware of SOAP messaging when developing NETCONF client. Iijima, et al. Expires May 22, 2008 [Page 9] Internet-Draft SOAP implementation November 2007 4.1.1. Developing NETCONF client without Eclipse Stub is generated by executing following command in DOS-prompt on the assumption that netconf-soap_1.0.wsdl, namely WSDL file extracted from [2], is placed in the directory of "C:\NetconfClient" and in the environment of Windows computer without Eclipse. C:\NetconfClient>java -classpath .;%AXIS_HOME%\lib\axis.jar;% AXIS_HOME%\lib\jaxrpc.jar;%AXIS_HOME%\lib\saaj.jar;%AXIS_HOME% \lib\commons-logging-1.0.4.jar;%AXIS_HOME%\lib\commons-discovery- 0.2.jar;%AXIS_HOME%\lib\wsdl4j-1.5.1.jar org.apache.axis.wsdl.WSDL2Java -p stub netconf-soap_1.0.wsdl In the directory where WSDL file is located, WSDL2Java command was executed. In the case we don't use Eclipse, locations of each Axis library has to be specified as a class path. "AXIS_HOME" is a directory where Apache Axis is installed. By executing above command, files with extension of "*.java" are generated in the "stub" directory, which is specified by above command. Inside the stub directory, we can find files such as "NetconfBindingStub.java", "Hello.java", and "GetConfigType.java" and the like. Then, we compiled them by executing following command in DOS-prompt. C:\NetconfClient>javac -classpath .;%AXIS_HOME%\lib\axis.jar;% AXIS_HOME%\lib\jaxrpc.jar stub/*.java Compiling those java files will generate "*.class" files. At the time of compiling, encoding style might be taken care of. After compiling, we wrote source code of the NETCONF client utilizing stub's classes and interfaces which are imported to local package and referenced. Functions such as session management, releasing of log messages, and son on have to be incorporated at this stage. And again, we compiled the source code of the NETCONF client. NETCONF client can be developed by taking these procedures. 4.1.2. Developing NETCONF client with Eclipse In the case we use Eclipse and Apache Ant, above procedures are significantly simplified and executed at one time. In this case, files named "build.xml" and "build.properties" are required for Apache Ant. Examples of "Build.xml" and "build.properties" are shown in Figure 3 and Figure 4 respectively. Iijima, et al. Expires May 22, 2008 [Page 10] Internet-Draft SOAP implementation November 2007 Figure 3: build.xml of NETCONF client axis.libdir=C:/axis-1_4/lib srcdir=src destdir=classes stub.stubdir=stub stub.wsdlpath=netconf-soap_1.0.wsdl stub.jar=NETCONF.jar Figure 4: build.properties of NETCONF client Iijima, et al. Expires May 22, 2008 [Page 11] Internet-Draft SOAP implementation November 2007 The location of WSDL file has to be specified in the "build.properties" file. In the case of Figure 4, the location of WSDL file is specified as under the current directory. As shown in Figure 4, after generating NETCONF stub code, Apache Ant will generate NETCONF.jar file, which is compressing all stub files (*.class) and acts as a library. The NETCONF.jar file also have to be added to development project's build path as an external library. After adding NETCONF.jar file to build path, we wrote NETCONF client's source codes utilizing stub's classes and interfaces. Functions such as session management, releasing of log messages, and son on have to be incorporated at this stage. And we compiled them and developed the NETCONF client. 4.2. Procedures of development of NETCONF server There are two ways of developing Web service provider. The one is called top-down approach, and another is called bottom-up approach. The top-down approach is done by first designing WSDL file, and then generate skeleton source code from WSDL file by using a Web service tool such as Apache Axis. Generated skeleton code just provides template of the source code. So generated skeleton code requires additional source codes in order to work as a Web service provider. This way is superior to bottom-up approach in terms of interoperability since specification is already defined in WSDL file. By contrast, the bottom-up approach is first creating Web service from a source code (e.x. Java bean) and then generating WSDL file from the source code by using a Web service tool such as Apache Axis. This approach is faster and easier than top-down approach. But in the case of bottom-up approach, ensuring the interoperability becomes difficult since implementation of Web service becomes vendor- specific. In the case of developing NETCONF server, since WSDL file is already defined in [2], there's no choice but to develop NETCONF server by top-down approach. The rest of the section mentions the top-down approach of developing NETCONF server. In order to develop SOAP-based NETCONF server by top-down approach, skeleton code is necessary. Skeleton is a library, which is also generated automatically from WSDL by a Web service tool. When using Apache Axis as a Web service tool, generated skeleton is in a form of Java library. From the same WSDL file as the one being used for generating stub, skeleton files such as "NetconfBindingSkeleton.java", "Hello.java", "GetConfigType.java", and so forth are generated. Before generating skeleton codes, development environment needs to be Iijima, et al. Expires May 22, 2008 [Page 12] Internet-Draft SOAP implementation November 2007 arranged. When developing Java-based NETCONF server, servlet container such as Apache Tomcat is necessary in addition to JDK, Apache Axis. And the directory of "webapps\axis" under Apache Axis have to be copied to the directory of "webapps" under Apache Tomcat. 4.2.1. Developing NETCONF server without Eclipse Skeleton is generated by executing following command in DOS-prompt on the assumption that netconf-soap_1.0.wsdl, namely WSDL file extracted from [2], is placed in the directory of "C:\NetconfServer" and in the environment of Windows computer without Eclipse. C:\NetconfClient>java -classpath .;%AXIS_HOME%\lib\axis.jar;% AXIS_HOME%\lib\jaxrpc.jar;%AXIS_HOME%\lib\saaj.jar;%AXIS_HOME% \lib\commons-logging-1.0.4.jar;%AXIS_HOME%\lib\commons-discovery- 0.2.jar;%AXIS_HOME%\lib\wsdl4j-1.5.1.jar org.apache.axis.wsdl.WSDL2Java -p skeleton -s -S true -d Session netconf-soap_1.0.wsdl In the directory where WSDL file is located, WSDL2Java command was executed. In the case we don't use Eclipse, locations of each Axis library have to be specified as a class path. "AXIS_HOME" is a directory where Apache Axis is installed. By executing above command, files with extension of "*.java" are generated in the "skeleton" directory, which is specified in the above command. Inside the skeleton directory, we can find files such as "NetconfBindingSkeleton.java", "Hello.java", and "GetConfigType.java" and the like. Furthermore, files named "deploy.wsdd" and "undeploy.wsdd" are found. "Deploy.wsdd" and "undeploy.wsdd" are used when deploying NETCONF service to servlet container and undeploying NETCONF service from servlet container respectively. Then, it is required to add source code of the NETCONF server to the skeleton code such as "NetconfBindingImpl.java". Functions such as session management, releasing of log messages, and son on have to be added at this stage. And compiling these java files by executing following command in DOS-prompt will generate "*.class" files. C:\NetconfClient>javac -classpath .;%AXIS_HOME%\lib\axis.jar;% AXIS_HOME%\lib\jaxrpc.jar skeleton/*.java NETCONF server can be developed by taking these procedures. Then, it is required to copy these class files into the directory of "webapps\axis\WEB-INFO/classes" of Apache Tomcat. Finally, it is required to deploy NETCONF service by executing following command. At this time, "deploy.wsdd", which was generated at the time of generating skeleton, is required. C:\NetconfClient>java -classpath .;%AXIS_HOME%\lib\axis.jar;% Iijima, et al. Expires May 22, 2008 [Page 13] Internet-Draft SOAP implementation November 2007 AXIS_HOME%\lib\jaxrpc.jar;%AXIS_HOME%\lib\saaj.jar;%AXIS_HOME% \lib\commons-logging-1.0.4.jar;%AXIS_HOME%\lib\commons-discovery- 0.2.jar org.apache.axis.client.AdminClient -p 832 depoy.wsdd In the direcotory where "deploy.wsdd" is located, the command was executed. 4.2.2. Developing NETCONF server with Eclipse In the case we use Eclipse and Apache Ant, above procedures are significantly simplified and executed at one time. In this case, files named "build.xml" and "build.properties" are required for Apache Ant. Examples of "Build.xml" and "build.properties" are shown in Figure 5 and Figure 6 respectively. Iijima, et al. Expires May 22, 2008 [Page 14] Internet-Draft SOAP implementation November 2007 Iijima, et al. Expires May 22, 2008 [Page 15] Internet-Draft SOAP implementation November 2007 Figure 5: build.xml of NETCONF server axis.libdir=C:/axis-1_4/lib tomcat.axis.classesdir= C:/Program Files/Apache Software Foundation/Tomcat 6.0/ webapps/axis/WEB-INF/classes srcdir=src destdir=classes skeleton.skeletondir=skeleton skeleton.wsdlpath=netconf-soap_1.0.wsdl skeleton.destdir=classes/skeleton deploy.port=832 deploy.ddname=deploy.wsdd Figure 6: build.properties of NETCONF server The location of WSDL file and "deploy.wsdd" file have to be specified in the "build.properties" file. In the case of Figure 6, the location of WSDL file and "deploy.wsdd" file are specified as under the current directory. After generating skeleton, it is required to add source code of the NETCONF server to skeleton code. Functions such as session management, releasing of log messages, and so on have to be added at this stage. And by compiling these files, class files of NETCONF server will be generated. Then it is required to copy these class files to the directory of Tomcat and to deploy the NETCONF service. After that, NETCONF server will become accessible from the NETCONF client. 4.2.3. Developing NETCONF server by C programming When implementing NETCONF server on network equipment, memory capacity might be limited and it might be unattainable to install Java environment on network equipment. Or platform of network equipment might not be the one which doesn't support Web service tool. In that case, implementing SOAP engine as well as NETCONF server on network equipment by C programming might be required. In order to develop NETCONF server capable of receiving NETCONF message which is sent over SOAP/HTTP, HTTP daemon and NETCONF daemon are necessary to be implemented inside network equipment. A commonly used HTTP daemon needs to be added with a SOAP engine and a connector to NETCONF daemon. After HTTP daemon receives a SOAP message which is sent over HTTP, the SOAP engine incorporated in the HTTP daemon removes the SOAP Header and passes NETCONF messages on to NETCONF daemon. Then, NETCONF daemon parses the NETCONF messages and configure the network equipment accordingly. Iijima, et al. Expires May 22, 2008 [Page 16] Internet-Draft SOAP implementation November 2007 5. Security Considerations Security should be considered from two angles. One is transport- level security, and the other is message-level security. Transport- level security, such as encryption of entire messages, is a matter of SSL/TLS. However, message-level security, such as partial encryption of messages or signatures, should be done by using other technologies. To fulfill that need, WS-security has been defined. WS-Security is a Web service technology and is dependent on SOAP technology. WS-Security technology can be incorporated by inserting XML encryption and XML signatures into the SOAP Header. Also, WS-Reliability achieves confirmation of sent messages and resending of messages. WS-Reliability is also achieved by inserting particular messages into the SOAP Header. Iijima, et al. Expires May 22, 2008 [Page 17] Internet-Draft SOAP implementation November 2007 6. IANA Considerations This document has no actions for IANA. Iijima, et al. Expires May 22, 2008 [Page 18] Internet-Draft SOAP implementation November 2007 7. References 7.1. Normative References [1] Enns, R., "NETCONF Configuration Protocol", RFC 4741, December 2006. [2] Goddard, T., "Using NETCONF over the Simple Object Access Protocol (SOAP)", RFC 4743, December 2006. 7.2. Informative References [3] Bradner, S. , "Key words for use in RFCs to Indicate Requirement Levels" , BCP 14 , RFC 2119 , March 1997 . [4] Sperberg-McQueen, C. , Paoli, J. , and T. Bray , "XML 1.0 Recommendation" , World Wide Web Consortium FirstEdition REC- xml-19980210 , February 1998 , . [5] "Web Services - Axis" . [6] "Web Service Description Language (WSDL) 1.1". [7] "Apache Ant". [8] "Apache Tomcat". [9] "Eclipse". [10] "NetBeans". [11] "Java SE". Iijima, et al. Expires May 22, 2008 [Page 19] Internet-Draft SOAP implementation November 2007 Authors' Addresses Iijima Tomoyuki Alaxala Networks Corp. Shin-Kawasaki Mitsui Bldg. 890 Saiwai-ku Kashimada Kawasaki, Kanagawa 212-0058 Japan Phone: +81-44-549-1735 Fax: +81-44-549-1272 Email: tomoyuki.iijima@alaxala.com Yoshifumi Atarashi Alaxala Networks Corp. Shin-Kawasaki Mitsui Bldg. 890 Saiwai-ku Kashimada Kawasaki, Kanagawa 212-0058 Japan Phone: +81-44-549-1735 Fax: +81-44-549-1272 Email: atarashi@alaxala.net Hiroyasu Kimura Alaxala Networks Corp. Shin-Kawasaki Mitsui Bldg. 890 Saiwai-ku Kashimada Kawasaki, Kanagawa 212-0058 Japan Phone: +81-44-549-1735 Fax: +81-44-549-1272 Email: h-kimura@alaxala.net Iijima, et al. Expires May 22, 2008 [Page 20] Internet-Draft SOAP implementation November 2007 Makoto Kitani Alaxala Networks Corp. Shin-Kawasaki Mitsui Bldg. 890 Saiwai-ku Kashimada Kawasaki, Kanagawa 212-0058 Japan Phone: +81-44-549-1735 Fax: +81-44-549-1272 Email: makoto.kitani@alaxala.com Hideki Okita Central Research Laboratory, Hitachi, Ltd. 1-280 Higashi-Koigakubo Kokubunji, Tokyo 185-8601 Japan Phone: +81-42-323-1111 Fax: +81-42-327-7868 Email: hideki.okita.pf@hitachi.com Iijima, et al. Expires May 22, 2008 [Page 21] Internet-Draft SOAP implementation November 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights 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; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Iijima, et al. Expires May 22, 2008 [Page 22]