Skip to main content

NETCONF over WebSocket
draft-iijima-netconf-websocket-ps-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Tomoyuki Iijima , Hiroyasu Kimura , Yoshifumi Atarashi , Hidemitsu Higuchi
Last updated 2011-10-20 (Latest revision 2011-03-04)
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-iijima-netconf-websocket-ps-01
NETCONF Working Group                                          T. Iijima
Internet-Draft                                             Hitachi, Ltd.
Intended status: Experimental                                  H. Kimura
Expires: April 23, 2012                                      Y. Atarashi
                                                              H. Higuchi
                                                  Alaxala Networks Corp.
                                                            Oct 21, 2011

                         NETCONF over WebSocket
                  draft-iijima-netconf-websocket-ps-01

Abstract

   This memo proposes transporting NETCONF over WebSocket
   protocol[I-D.ietf-hybi-thewebsocketprotocol].  The use of HTTP and
   Web-based applications are increasing with the emergence of advanced
   drawing technologies and cloud computing.  IT management systems
   supporting browser-based interface are getting common.  It's natural
   for network management systems to support Web-based interface.
   Currently, however, few network management protocols support the
   transportation over HTTP.  Although NETCONF[RFC6241] was defined to
   be sent over SOAP/HTTPS[RFC4743], it was excluded from the options of
   realizing notification mechanism[RFC5277] since HTTP lacks bi-
   directional capabilty.  At present, WebSocket protocol, the update of
   HTTP with bi-directional capability, is available.  This memo
   describes the way NETCONF is sent over WebSocket protocol.

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on April 21, 2012.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the

Iijima, et al.           Expires April 21, 2012                 [Page 1]
Internet-Draft           NETCONF over WebSocket                 Oct 2011

   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Problem Statement  . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Concerns about HTTP and WebSocket  . . . . . . . . . . . . . .  7
   5.  Messages of NETCONF over WebSocket . . . . . . . . . . . . . .  8
     5.1.  Message Sequence . . . . . . . . . . . . . . . . . . . . .  8
     5.2.  WebSocket Message from NETCONF Client at WebSocket
           Handshake  . . . . . . . . . . . . . . . . . . . . . . . . 10
     5.3.  WebSocket Message from NETCONF Server at WebSocket
           Handshake  . . . . . . . . . . . . . . . . . . . . . . . . 11
     5.4.  NETCONF Message over WebSocket Connection  . . . . . . . . 12
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19

Iijima, et al.           Expires April 21, 2012                 [Page 2]
Internet-Draft           NETCONF over WebSocket                 Oct 2011

1.  Introduction

   The use of HTTP and Web-based applications are increasing in contrast
   with install-based applications with the emergence of advanced
   drawing technologies and cloud computing.  IT management systems
   supporting browser-based interface to control IT resources are
   getting common.  It's natural for network management systems to
   support Web-based interface.  Currently, however, few network
   management protocols support transportation over HTTP.  Although
   NETCONF[RFC6241] was defined to be sent over SOAP/HTTPS[RFC4743], it
   was excluded from the options of realizing notification
   mechanism[RFC5277] since HTTP lacks bi-directional capabilty.  At
   present, WebSocket protocol, the update of HTTP with bi-directional
   capability, is available[I-D.ietf-hybi-thewebsocketprotocol].  This
   memo describes the way NETCONF is sent over WebSocket protocol.

   This memo does not intend to standardize NETCONF over WebSocket as a
   mandatory transport mapping of NETCONF.  NETCONF over SSH is defined
   to be mandatory in RFC6241[RFC6241].  But section 2 of RFC6241 also
   specifies that "the NETCONF protocol can be layered on any transport
   protocol that provides the required set of functionality."  According
   to the description of those requirements, "Connection-Oriented
   Operation" and "Authentication, Integrity, and Confidentiality" are
   the required set of functionality.  WebSocket protocol meets those
   requirements.  It is connection-oriented.  And, authentication,
   integrity, and confidentiality are ensured by technologies such as
   masking of payload and sending over TLS.  Thus, WebSocket can become
   one of the optional protocols to transport NETCONF.

