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

NETCONF Working Group                                          T. Iijima
Internet-Draft                                             Hitachi, Ltd.
Intended status: Experimental                                  H. Kimura
Expires: January 14, 2013                                    Y. Atarashi
                                                              H. Higuchi
                                                  Alaxala Networks Corp.
                                                            Jul 13, 2012

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

Abstract

   This memo proposes a way of transporting NETCONF over WebSocket
   protocol.  Web-based systems are increasing with the advancement of
   Web technologies and emergence of cloud computing.  Management
   systems that support browser-based interface are also getting common.
   It's natural to expect network devices to have browser-based
   managemaent interface.  Currently, however, few network management
   protocols support being transported over HTTP.  NETCONF[RFC6241] was
   defined to be sent over SOAP/HTTPS[RFC4743].  But, it falls short of
   fulfilling NETCONF specification in that it can't provide NETCONF
   notification[RFC5277] because of HTTP's lack of bi-directional
   capabilty.  At present, WebSocket protocol, the update of HTTP with
   bi-directional capability, is available[RFC6455].  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 January 14, 2013.

Copyright Notice

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

Iijima, et al.          Expires January 14, 2013                [Page 1]
Internet-Draft           NETCONF over WebSocket                 Jul 2012

   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 . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Concerns about Using HTTP and WebSocket  . . . . . . . . . . .  6
   5.  Handling of NETCONF username . . . . . . . . . . . . . . . . .  7
   6.  Transporting NETCONF Messages over WebSocket Protocol  . . . .  8
     6.1.  Message Sequence . . . . . . . . . . . . . . . . . . . . .  8
     6.2.  WebSocket Message from NETCONF Client at WebSocket
           Handshake  . . . . . . . . . . . . . . . . . . . . . . . . 10
     6.3.  WebSocket Message from NETCONF Server at WebSocket
           Handshake  . . . . . . . . . . . . . . . . . . . . . . . . 11
     6.4.  NETCONF Message at NETCONF Client over WebSocket
           Connection . . . . . . . . . . . . . . . . . . . . . . . . 11
     6.5.  NETCONF Message at NETCONF Server over WebSocket
           Connection . . . . . . . . . . . . . . . . . . . . . . . . 13
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 17
     10.2. Informative References . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19

Iijima, et al.          Expires January 14, 2013                [Page 2]
Internet-Draft           NETCONF over WebSocket                 Jul 2012

1.  Introduction

   Web-based systems are increasing due to the advancement of Web
   technologies and emergence of cloud computing.  Management systems
   that support browser-based interface are also getting common.  It's
   natural to expect network devices to have browser-based management
   interface.  Currently, however, few network management protocols
   support being transported over HTTP.  NETCONF[RFC6241] was defined to
   be sent over SOAP/HTTPS[RFC4743].  But, it falls short of fulfilling
   NETCONF specification in that it can't provide NETCONF notification
   [RFC5277] because of HTTP's lack of bi-directional capability.  At
   present, WebSocket protocol, the update of HTTP with bi-directional
   capability, is available[RFC6455].  This memo describes the way
   NETCONF is sent over WebSocket protocol.

   This memo does not intend to make WebSocket protocol as a mandatory
   transport mapping for NETCONF.  NETCONF specifies that it is
   mandatory to be sent over SSH [RFC6241].  But [RFC6241] also
   specifies in section 2 that "the NETCONF protocol can be layered on
   any transport protocol that provides the required set of
   functionality."  According to the specification, those required set
   of functionality are "Connection-Oriented Operation" and
   "Authentication, Integrity, and Confidentiality."  WebSocket protocol
   meets those requirements.  It is 'connection-oriented.'  And, as
   written in the section 10.5 of [RFC6455], 'authentication' is ensured
   by mechanisms available to a generic HTTP server, such as cookies,
   HTTP Authentication, or TLS.  Moreover, as written in the section
   10.6 of [RFC6241], 'integrity and confidentiality' are ensured by
   running WebSocket protocol over TLS.  For these reasons, WebSocket
   protocol coupled with TLS meets the requirements of transport
   protocol for NETCONF.

