idnits 2.17.1 draft-ietf-netconf-call-home-11.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 22, 2015) is 3138 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 6125 (Obsoleted by RFC 9525) ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group K. Watsen 3 Internet-Draft Juniper Networks 4 Intended status: Standards Track September 22, 2015 5 Expires: March 25, 2016 7 NETCONF Call Home and RESTCONF Call Home 8 draft-ietf-netconf-call-home-11 10 Abstract 12 This RFC presents NETCONF Call Home and RESTCONF Call Home, which 13 enable a NETCONF or RESTCONF server to initiate a secure connection 14 to a NETCONF or RESTCONF client respectively. 16 Editorial Note (To be removed by RFC Editor) 18 This draft contains many placeholder values that need to be replaced 19 with finalized values at the time of publication. This note 20 summarizes all of the substitutions that are needed. Please note 21 that no other RFC Editor instructions are specified anywhere else in 22 this document. 24 Artwork in this document contains placeholder references for this 25 draft. Please apply the following replacement: 27 o "XXXX" --> the assigned RFC value for this draft 29 This document contains references to another draft in progress, both 30 in the Normative References section, as well as in body text 31 throughout. Please update the following reference to reflect its 32 final RFC assignment: 34 o draft-ietf-netconf-restconf 36 Artwork in this document contains placeholder values for ports 37 pending IANA assignment from "draft-ietf-netconf-call-home". Please 38 apply the following replacements: 40 o "PORT-X" --> the assigned port value for "netconf-ch-ssh" 42 o "PORT-Y" --> the assigned port value for "netconf-ch-tls" 44 o "PORT-Z" --> the assigned port value for "restconf-ch-tls" 46 The following two Appendix sections are to be removed prior to 47 publication: 49 o Appendix A. Change Log 51 o Appendix B. Open Issues 53 Status of This Memo 55 This Internet-Draft is submitted in full conformance with the 56 provisions of BCP 78 and BCP 79. 58 Internet-Drafts are working documents of the Internet Engineering 59 Task Force (IETF). Note that other groups may also distribute 60 working documents as Internet-Drafts. The list of current Internet- 61 Drafts is at http://datatracker.ietf.org/drafts/current/. 63 Internet-Drafts are draft documents valid for a maximum of six months 64 and may be updated, replaced, or obsoleted by other documents at any 65 time. It is inappropriate to use Internet-Drafts as reference 66 material or to cite them other than as "work in progress." 68 This Internet-Draft will expire on March 25, 2016. 70 Copyright Notice 72 Copyright (c) 2015 IETF Trust and the persons identified as the 73 document authors. All rights reserved. 75 This document is subject to BCP 78 and the IETF Trust's Legal 76 Provisions Relating to IETF Documents 77 (http://trustee.ietf.org/license-info) in effect on the date of 78 publication of this document. Please review these documents 79 carefully, as they describe your rights and restrictions with respect 80 to this document. Code Components extracted from this document must 81 include Simplified BSD License text as described in Section 4.e of 82 the Trust Legal Provisions and are provided without warranty as 83 described in the Simplified BSD License. 85 Table of Contents 87 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 88 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 89 1.2. Requirements Terminology . . . . . . . . . . . . . . . . 4 90 1.3. Applicability Statement . . . . . . . . . . . . . . . . . 5 91 1.4. Relation to RFC 4253 . . . . . . . . . . . . . . . . . . 5 92 1.5. The NETCONF/RESTCONF Convention . . . . . . . . . . . . . 5 93 2. The NETCONF or RESTCONF Client . . . . . . . . . . . . . . . 5 94 2.1. Protocol Operation . . . . . . . . . . . . . . . . . . . 6 95 2.2. Configuration Data Model . . . . . . . . . . . . . . . . 7 96 3. The NETCONF or RESTCONF Server . . . . . . . . . . . . . . . 7 97 3.1. Protocol Operation . . . . . . . . . . . . . . . . . . . 7 98 3.2. Configuration Data Model . . . . . . . . . . . . . . . . 8 99 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 100 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 101 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 102 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 103 7.1. Normative References . . . . . . . . . . . . . . . . . . 10 104 7.2. Informative References . . . . . . . . . . . . . . . . . 11 105 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 106 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 12 107 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 12 108 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 12 109 A.4. 03 to 04 . . . . . . . . . . . . . . . . . . . . . . . . 12 110 A.5. 04 to 05 . . . . . . . . . . . . . . . . . . . . . . . . 12 111 A.6. 05 to 06 . . . . . . . . . . . . . . . . . . . . . . . . 13 112 A.7. 06 to 07 . . . . . . . . . . . . . . . . . . . . . . . . 13 113 A.8. 07 to 08 . . . . . . . . . . . . . . . . . . . . . . . . 13 114 A.9. 08 to 09 . . . . . . . . . . . . . . . . . . . . . . . . 13 115 A.10. 09 to 10 . . . . . . . . . . . . . . . . . . . . . . . . 13 116 A.11. 10 to 11 . . . . . . . . . . . . . . . . . . . . . . . . 13 117 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 13 119 1. Introduction 121 This RFC presents NETCONF Call Home and RESTCONF Call Home, which 122 enable a NETCONF or RESTCONF server to initiate a secure connection 123 to a NETCONF or RESTCONF client respectively. 125 NETCONF Call Home supports both of the secure transports used by the 126 NETCONF protocol [RFC6241], SSH and TLS. The NETCONF protocol's 127 binding to SSH is defined in [RFC6242]. The NETCONF protocol's 128 binding to TLS is defined in [RFC7589]. 130 RESTCONF Call Home only supports TLS, the same as the RESTCONF 131 protocol [draft-ietf-netconf-restconf]. The RESTCONF protocol's 132 binding to TLS is defined in [draft-ietf-netconf-restconf]. 134 The SSH protocol is defined in [RFC4253]. The TLS protocol is 135 defined in [RFC5246]. Both the SSH and TLS protocols are layered on 136 top of the TCP protocol, which is defined in [RFC793]. 138 Both NETCONF Call Home and RESTCONF Call Home preserve all but one of 139 the client/server roles in their respective protocol stacks, as 140 compared to client-initiated NETCONF and RESTCONF connections. The 141 one and only role reversal that occurs is at the TCP layer; that is, 142 which peer is the TCP-client and which is the TCP-server. 144 For example, a network element is traditionally the TCP-server. 145 However, when calling home, the network element becomes the TCP- 146 client. The network element's secure transport layer roles (SSH- 147 server, TLS-server) and its application layer roles (NETCONF-server, 148 RESTCONF-server) both remain the same. 150 Having consistency in both the secure transport layer (SSH, TLS) and 151 application layer (NETCONF, RESTCONF) roles conveniently enables 152 deployed network management infrastructure to support call home also. 153 For instance, existing certificate chains and user authentication 154 mechanisms are unaffected by call home. 156 1.1. Motivation 158 Call home is generally useful for both the initial deployment and on- 159 going management of networking elements. Here are some scenarios 160 enabled by call home: 162 o The network element may proactively call home after being powered 163 on for the first time in order to register itself with its 164 management system. 166 o The network element may access the network in a way that 167 dynamically assigns it an IP address, but does not register its 168 assigned IP address to a mapping service (e.g., dynamic DNS). 170 o The network element may be deployed behind a firewall that 171 implements network address translation (NAT) for all internal 172 network IP addresses. 174 o The network element may be deployed behind a firewall that doesn't 175 allow any management access to the internal network. 177 o The network element may be configured in "stealth mode" and thus 178 doesn't have any open ports for the management system to connect 179 to. 181 o The operator may prefer to have network elements initiate 182 management connections, believing it is easier to secure one open 183 port in the data center than to have an open port on each network 184 element in the network. 186 1.2. Requirements Terminology 188 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 189 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 190 document are to be interpreted as described in RFC 2119 [RFC2119]. 192 1.3. Applicability Statement 194 The techniques described in this document are suitable for network 195 management scenarios such as the ones described in Section 1.1. 196 However, these techniques are only defined for NETCONF Call Home and 197 RESTCONF Call Home, as described in this document. 199 The reason for this restriction is that different protocols have 200 different security assumptions. The NETCONF and RESTCONF protocols 201 require clients and servers to verify the identity of the other 202 party. This requirement is specified for the NETCONF protocol in 203 Section 2.2 of [RFC6241], and is specified for the RESTCONF protocol 204 in Sections 2.4 and 2.5 of [draft-ietf-netconf-restconf]). 206 This contrasts with the base SSH and TLS protocols, which do not 207 require programmatic verification of the other party (section 9.3.4 208 of [RFC4251], section 4 of [RFC4252], and section 7.3 of [RFC5246]). 209 In such circumstances, allowing the SSH/TLS server to contact the 210 SSH/TLS client would open new vulnerabilities. Any use of call home 211 with SSH/TLS for purposes other than NETCONF or RESTCONF will need a 212 thorough, contextual security analysis. 214 1.4. Relation to RFC 4253 216 This document uses the SSH Transport Layer Protocol [RFC4253] with 217 the exception that the statement "The client initiates the 218 connection" made in Section 4 (Connection Setup) does not apply. 219 Assuming the reference to client means "SSH client" and the reference 220 to connection means "TCP connection", this statement doesn't hold 221 true in call home, where the network element is the SSH server and 222 yet still initiates the TCP connection. Security implications 223 related to this change are discussed in Security Considerations 224 (Section 4). 226 1.5. The NETCONF/RESTCONF Convention 228 Throughout the remainder of this document, the term "NETCONF/ 229 RESTCONF" is used as an abbreviation in place of the text "the 230 NETCONF or the RESTCONF". The NETCONF/RESTCONF abbreviation is not 231 intended to require or to imply that a client or server must 232 implement both the NETCONF standard and the RESTCONF standard. 234 2. The NETCONF or RESTCONF Client 236 The term "NETCONF/RESTCONF client" can refer to the [RFC6241], 237 Section 1.1 "client". 239 2.1. Protocol Operation 241 C1 The NETCONF/RESTCONF client listens for TCP connection requests 242 from NETCONF/RESTCONF servers. The client SHOULD listen for 243 connections on the IANA-assigned ports defined in section 244 Section 5, but MAY be configured to use a non-standard port. 246 C2 The NETCONF/RESTCONF client accepts an incoming TCP connection 247 request and a TCP connection is established. 249 C3 Using this TCP connection, the NETCONF/RESTCONF client MUST 250 immediately start either the SSH-client [RFC4253] or the TLS- 251 client [RFC5246] protocol. For example, assuming the use of the 252 IANA-assigned ports, the SSH-client protocol is started when the 253 connection is accepted on port PORT-X and the TLS-client protocol 254 is started when the connection is accepted on either port PORT-Y 255 or PORT-Z. 257 C4 If using TLS, the NETCONF/RESTCONF client MUST advertise 258 "peer_allowed_to_send", as defined by [RFC6520]. This is 259 required so NETCONF/RESTCONF servers can depend on it being there 260 for call home connections, when keep-alives are needed the most. 262 C5 As part of establishing an SSH or TLS connection, the NETCONF/ 263 RESTCONF client MUST validate the server's presented host key or 264 certificate. This validation MAY be accomplished by certificate 265 path validation or by comparing the host key or certificate to a 266 previously trusted or "pinned" value. 268 C6 If certificate path validation is used, the NETCONF/RESTCONF 269 client MUST ensure that the certificate has a valid chain of 270 trust to a preconfigured trust anchor and that the certificate 271 encodes an "identifier" [RFC6125] that the client had awareness 272 of prior to the connection attempt. How identifiers are encoded 273 in certificates MAY be determined by a policy associated with the 274 certificate's trust anchor. For instance, a given trust anchor 275 may be known to only sign IDevID certificates [Std-802.1AR-2009] 276 having a unique identifier (e.g., serial number) in the X.509 277 certificate's "CommonName" field. 279 C7 After the server's host key or certificate is validated, the SSH 280 or TLS protocol proceeds as normal to establish a SSH or TLS 281 connection. 283 C8 Once the SSH or TLS connection is established, the NETCONF/ 284 RESTCONF client MUST immediately start using either the NETCONF- 285 client [RFC6241] or RESTCONF-client [draft-ietf-netconf-restconf] 286 protocol. Assuming the use of the IANA-assigned ports, the 287 NETCONF-client protocol is started when the connection is 288 accepted on either port PORT-X or PORT-Y and the RESTCONF-client 289 protocol is started when the connection is accepted on port PORT- 290 Z. 292 2.2. Configuration Data Model 294 How a NETCONF or RESTCONF client is configured is outside the scope 295 of this document. This includes configuration that might be used to 296 enable listening for call home connections, configuring trust 297 anchors, or configuring identifiers for expected connections. 299 3. The NETCONF or RESTCONF Server 301 The term "NETCONF/RESTCONF server" can refer to the [RFC6241], 302 Section 1.1 "server". 304 3.1. Protocol Operation 306 S1 The NETCONF/RESTCONF server initiates a TCP connection request to 307 the NETCONF/RESTCONF client. The server SHOULD connect to one of 308 the IANA-assigned ports defined in section Section 5, but MAY be 309 configured to use a non-standard port. Using the IANA-assigned 310 ports, the server connects to port PORT-X for NETCONF over SSH, 311 port PORT-Y for NETCONF over TLS, and port PORT-Z for RESTCONF 312 over TLS. 314 S2 The TCP connection request is accepted and a TCP connection is 315 established. 317 S3 Using this TCP connection, the NETCONF/RESTCONF server MUST 318 immediately start using either the SSH-server [RFC4253] or the 319 TLS-server [RFC5246] protocol, depending on how it is configured. 320 For example, assuming the use of the IANA-assigned ports, the 321 SSH-server protocol is used after connecting to the remote port 322 PORT-X and the TLS-server protocol is used after connecting to 323 one of the remote ports PORT-Y or PORT-Z. 325 S4 As part of establishing the SSH or TLS connection, the NETCONF/ 326 RESTCONF server will send its host key or certificate to the 327 client. If a certificate is sent, the server MUST also send all 328 intermediate certificates leading up to the certificate's trust 329 anchor. How to send a list of certificates is defined for SSH in 330 [RFC6187] Section 2.1, and for TLS in [RFC5246] Section 7.4.2. 332 S5 In most cases, establishing the SSH or TLS connection also 333 entails server authentication of client credentials; only with 334 RESTCONF do some client authentication schemes occur after the 335 secure transport connection (TLS) has been established. If 336 client authentication is required, and the client is unable to 337 successfully authenticate itself to the server in an amount of 338 time defined by local policy, the server MUST close the 339 connection. 341 S6 Once the SSH or TLS connection is established, the NETCONF/ 342 RESTCONF server MUST immediately start using either the NETCONF- 343 server [RFC6241] or RESTCONF-server [draft-ietf-netconf-restconf] 344 protocol, depending on how it is configured. Assuming the use of 345 the IANA-assigned ports, the NETCONF-server protocol is used 346 after connecting to remote port PORT-X or PORT-Y, and the 347 RESTCONF-server protocol is used after connecting to remote port 348 PORT-Z. 350 S7 If a persistent connection is desired, the NETCONF/RESTCONF 351 server, as the connection initiator, SHOULD actively test the 352 aliveness of the connection using a keep-alive mechanism. For 353 TLS based connections, the NETCONF/RESTCONF server SHOULD send 354 HeartbeatRequest messages, as defined by [RFC6520]. For SSH 355 based connections, per section 4 of [RFC4254], the NETCONF/ 356 RESTCONF server SHOULD send a SSH_MSG_GLOBAL_REQUEST message with 357 the purposely nonexistent "request name" value 358 "keepalive@ietf.org" and the "want reply" value set to '1'. 360 3.2. Configuration Data Model 362 How a NETCONF or RESTCONF server is configured is outside the scope 363 of this document. This includes configuration that might be used to 364 specify hostnames, IP addresses, ports, algorithms, or other relevant 365 parameters. That said, a YANG [RFC6020] model for configuring 366 NETCONF and RESTCONF servers, including call home, is provided in 367 [draft-ietf-netconf-server-model]. 369 4. Security Considerations 371 The security considerations described in [RFC6242] and [RFC7589], and 372 by extension [RFC4253], [RFC5246], and [draft-ietf-netconf-restconf] 373 apply here as well. 375 This RFC deviates from standard SSH and TLS usage by having the SSH/ 376 TLS server initiate the underlying TCP connection. This reversal is 377 incongruous with [RFC4253], which says "the client initiates the 378 connection" and also [RFC6125], which says "the client MUST construct 379 a list of acceptable reference identifiers, and MUST do so 380 independently of the identifiers presented by the service." To 381 account for these variances, this RFC requires that the NETCONF/ 382 RESTCONF client validate the SSH host key or certificate via 383 certificate path validation to a preconfigured trust anchor or by 384 comparing the host key or certificate to a previously trusted or 385 "pinned" value. Furthermore, if certificate path validation is used, 386 this RFC requires that the client be able to match a presented 387 identifier encoded in the certificate with an identifier the client 388 was preconfigured to expect. 390 An attacker could launch a denial of service (DoS) attack on the 391 NETCONF/RESTCONF client by having it perform computationally 392 expensive operations, before deducing that the attacker doesn't 393 posses a valid key. This is no different than any secured service 394 and all common precautions apply (e.g., blacklisting the source 395 address after a set number of unsuccessful login attempts). 397 5. IANA Considerations 399 This RFC requests that IANA assigns three TCP port numbers in the 400 "Registered Port Numbers" range with the service names "netconf-ch- 401 ssh", "netconf-ch-tls", and "restconf-ch-tls". These ports will be 402 the default ports for NETCONF Call Home and RESTCONF Call Home 403 protocols. Below is the registration template following the rules in 404 [RFC6335]. 406 Service Name: netconf-ch-ssh 407 Transport Protocol(s): TCP 408 Assignee: IESG 409 Contact: IETF Chair 410 Description: NETCONF Call Home (SSH) 411 Reference: RFC XXXX 412 Port Number: PORT-X 414 Service Name: netconf-ch-tls 415 Transport Protocol(s): TCP 416 Assignee: IESG 417 Contact: IETF Chair 418 Description: NETCONF Call Home (TLS) 419 Reference: RFC XXXX 420 Port Number: PORT-Y 422 Service Name: restconf-ch-tls 423 Transport Protocol(s): TCP 424 Assignee: IESG 425 Contact: IETF Chair 426 Description: RESTCONF Call Home (TLS) 427 Reference: RFC XXXX 428 Port Number: PORT-Z 430 6. Acknowledgements 432 The author would like to thank the following for lively discussions 433 on list and in the halls (ordered by last name): Andy Bierman, Martin 434 Bjorklund, Mehmet Ersue, Wes Hardaker, Stephen Hanna, David 435 Harrington, Jeffrey Hutzelman, Radek Krejci, Alan Luchuk, Mouse, Russ 436 Mundy, Tom Petch, Juergen Schoenwaelder, Peter Saint-Andre, Joe 437 Touch, Hannes Tschofenig, Sean Turner, and Bert Wijnen. 439 7. References 441 7.1. Normative References 443 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 444 Requirement Levels", BCP 14, RFC 2119, March 1997. 446 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 447 Protocol Architecture", RFC 4251, January 2006. 449 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 450 Authentication Protocol", RFC 4252, January 2006. 452 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 453 Transport Layer Protocol", RFC 4253, January 2006. 455 [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 456 Connection Protocol", RFC 4254, January 2006. 458 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 459 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 461 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 462 Verification of Domain-Based Application Service Identity 463 within Internet Public Key Infrastructure Using X.509 464 (PKIX) Certificates in the Context of Transport Layer 465 Security (TLS)", RFC 6125, March 2011. 467 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 468 Shell Authentication", RFC 6187, March 2011. 470 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 471 Bierman, "Network Configuration Protocol (NETCONF)", RFC 472 6241, June 2011. 474 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 475 Shell (SSH)", RFC 6242, June 2011. 477 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 478 Cheshire, "Internet Assigned Numbers Authority (IANA) 479 Procedures for the Management of the Service Name and 480 Transport Protocol Port Number Registry", BCP 165, RFC 481 6335, August 2011. 483 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 484 Layer Security (TLS) and Datagram Transport Layer Security 485 (DTLS) Heartbeat Extension", RFC 6520, February 2012. 487 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 488 NETCONF Protocol over Transport Layer Security (TLS) with 489 Mutual X.509 Authentication", RFC 7589, June 2015. 491 [RFC793] Postel, J., "TRANSMISSION CONTROL PROTOCOL", STD 7, 492 September 1981, . 494 [draft-ietf-netconf-restconf] 495 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 496 Protocol", draft-ieft-netconf-restconf-04 (work in 497 progress), 2014, . 500 7.2. Informative References 502 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 503 Network Configuration Protocol (NETCONF)", RFC 6020, 504 October 2010. 506 [Std-802.1AR-2009] 507 IEEE SA-Standards Board, "IEEE Standard for Local and 508 metropolitan area networks - Secure Device Identity", 509 December 2009, . 512 [draft-ietf-netconf-server-model] 513 Watsen, K. and J. Schoenwaelder, "NETCONF Server 514 Configuration Model", 2014, . 517 Appendix A. Change Log 519 A.1. 00 to 01 521 o The term "TCP connection" is now used throughout. 523 o The terms "network element" and "management system" are now only 524 used in the Motivation section. 526 o Restructured doc a little to create an Introduction section. 528 o Fixed reference in Applicability Statement so it would work 529 equally well for SSH and TLS. 531 o Fixed reported odd wording and three references. 533 A.2. 01 to 02 535 o Added call home support for the RESTCONF protocol. 537 o Fixed paragraph 3 of Security Considerations to equally apply to 538 the TLS protocol. 540 A.3. 02 to 03 542 o Tried to improve readability (issue #6) 544 o Removed "FIXME" in section 1.3 (issue #7) 546 o Added RFC Editor notes (issue #8) 548 o Removed "TCP session" term (issue #9) 550 o Improved language for usage of IANA-assigned ports (issue #10) 552 A.4. 03 to 04 554 o Replaced "verify credentials" with "verify identity" (issue #11) 556 A.5. 04 to 05 558 o Applied many suggestions from WGLC 560 o Removed essay like "Server Identification and Verification" 561 section 563 o Added text about keep-alives 564 o Added Configuration Data Model section for client protocol 566 o Improved Security Considerations section 568 A.6. 05 to 06 570 o Addressed comments raised by Alan Luchuk. 572 A.7. 06 to 07 574 o replaced "reference identifier" with "identifier" 576 o added reference to RFC6125 578 o moved reference to 6020 to Informative section 580 A.8. 07 to 08 582 o Added text regarding client authentication 584 o Now says client-initiated (not standard) NETCONF/RESTCONF 585 connections 587 o Now says server must send all (not any) intermediate certificates 589 o Improved wording based on suggestions from Jonathan and Tom 591 A.9. 08 to 09 593 o Added dynamic DNS as an example for an IP mapping service 595 o Replaced draft-ietf-netconf-rfc5539bis with RFC7589 597 o Recharacterized this draft's relationship to RFC4253 599 A.10. 09 to 10 601 o Updates from AD review 603 A.11. 10 to 11 605 o Fixed typo introduced in -10 607 Appendix B. Open Issues 609 All issues with this draft are tracked using GitHub issues. Please 610 see: https://github.com/netconf-wg/call-home/issues to see currently 611 opened issues. 613 Author's Address 615 Kent Watsen 616 Juniper Networks 618 EMail: kwatsen@juniper.net