Iijima, et al.           Expires April 21, 2012                 [Page 3]
Internet-Draft           NETCONF over WebSocket                 Oct 2011

2.  Problem Statement

   Figure 1 is an architecture of NETCONF extracted from
   RFC6241[RFC6241].  So far there's few ways to easily provide browser-
   based network management system using NETCONF.  Even though SOAP/
   HTTP/TLS is defined as one of the transport protocols for NETCONF, it
   can not provide notification mechanism since HTTP lacks bi-
   directional capability.  AJAX and Comet technologies are often used
   to outwardly provide HTTP with bi-directinal capability by way of
   polling or keeping a long session at the application level.  But,
   those technologies tend to consume large amount of bandwidth and
   memories.  There are cases where such technologies can not be
   accomodated into network devices due to their lack of resources
   (memory, processor).

             Layer                 Example
        +-------------+      +-----------------+      +----------------+
    (4) |   Content   |      |  Configuration  |      |  Notification  |
        |             |      |      data       |      |      data      |
        +-------------+      +-----------------+      +----------------+
               |                       |                      |
        +-------------+      +-----------------+              |
    (3) | Operations  |      |  <edit-config>  |              |
        |             |      |                 |              |
        +-------------+      +-----------------+              |
               |                       |                      |
        +-------------+      +-----------------+      +----------------+
    (2) |  Messages   |      |     <rpc>,      |      | <notification> |
        |             |      |   <rpc-reply>   |      |                |
        +-------------+      +-----------------+      +----------------+
               |                       |                      |
        +-------------+      +-----------------------------------------+
    (1) |   Secure    |      |  SSH, TLS, BEEP/TLS, SOAP/HTTP/TLS, ... |
        |  Transport  |      |                                         |
        +-------------+      +-----------------------------------------+

                     Figure 1: NETCONF Protocol Layers

   At present, WebSocket protocol is being standardized.  It is based on
   HTTP and has a bi-directional capability.  Although standardization
   is still ongoing in IETF, there are already some implementations.
   Jetty[Jetty], Kaazing[Kaazing], and Apache/pywebsocket are available
   as WebSocket servers.  And, Chrome[Chrome] and FireFox[FireFox] are
   available as browsers to run WebSocket clients.  By using WebSocket
   as an underlying protocol for NETCONF, NETCONF client in a network
   management system become browser-based.  And, realtime event

Iijima, et al.           Expires April 21, 2012                 [Page 4]
Internet-Draft           NETCONF over WebSocket                 Oct 2011

   notification is possible.  This is beneficial for a network
   management system that provides failure detection function.

Iijima, et al.           Expires April 21, 2012                 [Page 5]
Internet-Draft           NETCONF over WebSocket                 Oct 2011

3.  Use Case

   Some vendors are providing network management systems that put XML
   messages directly onto HTTP.  In some cases, API is provided in a
   style of XML, and operators write XML messages by hands and send
   those messages through network management system.  It's not scalable,
   but one of the advantages of this style is that it does not require
   much programming.  However, as far as the parts of XML is
   proprietary, those network management systems can manage limited
   number of network devices.  NETCONF and its data models can be used
   for this purpose.

   And, WebSocket is defining JavaScript API[WebSocket API], which is
   supported by current Web browsers.  By using WebSocket API to
   exchange NETCONF messages, NETCONF client becomes browser-based.
   Browser-based network management systems don't require installation
   in computers.  Thus, they can be provided without much care about the
   platform on which network management systems run.  For this reason,
   they can be used even by tablet computers, which will be deployed
   widely in a cloud computing age.

   In addition, there are various APIs to control computer and storage
   resources, which are also intended to be used by Web browser.  DMTF
   (Distributed Management Task Force), for example, is standardizing
   REST-based API in CMWG (Cloud Management Working Group) for
   controlling computer and storage resources[DMTF].  REST-based API is
   easily manipulated by JavaScript language.  And, SNIA (Storage
   Networking Industry Association) defines CDMI (Cloud Data Management
   Interface), a cloud strage API[CDMI].  This is also manipulated by
   JavaScript language.  By using WebSocket API for NETCONF notification
   and combining these APIs, it's possible to develop management systems
   that can control IT resources according to situations in networks.

