[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04

NETCONF Working Group                                          T. Iijima
Internet-Draft                                             Hitachi, Ltd.
Intended status: Experimental                                  H. Kimura
Expires: April 20, 2013                                      Y. Atarashi
                                                              H. Higuchi
                                                  Alaxala Networks Corp.
                                                            Oct 17, 2012


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

Abstract

   This memo proposes a way of transporting NETCONF over WebSocket
   protocol.  Web-related technologies are advancing and number of Web-
   based systems are increasing.  Management systems that adopt Web-
   related technologies or that have browser-based management interface
   are getting common.  It is natural to expect that there is a standard
   network operation and management protocol to be used over HTTP.
   Currently, however, there are few efforts in this area.  Although
   NETCONF[RFC6241] once defined itself to be sent over SOAP/
   HTTPS[RFC4743], supposedly due to unfamiliarity to SOAP or lack of
   bi-directional capability, such efforts aren't successful
   enough[I-D.ietf-netconf-rfc4743-rfc4744-to-historic].  But now,
   WebSocket protocol, the update of HTTP equipped with bi-directional
   capability, is available[RFC6455].  This memo describes how NETCONF
   should be treated 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 20, 2013.

Copyright Notice




Iijima, et al.           Expires April 20, 2013                 [Page 1]


Internet-Draft           NETCONF over WebSocket                 Oct 2012


   Copyright (c) 2012 IETF Trust and the persons identified as the
   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 Using HTTP and WebSocket  . . . . . . . . . . .  7
   5.  Handling of NETCONF Username . . . . . . . . . . . . . . . . .  8
   6.  Transporting NETCONF Messages over WebSocket Protocol  . . . .  9
     6.1.  Message Sequence . . . . . . . . . . . . . . . . . . . . .  9
     6.2.  WebSocket Message at Handshake from NETCONF Client . . . . 11
     6.3.  WebSocket Message at Handshake from NETCONF Server . . . . 12
     6.4.  NETCONF Message over WebSocket at NETCONF Client . . . . . 12
     6.5.  NETCONF Message over WebSocket at NETCONF Server . . . . . 14
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
     10.2. Informative References . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20

















Iijima, et al.           Expires April 20, 2013                 [Page 2]


Internet-Draft           NETCONF over WebSocket                 Oct 2012


1.  Introduction

   Web-related technologies are advancing and number of Web-based
   systems are increasing.  Management systems that adopt Web-related
   technologies or have browser-based management interface are getting
   common.  It is natural to expect that there is a standard network
   operation and management protocol to be sent over HTTP.  Currently,
   however, there are few efforts in this area and, in most cases,
   management interface to be used over HTTP are proprietary.  Although
   NETCONF[RFC6241] once defined itself to be sent over SOAP/
   HTTPS[RFC4743], supposedly due to unfamiliarity to SOAP or lack of
   bi-directional capability, such efforts didn't succeed well
   enough[I-D.ietf-netconf-rfc4743-rfc4744-to-historic].  But now,
   WebSocket protocol, the update of HTTP equipped with bi-directional
   capability, is available[RFC6455].  This memo describes how NETCONF
   should be exchanged over WebSocket protocol.

   This memo does not intend to make WebSocket as a mandatory transport
   protocol for NETCONF.  NETCONF specifies that it is mandatory to be
   sent over SSH[RFC6241].  But [RFC6241] also specifies in its 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 [RFC6455], '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 April 20, 2013                 [Page 3]


Internet-Draft           NETCONF over WebSocket                 Oct 2012


2.  Problem Statement

   Web-related technologies, such as JavaScript and JSON(JavaScript
   Orient Notation), are widely used.  And number of Web-based systems,
   such as those provided for IaaS (Infrastructure as a Service), are
   increasing.  There are systems that are providing management
   interface in a form of REST API(Application Programming Interface).
   It is natural to expect that there is a standard network operation
   and management protocol to be sent over HTTP.  Currently, however,
   there are few efforts in this area.  And, in most of the cases,
   management interface are proprietary.

   NETCONF[RFC6241] once defined itself to be sent over SOAP/
   HTTPS[RFC4743], as drawn in Figure 1.  But, supposedly due to
   unfamiliarity to SOAP or lack of bi-directional capability, such
   efforts haven't been successful
   enough[I-D.ietf-netconf-rfc4743-rfc4744-to-historic].


            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

   As of now, however, WebSocket protocol is available[RFC6455].  It is
   based on HTTP, which is familiar to all.  And, it has a bi-
   directional capability.  Thus, by using WebSocket protocol, it's
   possible to realize NETCONF that is used over HTTP with ease and that
   supports notification mechanism specified in [RFC5277].



Iijima, et al.           Expires April 20, 2013                 [Page 4]


Internet-Draft           NETCONF over WebSocket                 Oct 2012


   Some WebSocket implementations already exist today.  As examples of
   WebSocket server implementation, Jetty[Jetty], Kaazing[Kaazing], and
   the like are available.  And, as examples of WebSocket client
   implementation, Jetty[Jetty] is available.  Moreover, as examples of
   Web-browsers that can work as WebSocket client, Chrome[Chrome], and
   FireFox[FireFox] and the like are available.

   WebSocket server and client implementations mentioned above are
   providing libraries.  And WebSocket protocol itself also defines
   API[WebSocket API] to be used on Web-browsers.  Thus, by using those
   libraries and APIs, developers can develop NETCONF server, install-
   based NETCONF client, and browser-based NETCONF client with ease that
   use WebSocket for transporting NETCONF.






































Iijima, et al.           Expires April 20, 2013                 [Page 5]


Internet-Draft           NETCONF over WebSocket                 Oct 2012


3.  Use Case

   XML, which NETCONF uses for message encoding, has high compatibility
   with HTTP in that XML are easily manipulated on Web-browsers by
   JavaScript DOM (Document Object Model) API.  Hence, there are cases
   in which XML is used over HTTP to manage network devices.  But as far
   as those XML are proprietary, the way of managing network devices and
   items to manage are different from network device to network device.
   If NETCONF, instead of proprietary XML, and its data models are used
   for above cases, it will provide a way of managing various network
   devices in a same manner.

   Browser-based network management systems don't require installation
   on computers.  For this reason, some operators prefer browser-based
   network management systems.  This trend might accelerate in the age
   of tablet computers.  In this respect, it is rational for NETCONF to
   have an option to be used through browser-based network management
   system.  Operators will be able to manage network devices from any
   computers without installation.
































Iijima, et al.           Expires April 20, 2013                 [Page 6]


Internet-Draft           NETCONF over WebSocket                 Oct 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 transporting NETCONF
   over SOAP/HTTPS.  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 or
   during WebSocket opening handshake, SHOULD be specified as 'no-
   cache.'

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


































Iijima, et al.           Expires April 20, 2013                 [Page 7]


Internet-Draft           NETCONF over WebSocket                 Oct 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 matched with TLS authentication data.  At present,
   [I-D.badra-netconf-rfc5539bis] is proposing ways of extracting
   NETCONF username from TLS authentication data.  Being compliant with
   these approaches is the most efficient.  At least, it is confirmed
   that NETCONF server using WebSocket/TLS for underlying protocol can
   see TLS Certificate at the time of TLS handshake and can extract
   NETCONF username from the Certificate.

































Iijima, et al.           Expires April 20, 2013                 [Page 8]


Internet-Draft           NETCONF over WebSocket                 Oct 2012


6.  Transporting NETCONF Messages over WebSocket Protocol

   This section specifies how NETCONF messages are exchanged between
   NETCONF client and server over WebSocket protocol.

6.1.  Message Sequence

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


   +---------------------------+  +---------------------------+
   | Network Management System |  |     Network Device        |
   |                           |  |   (e.g. 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 April 20, 2013                 [Page 9]


Internet-Draft           NETCONF over WebSocket                 Oct 2012


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


                        Figure 2: Message Sequence

   First of all, a browser starts loading of an html file, which imports
   the code of NETCONF client, over TLS.  This invokes TLS handshake.
   At the time of TLS handshake, NETCONF server can extract NETCONF
   username from Certificate according to the algorithm 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 NETCONF client and it initiates
   WebSocket opening handshake.  When NETCONF server receives a
   WebSocket connection request, it notifies the 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
   client.  Then, NETCONF <rpc> messages are exchanged.  After NETCONF



Iijima, et al.           Expires April 20, 2013                [Page 10]


Internet-Draft           NETCONF over WebSocket                 Oct 2012


   <rpc> message of <create-subscription> request is approved by the
   NETCONF server, NETCONF <notification> messages are sent from NETCONF
   server asynchronously.

   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.  When
   port number other than 443 needs to be used, the number SHOULD be
   specified at both NETCONF client and server respectively.

6.2.  WebSocket Message at Handshake from NETCONF Client

   WebSocket opening handshake is necessary for the establishment of an
   WebSocket connection, which is used for NETCONF message exchange.
   The WebSocket handshake is initiated by a 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
   specification of subprotocol is made by using WebSocket API in the



Iijima, et al.           Expires April 20, 2013                [Page 11]


Internet-Draft           NETCONF over WebSocket                 Oct 2012


   html file of the NETCONF client as depicted in Figure 4.


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


    Figure 4: WebSocket API in NETCONF Clients for Initiating Handshake

6.3.  WebSocket Message at Handshake from NETCONF Server

   Figure 5 is an example of WebSocket message sent from the NETCONF
   server to the 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

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

   Unlike the WebSocket client, there's no standardized WebSocket API
   for WebSocket server.  But, there are some WebSocket server
   implementations as mentioned in section 2.  Thus, it's possible to
   develop a part of WebSocket opening handshake at NETCONF server with
   ease by using libraries provided by those implementations.

6.4.  NETCONF Message over WebSocket at NETCONF Client

   NETCONF message exchange between NETCONF client and server starts
   after an WebSocket connection is established. <hello> messages are
   exchanged, first, for the establishment of a NETCONF session and
   allocation of 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.  Moreover, messages like <notification> are
   sent asynchronously from NETCONF server to NETCONF client for NETCONF



Iijima, et al.           Expires April 20, 2013                [Page 12]


Internet-Draft           NETCONF over WebSocket                 Oct 2012


   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 been established.
            // Thus, NETCONF <hello> can be sent here
            // by send() method.
            wss.send("message to send");
            ....
          };

          wss.onmessage = function (evt) {
            // NETCONF message has arrived.
            // Thus, NETCONF message can be parsed here by DOM APIs.

            var parser = new DOMParser();
            var dom    = parser.parseFromString(evt.data, "text/xml");
            ....
            if(dom.documentElement.nodeName == "hello"){
              // The NETCONF message turned out to be
              // NETCONF <hello>.
              // 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 are sent from NETCONF client
   by using WebSocket API of "wss.send()."  And, NETCONF messages are
   received at NETCONF client 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 XML messages created by JavaScript DOM API according to the
   data set on the network management system.  It must be noted that in
   the case of transporting NETCONF over WebSocket, <rpc> parts need to



Iijima, et al.           Expires April 20, 2013                [Page 13]


Internet-Draft           NETCONF over WebSocket                 Oct 2012


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

6.5.  NETCONF Message over WebSocket at NETCONF Server

   Unlike the WebSocket client, the way of sending and receiving NETCONF
   message at NETCONF server is proprietary since there's no
   standardized API for WebSocket server.  But, there are some WebSocket
   server implementations as mentioned in section 2.  Thus, it's
   possible to develop NETCONF server with ease by using libraries
   provided by those implementations.








































Iijima, et al.           Expires April 20, 2013                [Page 14]


Internet-Draft           NETCONF over WebSocket                 Oct 2012


7.  Security Considerations

   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, NETCONF has to be sent in the
   form of NETCONF over WebSocket over TLS (WSS).

   In addition, 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.








































Iijima, et al.           Expires April 20, 2013                [Page 15]


Internet-Draft           NETCONF over WebSocket                 Oct 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 April 20, 2013                [Page 16]


Internet-Draft           NETCONF over WebSocket                 Oct 2012


9.  Acknowledgements

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















































Iijima, et al.           Expires April 20, 2013                [Page 17]


Internet-Draft           NETCONF over WebSocket                 Oct 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.

    [I-D.ietf-netconf-rfc4743-rfc4744-to-historic]
               Wijnen, B., "RFC4743 and RFC4744 to Historic status",
              draft-ietf-netconf-rfc4743-rfc4744-to-historic-00 (work in
              progress), September 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

    [Chrome]    "Chrome".

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

   [FireFox]  "FireFox".

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

   [Jetty]    "Jetty WebServer".

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

   [Kaazing]  "Kaazing".




Iijima, et al.           Expires April 20, 2013                [Page 18]


Internet-Draft           NETCONF over WebSocket                 Oct 2012


              <http://kaazing.com/>

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















































Iijima, et al.           Expires April 20, 2013                [Page 19]


Internet-Draft           NETCONF over WebSocket                 Oct 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 April 20, 2013                [Page 20]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/