Iijima, et al.          Expires January 14, 2013                [Page 3]
Internet-Draft           NETCONF over WebSocket                 Jul 2012

2.  Problem Statement

   Figure 1 is an architecture of NETCONF extracted from [RFC6241].  As
   of now, there's few protocols that is used to manage network devices
   through Web-based management system according to the NETCONF
   specification.  Although SOAP/HTTP/TLS is defined to be one of the
   transport protocols for NETCONF, it falls short of realizing
   notification mechanism since HTTP lacks bi-directional capability.

             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, however, WebSocket protocol is available.  It is based on
   HTTP and has a bi-directional capability.  Some implementations are
   available already.  Jetty[Jetty], Kaazing[Kaazing] and so on are
   available as WebSocket servers.  And, Web-browsers like
   Chrome[Chrome] and FireFox[FireFox] work as WebSocket clients.
   Moreover, there are WebSocket client libraries, which help develop
   install-based applications on top of WebSocket.

   By using WebSocket as an underlying protocol for NETCONF, it's
   possible to realize Web-based management systems that support not
   only NETCONF configuration but also NETCONF notification.

Iijima, et al.          Expires January 14, 2013                [Page 4]
Internet-Draft           NETCONF over WebSocket                 Jul 2012

3.  Use Case

   There are cases in which browser-based management systems use XML
   over HTTP to manage network devices.  XML has high compatibility with
   Web-based management systems in that XML messages are manipulated
   easily on Web browsers by using JavaScript DOM API.  If NETCONF,
   instead of proprietary XML, and its data models are used for above
   cases, it's possible to manage various network devices in the same
   manner through browser-based management systems.  But, as described
   in the previous section, NETCONF is rarely used in browser-based
   management systems today.

   Since WebSocket provides standardized JavaScript-based API[WebSocket
   API] for Web browsers, development of browser-based NETCONF client
   that can exchange messages over WebSocket is easily possible.  An
   html file written with WebSocket API to send and receive NETCONF
   messages works as a browser-based NETCONF client.

   Browser-based network management systems don't require installation
   on computers.  There is a case when people want to manage network
   devices from any computers.  In such a case, browser-based management
   systems are effective since it doesn't require installlation process.
   People can manage network devices even from tablet computers.

   Furthermore, there are other activities to use HTTP for managing
   devices other than network.  For example, DMTF (Distributed
   Management Task Force), has standarded REST-based CIMI (Cloud
   Infrastructure Management Interface)[DMTF] to control computers.
   REST-based API can be manipulated by JavaScript language at Web
   browsers.  And, SNIA (Storage Networking Industry Association) has
   standardized CDMI (Cloud Data Management Interface)[CDMI] to control
   storage devices.  This can also be manipulated by JavaScript language
   at Web browsers.  Having an option to control network devices through
   Web browsers will help operators to manage various devices from the
   same environment.

Iijima, et al.          Expires January 14, 2013                [Page 5]
Internet-Draft           NETCONF over WebSocket                 Jul 2012

4.  Concerns about Using HTTP and WebSocket

   There are some drawbacks inherent in HTTP as mentioned in the section
   2.4 of [RFC4743], which describes the way of using HTTP for
   transporting NETCONF/SOAP.  But, for these drawbacks, the same
   section makes suggestions.  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 fields of 'Cache-Control' and 'Pragma' in HTTP header, which is
   sent before WebSocket handshake, should be specified as 'no-cache.'

   And, WebSocket itself has several security concerns.  But, it
   incorporates its own security mechanisms such as origin header and
   masking, as stated in the Security Considerations section of
   [RFC6455].  In any case, TLS is necessary for ensuring authentication
   and confidentiality, when WebSocket is used for transporting NETCONF.

Iijima, et al.          Expires January 14, 2013                [Page 6]
Internet-Draft           NETCONF over WebSocket                 Jul 2012