Iijima, et al.           Expires April 21, 2012                 [Page 6]
Internet-Draft           NETCONF over WebSocket                 Oct 2011

4.  Concerns about HTTP and WebSocket

   HTTP and WebSocket, on the other hand, have several concerns to pay
   attention to.  As Security Considerations section of
   [I-D.ietf-hybi-thewebsocketprotocol] mentions, HTTP and WebSocket
   have quite a few risks of being attacked for its wide usage.  But, as
   stated in the same section of [I-D.ietf-hybi-thewebsocketprotocol],
   WebSocket incorporates its own security mechanisms such as challenge-
   response exchange and payload masking.  In addition, TLS is used when
   strong care needs to be paid on information transported over
   WebSocket protocol.

   Section 2.4 of RFC 4743[RFC4743] also mentions some drawbacks
   inherent in HTTP.  But the section makes suggestion offsetting those
   drawbacks.  Those suggestions are effective when WebSocket is used
   for transporting NETCONF.  That is, intermediate proxies should not
   be used since it may close idle connections.  And, the field of
   'Cache-Control' and 'Pragma' in HTTP header sent before and during
   WebSocket handshake should be specified as 'no-cache,' as in the case
   of transporting NETCONF over SOAP/HTTPS.

Iijima, et al.           Expires April 21, 2012                 [Page 7]
Internet-Draft           NETCONF over WebSocket                 Oct 2011

5.  Messages of NETCONF over WebSocket

   This section specifies the messages exchanged between an NETCONF
   client and an NETCONF server when WebSocket protocol is used for
   transporting NETCONF.

5.1.  Message Sequence

   Overall message sequence is depicted in Figure 2.

Iijima, et al.           Expires April 21, 2012                 [Page 8]
Internet-Draft           NETCONF over WebSocket                 Oct 2011

   +---------------------------+  +-------------------------+
   | Network Management System |  |     Network device      |
   | +---------++-----------+  |  |+-----------++---------+ |
   | | NETCONF || WebSocket |  |  || WebSocket || NETCONF | |
   | | client  ||  (HTTP)   |  |  ||  (HTTP)   || server  | |
   | |         ||  client   |  |  ||  server   ||         | |
   | +---------++-----------+  |  |+-----------++---------+ |
   +------|-----------|--------+  +------|-----------|------+
          |Load *.html|                  |           |
          |---------->|     HTTP:GET     |           |
          |           |----------------->|           |
          |           |   HTTP:200 OK    |           |
          |           |<-----------------|           |
          |<----------|                  |           |
                              ....
          |API:new WebSocket()           |           |
          |---------->|   HTTP:Upgrade   |           |
          |           |----------------->|           |
          |           |   HTTP:Upgrade   | WebSocket |
          |           |<-----------------| opening   |
          |           |    TCP:ACK       | handshake |
          |           |----------------->|           |
          |API:onopen = function() { }   |           |
          |<----------|                  |           |
          |NETCONF:<hello>               |           |
          |---------->|                  |           |
          |           |----------------->|           |
          |           |                  |---------->|
          |           |                  |  <hello>  |
          |           |                  |<----------|
          |           |<-----------------|           |
          |<----------|                  |           |
          |NETCONF:<create-subscription> |           |
          |---------->|                  |           |
          |           |----------------->|           |
          |           |                  |---------->|
          |           |                  |   <ok>    |
          |           |                  |<----------|
          |           |<-----------------|           |
          |<----------|                  |           |
                              ....
          |           |        NETCONF:<notification>|
          |           |                  |<----------|
          |           |<-----------------|           |
          |<----------|                  |           |
          |           |                  |           |

