idnits 2.17.1 draft-iijima-netconf-websocket-ps-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC6455], [RFC4743], [RFC6241], [I-D.ietf-netconf-RFC4743-rfc4744-to-historic]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 202: '...at is, intermediate proxies SHOULD not...' RFC 2119 keyword, line 205: '...ening handshake, SHOULD be specified a...' RFC 2119 keyword, line 219: '... username SHOULD be carried and prov...' RFC 2119 keyword, line 225: '... username SHOULD be matched with TLS...' RFC 2119 keyword, line 342: '...needs to be used, the number SHOULD be...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: 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.' -- The document date (Oct 17, 2012) is 4201 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group T. Iijima 3 Internet-Draft Hitachi, Ltd. 4 Intended status: Experimental H. Kimura 5 Expires: April 20, 2013 Y. Atarashi 6 H. Higuchi 7 Alaxala Networks Corp. 8 Oct 17, 2012 10 NETCONF over WebSocket 11 draft-iijima-netconf-websocket-ps-04 13 Abstract 15 This memo proposes a way of transporting NETCONF over WebSocket 16 protocol. Web-related technologies are advancing and number of Web- 17 based systems are increasing. Management systems that adopt Web- 18 related technologies or that have browser-based management interface 19 are getting common. It is natural to expect that there is a standard 20 network operation and management protocol to be used over HTTP. 21 Currently, however, there are few efforts in this area. Although 22 NETCONF[RFC6241] once defined itself to be sent over SOAP/ 23 HTTPS[RFC4743], supposedly due to unfamiliarity to SOAP or lack of 24 bi-directional capability, such efforts aren't successful 25 enough[I-D.ietf-netconf-rfc4743-rfc4744-to-historic]. But now, 26 WebSocket protocol, the update of HTTP equipped with bi-directional 27 capability, is available[RFC6455]. This memo describes how NETCONF 28 should be treated over WebSocket protocol. 30 Status of this Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on April 20, 2013. 47 Copyright Notice 48 Copyright (c) 2012 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 4 65 3. Use Case . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 4. Concerns about Using HTTP and WebSocket . . . . . . . . . . . 7 67 5. Handling of NETCONF Username . . . . . . . . . . . . . . . . . 8 68 6. Transporting NETCONF Messages over WebSocket Protocol . . . . 9 69 6.1. Message Sequence . . . . . . . . . . . . . . . . . . . . . 9 70 6.2. WebSocket Message at Handshake from NETCONF Client . . . . 11 71 6.3. WebSocket Message at Handshake from NETCONF Server . . . . 12 72 6.4. NETCONF Message over WebSocket at NETCONF Client . . . . . 12 73 6.5. NETCONF Message over WebSocket at NETCONF Server . . . . . 14 74 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 75 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 76 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 77 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 78 10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 79 10.2. Informative References . . . . . . . . . . . . . . . . . . 18 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 82 1. Introduction 84 Web-related technologies are advancing and number of Web-based 85 systems are increasing. Management systems that adopt Web-related 86 technologies or have browser-based management interface are getting 87 common. It is natural to expect that there is a standard network 88 operation and management protocol to be sent over HTTP. Currently, 89 however, there are few efforts in this area and, in most cases, 90 management interface to be used over HTTP are proprietary. Although 91 NETCONF[RFC6241] once defined itself to be sent over SOAP/ 92 HTTPS[RFC4743], supposedly due to unfamiliarity to SOAP or lack of 93 bi-directional capability, such efforts didn't succeed well 94 enough[I-D.ietf-netconf-rfc4743-rfc4744-to-historic]. But now, 95 WebSocket protocol, the update of HTTP equipped with bi-directional 96 capability, is available[RFC6455]. This memo describes how NETCONF 97 should be exchanged over WebSocket protocol. 99 This memo does not intend to make WebSocket as a mandatory transport 100 protocol for NETCONF. NETCONF specifies that it is mandatory to be 101 sent over SSH[RFC6241]. But [RFC6241] also specifies in its section 102 2 that "the NETCONF protocol can be layered on any transport protocol 103 that provides the required set of functionality." According to the 104 specification, those required set of functionality are "Connection- 105 Oriented Operation" and "Authentication, Integrity, and 106 Confidentiality." WebSocket protocol meets those requirements. It 107 is 'connection-oriented.' And, as written in the section 10.5 of 108 [RFC6455], 'authentication' is ensured by mechanisms available to a 109 generic HTTP server, such as cookies, HTTP Authentication, or TLS. 110 Moreover, as written in the section 10.6 of [RFC6455], 'integrity and 111 confidentiality' are ensured by running WebSocket protocol over TLS. 112 For these reasons, WebSocket protocol coupled with TLS meets the 113 requirements of transport protocol for NETCONF. 115 2. Problem Statement 117 Web-related technologies, such as JavaScript and JSON(JavaScript 118 Orient Notation), are widely used. And number of Web-based systems, 119 such as those provided for IaaS (Infrastructure as a Service), are 120 increasing. There are systems that are providing management 121 interface in a form of REST API(Application Programming Interface). 122 It is natural to expect that there is a standard network operation 123 and management protocol to be sent over HTTP. Currently, however, 124 there are few efforts in this area. And, in most of the cases, 125 management interface are proprietary. 127 NETCONF[RFC6241] once defined itself to be sent over SOAP/ 128 HTTPS[RFC4743], as drawn in Figure 1. But, supposedly due to 129 unfamiliarity to SOAP or lack of bi-directional capability, such 130 efforts haven't been successful 131 enough[I-D.ietf-netconf-rfc4743-rfc4744-to-historic]. 133 Layer Example 134 +-------------+ +-----------------+ +----------------+ 135 (4) | Content | | Configuration | | Notification | 136 | | | data | | data | 137 +-------------+ +-----------------+ +----------------+ 138 | | | 139 +-------------+ +-----------------+ | 140 (3) | Operations | | | | 141 | | | | | 142 +-------------+ +-----------------+ | 143 | | | 144 +-------------+ +-----------------+ +----------------+ 145 (2) | Messages | | , | | | 146 | | | | | | 147 +-------------+ +-----------------+ +----------------+ 148 | | | 149 +-------------+ +-----------------------------------------+ 150 (1) | Secure | | SSH, TLS, BEEP/TLS, SOAP/HTTP/TLS, ... | 151 | Transport | | | 152 +-------------+ +-----------------------------------------+ 154 Figure 1: NETCONF Protocol Layers 156 As of now, however, WebSocket protocol is available[RFC6455]. It is 157 based on HTTP, which is familiar to all. And, it has a bi- 158 directional capability. Thus, by using WebSocket protocol, it's 159 possible to realize NETCONF that is used over HTTP with ease and that 160 supports notification mechanism specified in [RFC5277]. 162 Some WebSocket implementations already exist today. As examples of 163 WebSocket server implementation, Jetty[Jetty], Kaazing[Kaazing], and 164 the like are available. And, as examples of WebSocket client 165 implementation, Jetty[Jetty] is available. Moreover, as examples of 166 Web-browsers that can work as WebSocket client, Chrome[Chrome], and 167 FireFox[FireFox] and the like are available. 169 WebSocket server and client implementations mentioned above are 170 providing libraries. And WebSocket protocol itself also defines 171 API[WebSocket API] to be used on Web-browsers. Thus, by using those 172 libraries and APIs, developers can develop NETCONF server, install- 173 based NETCONF client, and browser-based NETCONF client with ease that 174 use WebSocket for transporting NETCONF. 176 3. Use Case 178 XML, which NETCONF uses for message encoding, has high compatibility 179 with HTTP in that XML are easily manipulated on Web-browsers by 180 JavaScript DOM (Document Object Model) API. Hence, there are cases 181 in which XML is used over HTTP to manage network devices. But as far 182 as those XML are proprietary, the way of managing network devices and 183 items to manage are different from network device to network device. 184 If NETCONF, instead of proprietary XML, and its data models are used 185 for above cases, it will provide a way of managing various network 186 devices in a same manner. 188 Browser-based network management systems don't require installation 189 on computers. For this reason, some operators prefer browser-based 190 network management systems. This trend might accelerate in the age 191 of tablet computers. In this respect, it is rational for NETCONF to 192 have an option to be used through browser-based network management 193 system. Operators will be able to manage network devices from any 194 computers without installation. 196 4. Concerns about Using HTTP and WebSocket 198 There are some drawbacks inherent in HTTP as mentioned in the section 199 2.4 of [RFC4743], which describes the way of transporting NETCONF 200 over SOAP/HTTPS. But, for these drawbacks, the same section makes 201 suggestions. Those suggestions are effective when WebSocket is used 202 for transporting NETCONF. That is, intermediate proxies SHOULD not 203 be used since it may close idle connections. And, the fields of 204 'Cache-Control' and 'Pragma' in HTTP header, which is sent before or 205 during WebSocket opening handshake, SHOULD be specified as 'no- 206 cache.' 208 WebSocket has had several security concerns. But it incorporated its 209 own security mechanisms such as origin header and masking, as stated 210 in the Security Considerations section of [RFC6455]. In any case, 211 using TLS is necessary for ensuring authentication and 212 confidentiality, when WebSocket is used for transporting NETCONF. 214 5. Handling of NETCONF Username 216 NETCONF[RFC6241] mandates underlying transport protocol to carry 217 NETCONF username and to provide it to NETCONF server. In the case of 218 transporting NETCONF over WebSocket, this memo proposes that NETCONF 219 username SHOULD be carried and provided in compliance with NETCONF 220 over TLS[I-D.badra-netconf-rfc5539bis]. 222 In the case of transporting NETCONF over WebSocket, TLS is necessary 223 for the user authentication. In order to ensure that NETCONF access 224 control is done consistently with TLS authentication, NETCONF 225 username SHOULD be matched with TLS authentication data. At present, 226 [I-D.badra-netconf-rfc5539bis] is proposing ways of extracting 227 NETCONF username from TLS authentication data. Being compliant with 228 these approaches is the most efficient. At least, it is confirmed 229 that NETCONF server using WebSocket/TLS for underlying protocol can 230 see TLS Certificate at the time of TLS handshake and can extract 231 NETCONF username from the Certificate. 233 6. Transporting NETCONF Messages over WebSocket Protocol 235 This section specifies how NETCONF messages are exchanged between 236 NETCONF client and server over WebSocket protocol. 238 6.1. Message Sequence 240 Simplified overall message sequence is depicted in Figure 2. This 241 sequence is depicting the case in which NETCONF client runs on a Web- 242 browser. However, it must be noted that there is also a case in 243 which NETCONF client runs as an install-based software developed with 244 WebSocket client library. 246 +---------------------------+ +---------------------------+ 247 | Network Management System | | Network Device | 248 | | | (e.g. 192.168.1.1) | 249 | +---------++-----------+ | | +-----------++---------+ | 250 | | NETCONF || WebSocket | | | | WebSocket || NETCONF | | 251 | | Client || (HTTP) | | | | (HTTP) || Server | | 252 | | || Client | | | | Server || | | 253 | +---------++-----------+ | | +-----------++---------+ | 254 +------|-----------|--------+ +--------|-----------|------+ 255 | | | | 256 |Load *.html| | | 257 |---------->| Hello(TLS) | | 258 | / |------------------->| | 259 | | | Server Certificate | | 260 | TLS |<-------------------| | 261 | handshake | Client Certificate | | 262 | | |------------------->|NETCONF username 263 | | | Finished(TLS) |---------->| 264 | \ |<-------------------| | 265 | | | | 266 | | GET(HTTP) | | 267 | |------------------->| | 268 | | 200 OK(HTTP) | | 269 | |<-------------------| | 270 |<----------| | | 271 .... 272 |Call WebSocket() API | | 273 |---------->| | | 274 | |Connection: Upgrade | | 275 | / |------------------->| | 276 | WebSocket |Connection: Upgrade | | 277 | opening |<-------------------| | 278 | handshake | ACK(TCP) | | 279 | \ |------------------->| | 280 |Invoke onopen = function() { } | | 281 |<----------| | | 282 | | | | 283 |(NETCONF) | | 284 |---------->| | | 285 | |------------------->| | 286 | | |---------->| 287 | | | | 288 | | |<----------| 289 | |<-------------------| | 290 |<----------| | | 291 .... 292 |(NETCONF) | | 293 |---------->| | | 294 | |------------------->| | 295 | | |---------->| 296 | | | | 297 | | |<----------| 298 | |<-------------------| | 299 |<----------| | | 300 .... 301 | | (NETCONF)| 302 | | |<----------| 303 | |<-------------------| | 304 |<----------| | | 305 | | | | 307 Figure 2: Message Sequence 309 First of all, a browser starts loading of an html file, which imports 310 the code of NETCONF client, over TLS. This invokes TLS handshake. 311 At the time of TLS handshake, NETCONF server can extract NETCONF 312 username from Certificate according to the algorithm described in 313 [I-D.badra-netconf-rfc5539bis]. After TLS handshake is complete, the 314 html file is loaded onto the browser. 316 The loaded html file works as NETCONF client and it initiates 317 WebSocket opening handshake. When NETCONF server receives a 318 WebSocket connection request, it notifies the client of whether 319 WebSocket handshake has succeeded. After WebSocket connection is 320 established, NETCONF client starts sending NETCONF messages over the 321 connection. 323 NETCONF messages are exchanged between NETCONF client and 324 server, at first, so that a NETCONF session is established and a 325 NETCONF session ID is allocated by NETCONF server to the NETCONF 326 client. Then, NETCONF messages are exchanged. After NETCONF 327 message of request is approved by the 328 NETCONF server, NETCONF messages are sent from NETCONF 329 server asynchronously. 331 When WebSocket server shuts down, NETCONF session as well as 332 WebSocket connection is killed. Since NETCONF notification 333 subscription is associated with NETCONF session ID as written in 334 section 3.5 of NETCONF notification mechanism[RFC5277], subscription 335 status is lost when WebSocket server shuts down. Thus, it is 336 necessary to redo WebSocket opening handshake, NETCONF session 337 establishment, and NETCONF notification subscription after WebSocket 338 server reboots. 340 Without any indications, TCP port numbers of 443 is automatically 341 used for transporting NETCONF messages over WebSocket over TLS. When 342 port number other than 443 needs to be used, the number SHOULD be 343 specified at both NETCONF client and server respectively. 345 6.2. WebSocket Message at Handshake from NETCONF Client 347 WebSocket opening handshake is necessary for the establishment of an 348 WebSocket connection, which is used for NETCONF message exchange. 349 The WebSocket handshake is initiated by a NETCONF client. Figure 3 350 is an example of WebSocket message sent from the NETCONF client at 351 the time of WebSocket handshake. 353 C: GET /netconf HTTP/1.1 354 C: Host: 192.168.1.1 355 C: Upgrade: websocket 356 C: Connection: Upgrade 357 C: Sec-WebSocket-Key: dGhlIHNhbXBsZSBub25jZQ== 358 C: Origin: http://192.168.1.1 359 C: Sec-WebSocket-Protocol: netconf 360 C: Sec-WebSocket-Version: 13 362 Figure 3: WebSocket Message from NETCONF Client 364 Most of the fileds in Figure 3 are generated automatically by 365 WebSocket client. The only field that the NETCONF client needs to 366 specify is 'Sec-WebSocket-Protocol' field, so-called subprotocol 367 field. The NETCONF client has to specify the field as 'netconf,' for 368 example, so that the NETCONF server understands that messages sent 369 over this connection is directed towards NETCONF server. 371 Aforementioned establishment of the WebSocket connection and 372 specification of subprotocol is made by using WebSocket API in the 373 html file of the NETCONF client as depicted in Figure 4. 375 var wssURL = "wss://" + location.host; 376 var wss = new WebSocket(wssURL, "netconf"); 378 Figure 4: WebSocket API in NETCONF Clients for Initiating Handshake 380 6.3. WebSocket Message at Handshake from NETCONF Server 382 Figure 5 is an example of WebSocket message sent from the NETCONF 383 server to the NETCONF client at the time of WebSocket handshake. 385 S: HTTP/1.1 101 Switching Protocols 386 S: Upgrade: websocket 387 S: Connection: Upgrade 388 S: Sec-WebSocket-Accept: s3pPLMBiTxaQ9kYGzzhZRbK+xOo= 389 S: Sec-WebSocket-Protocol: netconf 391 Figure 5: WebSocket Message from NETCONF Server 393 Most of the fields in Figure 5 are generated automatically by 394 WebSocket server, too. The only field that the NETCONF server needs 395 to specify is 'Sec-WebSocket-Protocol' field. The NETCONF server has 396 to specify the field as 'netconf,' for example, in order to let the 397 NETCONF client know that the WebSocket server in the network device 398 accepts NETCONF messages. 400 Unlike the WebSocket client, there's no standardized WebSocket API 401 for WebSocket server. But, there are some WebSocket server 402 implementations as mentioned in section 2. Thus, it's possible to 403 develop a part of WebSocket opening handshake at NETCONF server with 404 ease by using libraries provided by those implementations. 406 6.4. NETCONF Message over WebSocket at NETCONF Client 408 NETCONF message exchange between NETCONF client and server starts 409 after an WebSocket connection is established. messages are 410 exchanged, first, for the establishment of a NETCONF session and 411 allocation of NETCONF session ID. Then, messages like are sent from NETCONF client to NETCONF server for NETCONF 413 configurations. And messages like are 414 sent from NETCONF client to NETCONF server for subscription of 415 NETCONF notification. Moreover, messages like are 416 sent asynchronously from NETCONF server to NETCONF client for NETCONF 417 notification. During this data transfer period, both NETCONF 418 configuration messages and NETCONF notification messages are 419 encapsulated as a payload of WebSocket protocol according to the Data 420 Framing specified in the section 5.2 of WebSocket protocol[RFC6455]. 421 This encapsulation is made by WebSocket layer. 423 Sending and receiving of NETCONF messages at NETCONF client is made 424 by using WebSocket API. The example is illustrated in Figure 6. 426 wss.onopen = function() { 427 // WebSocket connection has been established. 428 // Thus, NETCONF can be sent here 429 // by send() method. 430 wss.send("message to send"); 431 .... 432 }; 434 wss.onmessage = function (evt) { 435 // NETCONF message has arrived. 436 // Thus, NETCONF message can be parsed here by DOM APIs. 438 var parser = new DOMParser(); 439 var dom = parser.parseFromString(evt.data, "text/xml"); 440 .... 441 if(dom.documentElement.nodeName == "hello"){ 442 // The NETCONF message turned out to be 443 // NETCONF . 444 // Subsequent NETCONF message can be sent here 445 // by send() method. 446 wss.send("message to send"); 447 ... 448 } 449 }; 451 Figure 6: WebSocket API in NETCONF Client for Sending Messages 453 As shown in Figure 6, NETCONF messages are sent from NETCONF client 454 by using WebSocket API of "wss.send()." And, NETCONF messages are 455 received at NETCONF client by using WebSocket API of 456 "wss.onmessage()." 458 The contents of NETCONF messages exchanged through above API might be 459 either a hand-written XML messages typed into network management 460 system or XML messages created by JavaScript DOM API according to the 461 data set on the network management system. It must be noted that in 462 the case of transporting NETCONF over WebSocket, parts need to 463 be created by NETCONF client, unlike the case of transporting NETCONF 464 over SOAP/HTTPS, in which parts are generated in SOAP layer. 466 6.5. NETCONF Message over WebSocket at NETCONF Server 468 Unlike the WebSocket client, the way of sending and receiving NETCONF 469 message at NETCONF server is proprietary since there's no 470 standardized API for WebSocket server. But, there are some WebSocket 471 server implementations as mentioned in section 2. Thus, it's 472 possible to develop NETCONF server with ease by using libraries 473 provided by those implementations. 475 7. Security Considerations 477 It is necessary to use TLS (Transport Layer Security) in order to 478 ensure Transport-level security, such as authentication of users and 479 encryption of data transfer. That is, NETCONF has to be sent in the 480 form of NETCONF over WebSocket over TLS (WSS). 482 In addition, the security considerations of NETCONF 483 protocol[RFC6241], NETCONF Notification mechanism[RFC5277], and 484 WebSocket protocol[RFC6455] are applicable to this document. 485 Implementers or users SHOULD take these considerations into account. 487 8. IANA Considerations 489 As written in section 11.5 of WebSokcet protocol[RFC6455], NETCONF's 490 Subprotocol Common Name, to be exchanged in 'Sec-WebSocket-Protocol' 491 field at WebSocket opening handshake, coupled with Identifier and 492 Definition need to be registered with the WebSocket Subprotocol Name 493 Registry. 495 9. Acknowledgements 497 This document was written using the xml2rfc tool described in 498 [RFC2629]. 500 10. References 502 10.1. Normative References 504 [I-D.badra-netconf-rfc5539bis] 505 Badra, M., "NETCONF Over Transport Layer Security (TLS)", 506 draft-badra-netconf-rfc5539bis-02 (work in progress), 507 April 2012. 509 [I-D.ietf-netconf-rfc4743-rfc4744-to-historic] 510 Wijnen, B., "RFC4743 and RFC4744 to Historic status", 511 draft-ietf-netconf-rfc4743-rfc4744-to-historic-00 (work in 512 progress), September 2012. 514 [RFC4743] Goddard, T., "Using NETCONF over the Simple Object 515 Access Protocol (SOAP)", RFC 4743, December 2006. 517 [RFC5277] Chisholm, S. and H. Trevino, "NETCONF Event 518 Notifications", RFC 5277, July 2008. 520 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 521 Bierman, "Network Configuration Protocol (NETCONF)", 522 RFC 6241, June 2011. 524 [RFC6455] Fette, I. and A. Melnikov, "The WebSocket Protocol", 525 RFC 6455, December 2011. 527 [WebSocket API] 528 "The WebSocket API". 530 532 10.2. Informative References 534 [Chrome] "Chrome". 536 538 [FireFox] "FireFox". 540 542 [Jetty] "Jetty WebServer". 544 546 [Kaazing] "Kaazing". 548 550 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 551 June 1999. 553 Authors' Addresses 555 Tomoyuki Iijima 556 Hitachi, Ltd. 557 292 Yoshida-cho, Totsuka-ku 558 Yokohama, Kanagawa 244-0817 559 Japan 561 Phone: +81-45-860-2156 562 Email: tomoyuki.iijima.fg@hitachi.com 564 Hiroyasu Kimura 565 Alaxala Networks Corp. 566 Shin-Kawasaki Mitsui Bldg. 567 890 Saiwai-ku Kashimada 568 Kawasaki, Kanagawa 212-0058 569 Japan 571 Phone: +81-44-549-1735 572 Fax: +81-44-549-1272 573 Email: h-kimura@alaxala.net 575 Yoshifumi Atarashi 576 Alaxala Networks Corp. 577 Shin-Kawasaki Mitsui Bldg. 578 890 Saiwai-ku Kashimada 579 Kawasaki, Kanagawa 212-0058 580 Japan 582 Phone: +81-44-549-1735 583 Fax: +81-44-549-1272 584 Email: atarashi@alaxala.net 586 Hidemitsu Higuchi 587 Alaxala Networks Corp. 588 Shin-Kawasaki Mitsui Bldg. 589 890 Saiwai-ku Kashimada 590 Kawasaki, Kanagawa 212-0058 591 Japan 593 Phone: +81-44-549-1735 594 Fax: +81-44-549-1272 595 Email: hidemitsu.higuchi@alaxala.com