5.  Handling of NETCONF username

   NETCONF[RFC6241] mandates underlying transport protocol to carry
   NETCONF username and to provide it to NETCONF server.  In the case of
   transporting NETCONF over WebSocket, this memo proposes that NETCONF
   username should be carried and provided in compliance with NETCONF
   over TLS[I-D.badra-netconf-rfc5539bis].  In the case of transporting
   NETCONF over WebSocket, TLS is necessary for the user authentication.
   In order to ensure that NETCONF access control is done consistently
   with TLS authentication, NETCONF username should be extracted from
   TLS authentication data.  At present, [I-D.badra-netconf-rfc5539bis]
   is proposing the way of extracting NETCONF username from TLS
   authentication data, and basing on this algorithm is the efficient
   approach.  NETCONF server which uses TLS can get TLS Certificate from
   SSL Socket before WebSocket opening handshake starts, and can extract
   NETCONF username from the Certificate.

Iijima, et al.          Expires January 14, 2013                [Page 7]
Internet-Draft           NETCONF over WebSocket                 Jul 2012

6.  Transporting NETCONF Messages over WebSocket Protocol

   This section specifies the way of transporting NETCONF messages
   between a NETCONF client and a NETCONF server when WebSocket protocol
   is used for underlying protocol for NETCONF.

6.1.  Message Sequence

   Overall message sequence is depicted in Figure 2.  This sequence is
   depicting the case in which NETCONF client runs on a Web-browser.
   But it must be noted that there is also a case in which NETCONF
   client runs as an install-based application if NETCONF client is
   developed with WebSocket client library.

     +---------------------------+  +-------------------------+
     | Network Management System |  |     Network Device      |
     |                           |  |      (192.168.1.1)      |
     | +---------++-----------+  |  |+-----------++---------+ |
     | | NETCONF || WebSocket |  |  || WebSocket || NETCONF | |
     | | Client  ||  (HTTP)   |  |  ||  (HTTP)   || Server  | |
     | |         ||  Client   |  |  ||  Server   ||         | |
     | +---------++-----------+  |  |+-----------++---------+ |
     +------|-----------|--------+  +------|-----------|------+
            |           |                  |           |
            |Load *.html|                  |           |
            |---------->|    Hello(TLS)    |           |
            |     /     |----------------->|           |
            |    |      |Server Certificate|           |
            |    TLS    |<-----------------|           |
            | handshake |Client Certificate|           |
            |    |      |----------------->|NETCONF username
            |    |      |  Finished(TLS)   |---------->|
            |     \     |<-----------------|           |
            |           |                  |           |
            |           |     GET(HTTP)    |           |
            |           |----------------->|           |
            |           |   200 OK(HTTP)   |           |
            |           |<-----------------|           |
            |<----------|                  |           |
                                ....
            |Call WebSocket() API          |           |
            |---------->|                  |           |
            |           |Connection: Upgrade           |
            |     /     |----------------->|           |
            | WebSocket |Connection: Upgrade           |
            | opening   |<-----------------|           |
            | handshake |     ACK(TCP)     |           |

Iijima, et al.          Expires January 14, 2013                [Page 8]
Internet-Draft           NETCONF over WebSocket                 Jul 2012

            |     \     |----------------->|           |
            |Invoke onopen = function() { }|           |
            |<----------|                  |           |
            |           |                  |           |
            |<hello>(NETCONF)              |           |
            |---------->|                  |           |
            |           |----------------->|           |
            |           |                  |---------->|
            |           |                  |  <hello>  |
            |           |                  |<----------|
            |           |<-----------------|           |
            |<----------|                  |           |
            |<create-subscription>(NETCONF)|           |
            |---------->|                  |           |
            |           |----------------->|           |
            |           |                  |---------->|
            |           |                  |   <ok>    |
            |           |                  |<----------|
            |           |<-----------------|           |
            |<----------|                  |           |
                                ....
            |           |       <notification>(NETCONF)|
            |           |                  |<----------|
            |           |<-----------------|           |
            |<----------|                  |           |
            |           |                  |           |

                        Figure 2: Message Sequence

   First of all, a browser initiates loading of an html file, which
   imports the code of NETCONF client.  This initiates the TLS handshake
   before the loading of the html file.  At the time of TLS handshake,
   NETCONF server can extract NETCONF username from Certificate or PSK
   according to the algorighm described in
   [I-D.badra-netconf-rfc5539bis].  After TLS handshake is complete, the
   html file is loaded onto the browser.

   The loaded html file works as an NETCONF client and it initiates
   WebSocket opening handshake.  When NETCONF server receives a
   WebSocket connection request, it notifies NETCONF client of whether
   WebSocket handshake has succeeded.  After WebSocket connection is
   established, NETCONF client starts sending NETCONF messages over the
   connection.

   NETCONF <hello> messages are exchanged between NETCONF client and
   server, at first, so that a NETCONF session is established and a
   NETCONF session ID is allocated by NETCONF server to the NETCONF