Iijima, et al.           Expires April 21, 2012                 [Page 9]
Internet-Draft           NETCONF over WebSocket                 Oct 2011

                        Figure 2: Message Sequence

   When a browser loads an html file which imports the code of NETCONF
   client using WebSocket API, it initiates WebSocket opening handshake.
   After NETCONF client is notified of the success of WebSocket
   handshake, it starts sending NETCONF messages.  NETCONF <rpc>
   messages are exchanged, after an NETCONF session is established and
   an NETCONF session ID is allocated by the NETCONF server to the
   NETCONF client.  NETCONF <notification> messages are sent from
   NETCONF server, after an NETCONF session ID is allocated and
   subscription request is approved by the NETCONF server.

   When WebSocket server shuts down, NETCONF session as well as
   WebSocket connection is killed.  Since NETCONF notification
   subscription is associated with NETCONF session ID as written in
   section 3.5 of [RFC5277], status of subscription is lost when
   WebSocket server shuts down.  Thus, WebSocket opening handshake,
   NETCONF session establishment, and NETCONF notification subscription
   need to be made again after WebSocket server reboots.

   TCP port numbers of 80 and 443 can be used for transporting NETCONF
   messages over WebSocket and for transporting NETCONF messages over
   WebSocket over TLS, respectively.  In this case, indication of TCP
   port numbers in NETCONF client is unnecessary.  When any TCP port
   numbers other than official HTTP and HTTPS numbers are assigned for
   this purpose, indication of port numbers in NETCONF client as well as
   NETCONF server is necessary.  And, setting about firewall should be
   opened for these port numbers.

5.2.  WebSocket Message from NETCONF Client at WebSocket Handshake

   WebSocket opening handshake is necessary before an NETCONF client
   establishes an NETCONF session.  The WebSocket handshake is initiated
   by the NETCONF client.  Figure 3 is an example of WebSocket message
   sent from the NETCONF client at the time of WebSocket handshake.

      C: GET /netconf HTTP/1.1
      C: Host: netconfdevice
      C: Upgrade: websocket
      C: Connection: Upgrade
      C: Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
      C: Origin: http://example.com
      C: Sec-WebSocket-Protocol: netconf
      C: Sec-WebSocket-Version: 13

              Figure 3: WebSocket Message from NETCONF Client

Iijima, et al.           Expires April 21, 2012                [Page 10]
Internet-Draft           NETCONF over WebSocket                 Oct 2011

   As written in Figure 3, GET instead of POST is specified in the
   WebSocket header.  Fields of 'Upgrade' and 'Connection' are specified
   as 'websocket' and 'Upgrade' respectively, so that an HTTP server
   running in the NETCONF server understands that it needs to work as an
   WebSocket server.  Challenge-response mechanism encoded in base64 is
   included in the 'Sec-WebSocket-Key' field.  And, Origin field needs
   to be validated by the WebSocket server.  But, these are generated
   automatically by WebSocket client.  The field that the NETCONF client
   needs to specify is that of 'Sec-WebSocket-Protocol,' so-called
   subprotocol field.  The NETCONF client has to specify it, for
   example, as 'netconf,' so that the WebSocket server understands that
   it needs to hand over messages sent over this connection to the
   NETCONF server.

   Aforementioned establishment of the WebSocket connection and
   specification of subprotocol is made by using WebSocket API as
   depicted in Figure 4 in the NETCONF clients.

      var wsURL = "ws://" + host;
      ws = new WebSocket(wsURL, "netconf");

    Figure 4: WebSocket API in NETCONF Clients for Initiating Handshake

5.3.  WebSocket Message from NETCONF Server at WebSocket Handshake

   Figure 5 is an example of WebSocket message sent from an NETCONF
   server to an NETCONF client at the time of WebSocket handshake.

      S: HTTP/1.1 101 Switching Protocols
      S: Upgrade: websocket
      S: Connection: Upgrade
      S: Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo=
      S: Sec-WebSocket-Protocol: netconf

              Figure 5: WebSocket Message from NETCONF Server

   Unlike the WebSocket client, there's no standardized WebSocket API
   for WebSocket server.  Although the way of implementing WebSocket
   server is proprietary, there's some implementations as mentioned in
   section 2.  NETCONF server can be develped on top of those
   implementations by using their libraries.

   As written in Figure 5, when HTTP server inside network device can
   run as WebSocket server, the number of 101 has to be returned to

Iijima, et al.           Expires April 21, 2012                [Page 11]
Internet-Draft           NETCONF over WebSocket                 Oct 2011

   WebSocket client.  Fields of 'Upgrade' and 'Connection' are specified
   as 'websocket' and 'Upgrade' respectively, in order to let the
   NETCONF client know that an HTTP server in network device can run as
   WebSocket server.  In this case too, above fields need to be
   generated by WebSocket server.  The field that the NETCONF server
   needs to specify is that of 'Sec-WebSocket-Protocol.'  The NETCONF
   server has to specify its name of the subprotocol, for example, as
   'netconf,' in order to let the NETCONF client know that the WebSocket
   server in the network device accepts NETCONF messages.

5.4.  NETCONF Message over WebSocket Connection

   After an WebSocket connection is established, an NETCONF client and
   an NETCONF server start exchanging NETCONF messages.  Exchanges of
   <hello> messages between NETCONF client and NETCONF server start from
   this timing.  After an NETCONF session is established and a session
   ID is allocated to NETCONF client, <rpc> messages containing <edit-
   config> for NETCONF configurations and <rpc> messages like <create-
   subscription> for NETCONF notification should be sent from the
   NETCONF client to the NETCONF server.  And messages like
   <notification> should be sent from the NETCONF server to the NETCONF
   client asynchronously.  During this data transfer period, so called
   HTTP headers coupled with GET, 404 and so on are unnecessary.
   NETCONF configuration messages as well as NETCONF notification
   messages are encapsulated as a payload of WebSocket protocol
   according to the Data Framing specified in the section 5.2 of
   [I-D.ietf-hybi-thewebsocketprotocol].  And above encapusulated data
   are exchanged over TCP without the use of HTTP.

   Sending of NETCONF message from NETCONF client is made by using
   WebSocket API as depicted in Figure 6.

Iijima, et al.           Expires April 21, 2012                [Page 12]
Internet-Draft           NETCONF over WebSocket                 Oct 2011

          ws.onopen = function() {
            // WebSocket connection has established.
            // rpc message of <hello> can be sent here
            // by send() method.
            ws.send("message to send");
            ....
          };

          ws.onmessage = function (evt) {
            // NETCONF message has arrived.
            // NETCONF message can be parsed by DOM APIs.
            var received_msg = evt.data;

            var parser = new DOMParser();
            var dom    = parser.parseFromString(evt.data, "text/xml");
            if(dom.documentElement.nodeName == "hello"){
              // rpc reply message of <hello> has arrived.
              // Subsequent NETCONF message can be sent here
              // by send() method.
              ws.send("message to send");
              ...
            }
          };

      Figure 6: WebSocket API in NETCONF Client for Sending Messages

   As shown in Figure 6, NETCONF messages are sent from WebSocket API.
   The NETCONF message to send through WebSocket API can be a hand-
   written message typed in from browser-based NMS.  Or it might be
   created by JavaScript DOM API according to the data typed in from
   browser-based NMS.  Unlike the case of NETCONF over SOAP over HTTPS,
   which provides API to manipulate NETCONF <rpc>, parts of <rpc> as
   well as contents need to be manipulated by NETCONF client.

   NETCONF messages are also received by WebSocket API.  These messages
   are analyzed by JavaScript DOM API.

   In contrast, the way of sending NETCONF message from NETCONF server
   is proprietary.  Unlike the WebSocket client, there's no standardized
   WebSocket API for WebSocket server.  Although the way of implementing
   WebSocket server is proprietary, there's some implementations as
   mentioned in section 2.  NETCONF server can be developed on top of
   those implementations by using their libraries.  By using send method
   of those libraries, it's possible to send NETCONF notification
   message asynchronously from NETCONF server to NETCONF clients.