Iijima, et al.          Expires January 14, 2013                [Page 9]
Internet-Draft           NETCONF over WebSocket                 Jul 2012

   client.  Then, NETCONF <rpc> messages are exchanged.  After NETCONF
   <rpc> message of <create-subscription> request is approved by the
   NETCONF server, NETCONF <notification> messages are sent from 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 NETCONF notification mechanism[RFC5277], subscription
   status is lost when WebSocket server shuts down.  Thus, it is
   necessary to redo WebSocket opening handshake, NETCONF session
   establishment, and NETCONF notification subscription after WebSocket
   server reboots.

   Without any indications, TCP port numbers of 443 is automatically
   used for transporting NETCONF messages over WebSocket over TLS.  If
   necessary, any TCP port numbers other than above can be used by
   specifying at both NETCONF client and server.

6.2.  WebSocket Message from NETCONF Client at WebSocket Handshake

   WebSocket opening handshake is necessary for the establishment of an
   WebSocket connection, to be used for NETCONF message exchange.  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: 192.168.1.1
      C: Upgrade: websocket
      C: Connection: Upgrade
      C: Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ==
      C: Origin: http://192.168.1.1
      C: Sec-WebSocket-Protocol: netconf
      C: Sec-WebSocket-Version: 13

              Figure 3: WebSocket Message from NETCONF Client

   Most of the fileds in Figure 3 are generated automatically by
   WebSocket client.  The only field that the NETCONF client needs to
   specify is 'Sec-WebSocket-Protocol' field, so-called subprotocol
   field.  The NETCONF client has to specify the field as 'netconf,' for
   example, so that the NETCONF server understands that messages sent
   over this connection is directed towards NETCONF server.

   Aforementioned establishment of the WebSocket connection and

Iijima, et al.          Expires January 14, 2013               [Page 10]
Internet-Draft           NETCONF over WebSocket                 Jul 2012

   specification of subprotocol is made by using WebSocket API in the
   html file of the NETCONF client as depicted in Figure 4.

      var wssURL = "wss://" + host;
      wss = new WebSocket(wssURL, "netconf");

    Figure 4: WebSocket API in NETCONF Clients for Initiating Handshake

6.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 are some implementations as mentioned in
   section 2.  Thus, it's possible to develop NETCONF server by using
   the implementations' libraries.

   Most of the fields in Figure 5 are generated automatically by
   WebSocket server.  The only field that the NETCONF server needs to
   specify is 'Sec-WebSocket-Protocol' field.  The NETCONF server has to
   specify ithe field as 'netconf,' for example, in order to let the
   NETCONF client know that the WebSocket server in the network device
   accepts NETCONF messages.

6.4.  NETCONF Message at NETCONF Client over WebSocket Connection

   NETCONF message exchange between NETCONF client and NETCONF server
   starts after an WebSocket connection is established. <hello> messages
   are exchanged, first, to establish a NETCONF session and to allocate
   NETCONF session ID.  Then, <rpc> messages like <edit-config> are sent
   from NETCONF client to NETCONF server for NETCONF configurations.
   And <rpc> messages like <create-subscription> are sent from NETCONF
   client to NETCONF server for subscription of NETCONF notification.
   In addition, messages like <notification> are sent asynchronously