Iijima, et al.           Expires April 21, 2012                [Page 13]
Internet-Draft           NETCONF over WebSocket                 Oct 2011

6.  Security Considerations

   The security considerations of [RFC6241], [RFC5277], and
   [I-D.ietf-hybi-thewebsocketprotocol] are applicable to this document.
   Implementers or users should take these considerations into account.

   Transport-level security, such as authentication of users and
   encryption of data transfer, has to be ensured by TLS (Transport
   Layer Security).  That is, security has to be provided in the form of
   NETCONF over WebSocket over TLS (WSS).

Iijima, et al.           Expires April 21, 2012                [Page 14]
Internet-Draft           NETCONF over WebSocket                 Oct 2011

7.  IANA Considerations

   As written in section 11.5 of [I-D.ietf-hybi-thewebsocketprotocol],
   registration of NETCONF's Identifier, to be exchanged at WebSocket
   opening handshake, and Common Name with WebSocket Subprotocol Name
   Registry is necessary.

Iijima, et al.           Expires April 21, 2012                [Page 15]
Internet-Draft           NETCONF over WebSocket                 Oct 2011

8.  Acknowledgements

   This document was written using the xml2rfc tool described in RFC
   2629 [RFC2629].

Iijima, et al.           Expires April 21, 2012                [Page 16]
Internet-Draft           NETCONF over WebSocket                 Oct 2011

 9.   References

 9.1.   Normative References

    [I-D.ietf-hybi-thewebsocketprotocol]
               Fette, I.  and A. Melnikov, "The WebSocket protocol",
              draft-ietf-hybi-thewebsocketprotocol-17 (work in
              progress), September 2011.

    [RFC4743]   Goddard, T., "Using NETCONF over the Simple Object
              Access Protocol (SOAP)", RFC 4743, December 2006.

    [RFC5277]   Chisholm, S.  and H. Trevino, "NETCONF Event
              Notifications", RFC 5277, July 2008.

    [RFC6241]   Enns, R., Bjorklund, M., Schoenwaelder, J., and A.
              Bierman, "Network Configuration Protocol (NETCONF)",
              RFC 6241, June 2011.

    [WebSocket API]
               "The WebSocket API".

              <http://dev.w3.org/html5/websockets/>

 9.2.   Informative References

    [CDMI]      "SNIA's CDMI".

              <http://cdmi.sniacloud.com/>

   [Chrome]   "Chrome".

              <http://www.google.com/chrome/?hl=en>

   [DMTF]     "CLOUD | DMTF".

              <http://www.dmtf.org/standards/cloud>

   [FireFox]  "FireFox".

              <http://www.mozilla.org/>

   [I-D.moffitt-xmpp-over-websocket]
              Moffitt, J. and E. Cestari, "An XMPP Sub-protocol for
              WebSocket", draft-moffitt-xmpp-over-websocket-00 (work in
              progress), December 2010.

   [Jetty]    "Jetty WebServer".

Iijima, et al.           Expires April 21, 2012                [Page 17]
Internet-Draft           NETCONF over WebSocket                 Oct 2011

              <http://jetty.codehaus.org/jetty/>

   [Kaazing]  "Kaazing".

              <http://kaazing.com/>

   [RFC2629]  Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
              June 1999.

Iijima, et al.           Expires April 21, 2012                [Page 18]
Internet-Draft           NETCONF over WebSocket                 Oct 2011

Authors' Addresses

   Tomoyuki Iijima
   Hitachi, Ltd.
   292 Yoshida-cho, Totsuka-ku
   Yokohama, Kanagawa  244-0817
   Japan

   Phone: +81-45-860-2156
   Email: tomoyuki.iijima.fg@hitachi.com

   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.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

   Hidemitsu Higuchi
   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: hidemitsu.higuchi@alaxala.com

Iijima, et al.           Expires April 21, 2012                [Page 19]