Iijima, et al.          Expires January 14, 2013               [Page 11]
Internet-Draft           NETCONF over WebSocket                 Jul 2012

   from NETCONF server to NETCONF client for NETCONF notification.
   During this data transfer period, both NETCONF configuration messages
   and NETCONF notification messages are encapsulated as a payload of
   WebSocket protocol according to the Data Framing specified in the
   section 5.2 of WebSocket protocol[RFC6455].  This encapsulation is
   made by WebSocket layer.

   Sending and receiving of NETCONF messages at NETCONF client is made
   by using WebSocket API.  The example is illustrated in Figure 6.

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

          wss.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.
              wss.send("message to send");
              ...
            }
          };

      Figure 6: WebSocket API in NETCONF Client for Sending Messages

   As shown in Figure 6, NETCONF messages sent from NETCONF client is
   sent by using WebSocket API of "wss.send()."  And, NETCONF messages
   received at NETCONF client is received by using WebSocket API of
   "wss.onmessage()."

   The contents of NETCONF messages exchanged through above API might be
   either a hand-written XML messages typed into network management
   system or messages created by JavaScript DOM API according to the
   data typed into network management system.  It must be noted that in
   the case of transporting NETCONF over WebSocket, <rpc> parts need to

Iijima, et al.          Expires January 14, 2013               [Page 12]
Internet-Draft           NETCONF over WebSocket                 Jul 2012

   be created by NETCONF client, unlike the case of transporting NETCONF
   over SOAP/HTTPS, in which <rpc> parts are produced in SOAP layer.

6.5.  NETCONF Message at NETCONF Server over WebSocket Connection

   The way of sending and receiving NETCONF message at NETCONF server is
   proprietary.  Unlike the WebSocket client, there's no standardized
   API for WebSocket server.  But, there are some WebSocket server
   implementations as mentioned in section 2.  By using libraries of
   those implementations, developers can develop NETCONF server on top
   of those implementations.

Iijima, et al.          Expires January 14, 2013               [Page 13]
Internet-Draft           NETCONF over WebSocket                 Jul 2012

7.  Security Considerations

   The security considerations of NETCONF protocol[RFC6241], NETCONF
   Notification mechanism[RFC5277], and WebSocket protocol[RFC6455] are
   applicable to this document.  Implementers or users should take these
   considerations into account.

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

Iijima, et al.          Expires January 14, 2013               [Page 14]
Internet-Draft           NETCONF over WebSocket                 Jul 2012

8.  IANA Considerations

   As written in section 11.5 of WebSokcet protocol[RFC6455], NETCONF's
   Subprotocol Common Name, to be exchanged in 'Sec-WebSocket-Protocol'
   field at WebSocket opening handshake, coupled with Identifier and
   Definition need to be registered with the WebSocket Subprotocol Name
   Registry.

Iijima, et al.          Expires January 14, 2013               [Page 15]
Internet-Draft           NETCONF over WebSocket                 Jul 2012

9.  Acknowledgements

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

Iijima, et al.          Expires January 14, 2013               [Page 16]
Internet-Draft           NETCONF over WebSocket                 Jul 2012

 10.   References

 10.1.   Normative References

    [I-D.badra-netconf-rfc5539bis]
               Badra, M., "NETCONF Over Transport Layer Security (TLS)",
              draft-badra-netconf-rfc5539bis-02 (work in progress),
              April 2012.

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

    [RFC6455]   Fette, I.  and A. Melnikov, "The WebSocket Protocol",
              RFC 6455, December 2011.

    [WebSocket API]
               "The WebSocket API".

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

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

   [Jetty]    "Jetty WebServer".

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

Iijima, et al.          Expires January 14, 2013               [Page 17]
Internet-Draft           NETCONF over WebSocket                 Jul 2012

   [Kaazing]  "Kaazing".

              <http://kaazing.com/>

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

Iijima, et al.          Expires January 14, 2013               [Page 18]
Internet-Draft           NETCONF over WebSocket                 Jul 2012

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

   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 January 14, 2013               [Page 19]