idnits 2.17.1 draft-ietf-netconf-call-home-10.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 3132 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-10 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 drafts 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 Appendix B. Open Issues . . . . . . . . . . . . . . . . . . . . 13 117 1. Introduction 119 This RFC presents NETCONF Call Home and RESTCONF Call Home, which 120 enable a NETCONF or RESTCONF server to initiate a secure connection 121 to a NETCONF or RESTCONF client respectively. 123 NETCONF Call Home supports both of the secure transports used by the 124 NETCONF protocol [RFC6241], SSH and TLS. The NETCONF protocol's 125 binding to SSH is defined in [RFC6242]. The NETCONF protocol's 126 binding to TLS is defined in [RFC7589]. 128 RESTCONF Call Home only supports TLS, the same as the RESTCONF 129 protocol [draft-ietf-netconf-restconf]. The RESTCONF protocol's 130 binding to TLS is defined in [draft-ietf-netconf-restconf]. 132 The SSH protocol is defined in [RFC4253]. The TLS protocol is 133 defined in [RFC5246]. Both the SSH and TLS protocols are layered on 134 top of the TCP protocol, which is defined in [RFC793]. 136 Both NETCONF Call Home and RESTCONF Call Home preserve all but one of 137 the client/server roles in their respective protocol stacks, as 138 compared to client-initiated NETCONF and RESTCONF connections. The 139 one and only role reversal that occurs is at the TCP layer; that is, 140 which peer is the TCP-client and which is the TCP-server. 142 For example, a network element is traditionally the TCP-server. 143 However, when calling home, the network element becomes the TCP- 144 client. The network element's secure transport layer roles (SSH- 145 server, TLS-server) and its application layer roles (NETCONF-server, 146 RESTCONF-server) both remain the same. 148 Having consistency in both the secure transport layer (SSH, TLS) and 149 application layer (NETCONF, RESTCONF) roles conveniently enables 150 deployed network management infrastructure to support call home also. 151 For instance, existing certificate chains and user authentication 152 mechanisms are unaffected by call home. 154 1.1. Motivation 156 Call home is generally useful for both the initial deployment and on- 157 going management of networking elements. Here are some scenarios 158 enabled by call home: 160 o The network element may proactively call home after being powered 161 on for the first time in order to register itself with its 162 management system. 164 o The network element may access the network in a way that 165 dynamically assigns it an IP address, but does not register its 166 assigned IP address to a mapping service (e.g., dynamic DNS). 168 o The network element may be deployed behind a firewall that 169 implements network address translation (NAT) for all internal 170 network IP addresses. 172 o The network element may be deployed behind a firewall that doesn't 173 allow any management access to the internal network. 175 o The network element may be configured in "stealth mode" and thus 176 doesn't have any open ports for the management system to connect 177 to. 179 o The operator may prefer to have network elements initiate 180 management connections, believing it is easier to secure one open 181 port in the data center than to have an open port on each network 182 element in the network. 184 1.2. Requirements Terminology 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in RFC 2119 [RFC2119]. 190 1.3. Applicability Statement 192 The techniques described in this document are suitable for network 193 management scenarios such as the ones described in Section 1.1. 194 However, these techniques are only defined for NETCONF Call Home and 195 RESTCONF Call Home, as described in this document. 197 The reason for this restriction is that different protocols have 198 different security assumptions. The NETCONF and RESTCONF protocols 199 require clients and servers to verify the identity of the other 200 party. This requirement is specified for the NETCONF protocol in 201 Section 2.2 of [RFC6241], and is specified for the RESTCONF protocol 202 in Sections 2.4 and 2.5 of [draft-ietf-netconf-restconf]). 204 This contrasts with the base SSH and TLS protocols, which do not 205 require programmatic verification of the other party (section 9.3.4 206 of [RFC4251], section 4 of [RFC4252], and section 7.3 of [RFC5246]). 207 In such circumstances, allowing the SSH/TLS server to contact the 208 SSH/TLS client would open new vulnerabilities. Any use of call home 209 with SSH/TLS for purposes other than NETCONF or RESTCONF will need a 210 thorough, contextual security analysis. 212 1.4. Relation to RFC 4253 214 This document uses the SSH Transport Layer Protocol [RFC4253] with 215 the exception that the statement "The client initiates the 216 connection" made in Section 4 (Connection Setup) does not apply. 217 Assuming the reference to client means "SSH client" and the reference 218 to connection means "TCP connection", this statement doesn't hold 219 true in call home, where the network element is the SSH server and 220 yet still initiates the TCP connection. Security implications 221 related to this change are discussed in Security Considerations 222 (Section 4). 224 1.5. The NETCONF/RESTCONF Convention 226 Throughout the remainder of this document, the term "NETCONF/ 227 RESTCONF" is used as an abbreviation in place of the text "the 228 NETCONF or the RESTCONF". The NETCONF/RESTCONF abbreviation is not 229 intended to require or to imply that a client or server must 230 implement both the NETCONF standard and the RESTCONF standard. 232 2. The NETCONF or RESTCONF Client 234 The term "NETCONF/RESTCONF client" can refer to the [RFC6241], 235 Section 1.1 "client". 237 2.1. Protocol Operation 239 C1 The NETCONF/RESTCONF client listens for TCP connection requests 240 from NETCONF/RESTCONF servers. The client SHOULD listen for 241 connections on the IANA-assigned ports defined in section 242 Section 5, but MAY be configured to use a non-standard port. 244 C2 The NETCONF/RESTCONF client accepts an incoming TCP connection 245 request and a TCP connection is established. 247 C3 Using this TCP connection, the NETCONF/RESTCONF client MUST 248 immediately start either the SSH-client [RFC4253] or the TLS- 249 client [RFC5246] protocol. For example, assuming the use of the 250 IANA-assigned ports, the SSH-client protocol is started when the 251 connection is accepted on port PORT-X and the TLS-client protocol 252 is started when the connection is accepted on either port PORT-Y 253 or PORT-Z. 255 C4 If using TLS, the NETCONF/RESTCONF client MUST advertise 256 "peer_allowed_to_send", as defined by [RFC6520]. This is 257 required so NETCONF/RESTCONF servers can depend on it being there 258 for call home connections, when keep-alives are needed the most. 260 C5 As part of establishing an SSH or TLS connection, the NETCONF/ 261 RESTCONF client MUST validate the server's presented host key or 262 certificate. This validation MAY be accomplished by certificate 263 path validation or by comparing the host key or certificate to a 264 previously trusted or "pinned" value. 266 C6 If certificate path validation is used, the NETCONF/RESTCONF 267 client MUST ensure that the certificate has a valid chain of 268 trust to a preconfigured trust anchor and that the certificate 269 encodes an "identifier" [RFC6125] that the client had awareness 270 of prior to the connection attempt. How identifiers are encoded 271 in certificates MAY be determined by a policy associated with the 272 certificate's trust anchor. For instance, a given trust anchor 273 may be known to only sign IDevID certificates [Std-802.1AR-2009] 274 having a unique identifier (e.g., serial number) in the X.509 275 certificate's "CommonName" field. 277 C7 After the server's host key or certificate is validated, the SSH 278 or TLS protocol proceeds as normal to establish a SSH or TLS 279 connection. 281 C8 Once the SSH or TLS connection is established, the NETCONF/ 282 RESTCONF client MUST immediately start using either the NETCONF- 283 client [RFC6241] or RESTCONF-client [draft-ietf-netconf-restconf] 284 protocol. Assuming the use of the IANA-assigned ports, the 285 NETCONF-client protocol is started when the connection is 286 accepted on either port PORT-X or PORT-Y and the RESTCONF-client 287 protocol is started when the connection is accepted on port PORT- 288 Z. 290 2.2. Configuration Data Model 292 How a NETCONF or RESTCONF client is configured is outside the scope 293 of this document. This includes configuration that might be used to 294 enable listening for call home connections, configuring trust 295 anchors, or configuring identifiers for expected connections. 297 3. The NETCONF or RESTCONF Server 299 The term "NETCONF/RESTCONF server" can refer to the [RFC6241], 300 Section 1.1 "server". 302 3.1. Protocol Operation 304 S1 The NETCONF/RESTCONF server initiates a TCP connection request to 305 the NETCONF/RESTCONF client. The server SHOULD connect to one of 306 the IANA-assigned ports defined in section Section 5, but MAY be 307 configured to use a non-standard port. Using the IANA-assigned 308 ports, the server connects to port PORT-X for NETCONF over SSH, 309 port PORT-Y for NETCONF over TLS, and port PORT-Z for RESTCONF 310 over TLS. 312 S2 The TCP connection request is accepted and a TCP connection is 313 established. 315 S3 Using this TCP connection, the NETCONF/RESTCONF server MUST 316 immediately start using either the SSH-server [RFC4253] or the 317 TLS-server [RFC5246] protocol, depending on how it is configured. 318 For example, assuming the use of the IANA-assigned ports, the 319 SSH-server protocol is used after connecting to the remote port 320 PORT-X and the TLS-server protocol is used after connecting to 321 one of the remote ports PORT-Y or PORT-Z. 323 S4 As part of establishing the SSH or TLS connection, the NETCONF/ 324 RESTCONF server will send its host key or certificate to the 325 client. If a certificate is sent, the server MUST also send all 326 intermediate certificates leading up to the certificate's trust 327 anchor. How to send a list of certificates is defined for SSH in 328 [RFC6187] Section 2.1, and for TLS in [RFC5246] Section 7.4.2. 330 S5 In most cases, establishing the SSH or TLS connection also 331 entails server authentication of client credentials; only with 332 RESTCONF do some client authentication schemes occur after the 333 secure transport connection (TLS) has been established. If 334 client authentication is required, and the client is unable to 335 successfully authenticate itself to the server in an amount of 336 time defined by local policy, the server MUST close the 337 connection. 339 S6 Once the SSH or TLS connection is established, the NETCONF/ 340 RESTCONF server MUST immediately start using either the NETCONF- 341 server [RFC6241] or RESTCONF-server [draft-ietf-netconf-restconf] 342 protocol, depending on how it is configured. Assuming the use of 343 the IANA-assigned ports, the NETCONF-server protocol is used 344 after connecting to remote port PORT-X or PORT-Y, and the 345 RESTCONF-server protocol is used after connecting to remote port 346 PORT-Z. 348 S7 If a persistent connection is desired, the NETCONF/RESTCONF 349 server, as the connection initiator, SHOULD actively test the 350 aliveness of the connection using a keep-alive mechanism. For 351 TLS based connections, the NETCONF/RESTCONF server SHOULD send 352 HeartbeatRequest messages, as defined by [RFC6520]. For SSH 353 based connections, per section 4 of [RFC4254], the NETCONF/ 354 RESTCONF server SHOULD send a SSH_MSG_GLOBAL_REQUEST message with 355 the purposely nonexistent "request name" value 356 "keepalive@ietf.org" and the "want reply" value set to '1'. 358 3.2. Configuration Data Model 360 How a NETCONF or RESTCONF server is configured is outside the scope 361 of this document. This includes configuration that might be used to 362 specify hostnames, IP addresses, ports, algorithms, or other relevant 363 parameters. That said, a YANG [RFC6020] model for configuring 364 NETCONF and RESTCONF servers, including call home, is provided in 365 [draft-ietf-netconf-server-model]. 367 4. Security Considerations 369 The security considerations described in [RFC6242] and [RFC7589], and 370 by extension [RFC4253], [RFC5246], and [draft-ietf-netconf-restconf] 371 apply here as well. 373 This RFC deviates from standard SSH and TLS usage by having the SSH/ 374 TLS server initiate the underlying TCP connection. This reversal is 375 incongruous with [RFC4253], which says "the client initiates the 376 connection" and also [RFC6125], which says "the client MUST construct 377 a list of acceptable reference identifiers, and MUST do so 378 independently of the identifiers presented by the service." To 379 account for these variances, this RFC requires that the NETCONF/ 380 RESTCONF client validate the SSH host key or certificate via 381 certificate path validation to a preconfigured trust anchor or by 382 comparing the host key or certificate to a previously trusted or 383 "pinned" value. Furthermore, if certificate path validation is used, 384 this RFC requires that the client be able to match a presented 385 identifier encoded in the certificate with an identifier the client 386 was preconfigured to expect. 388 An attacker could launch a denial of service (DoS) attack on the 389 NETCONF/RESTCONF client by having it perform computationally 390 expensive operations, before deducing that the attacker doesn't 391 posses a valid key. This is no different than any secured service 392 and all common precautions apply (e.g., blacklisting the source 393 address after a set number of unsuccessful login attempts). 395 5. IANA Considerations 397 This RFC requests that IANA assigns three TCP port numbers in the 398 "Registered Port Numbers" range with the service names "netconf-ch- 399 ssh", "netconf-ch-tls", and "restconf-ch-tls". These ports will be 400 the default ports for NETCONF Call Home and RESTCONF Call Home 401 protocols. Below is the registration template following the rules in 402 [RFC6335]. 404 Service Name: netconf-ch-ssh 405 Transport Protocol(s): TCP 406 Assignee: IESG 407 Contact: IETF Chair 408 Description: NETCONF Call Home (SSH) 409 Reference: RFC XXXX 410 Port Number: PORT-X 412 Service Name: netconf-ch-tls 413 Transport Protocol(s): TCP 414 Assignee: IESG 415 Contact: IETF Chair 416 Description: NETCONF Call Home (TLS) 417 Reference: RFC XXXX 418 Port Number: PORT-Y 420 Service Name: restconf-ch-tls 421 Transport Protocol(s): TCP 422 Assignee: IESG 423 Contact: IETF Chair 424 Description: RESTCONF Call Home (TLS) 425 Reference: RFC XXXX 426 Port Number: PORT-Z 428 6. Acknowledgements 430 The author would like to thank the following for lively discussions 431 on list and in the halls (ordered by last name): Andy Bierman, Martin 432 Bjorklund, Mehmet Ersue, Wes Hardaker, Stephen Hanna, David 433 Harrington, Jeffrey Hutzelman, Radek Krejci, Alan Luchuk, Mouse, Russ 434 Mundy, Tom Petch, Juergen Schoenwaelder, Peter Saint-Andre, Joe 435 Touch, Hannes Tschofenig, Sean Turner, and Bert Wijnen. 437 7. References 439 7.1. Normative References 441 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 442 Requirement Levels", BCP 14, RFC 2119, March 1997. 444 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 445 Protocol Architecture", RFC 4251, January 2006. 447 [RFC4252] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 448 Authentication Protocol", RFC 4252, January 2006. 450 [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 451 Transport Layer Protocol", RFC 4253, January 2006. 453 [RFC4254] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 454 Connection Protocol", RFC 4254, January 2006. 456 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 457 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 459 [RFC6125] Saint-Andre, P. and J. Hodges, "Representation and 460 Verification of Domain-Based Application Service Identity 461 within Internet Public Key Infrastructure Using X.509 462 (PKIX) Certificates in the Context of Transport Layer 463 Security (TLS)", RFC 6125, March 2011. 465 [RFC6187] Igoe, K. and D. Stebila, "X.509v3 Certificates for Secure 466 Shell Authentication", RFC 6187, March 2011. 468 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 469 Bierman, "Network Configuration Protocol (NETCONF)", RFC 470 6241, June 2011. 472 [RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure 473 Shell (SSH)", RFC 6242, June 2011. 475 [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. 476 Cheshire, "Internet Assigned Numbers Authority (IANA) 477 Procedures for the Management of the Service Name and 478 Transport Protocol Port Number Registry", BCP 165, RFC 479 6335, August 2011. 481 [RFC6520] Seggelmann, R., Tuexen, M., and M. Williams, "Transport 482 Layer Security (TLS) and Datagram Transport Layer Security 483 (DTLS) Heartbeat Extension", RFC 6520, February 2012. 485 [RFC7589] Badra, M., Luchuk, A., and J. Schoenwaelder, "Using the 486 NETCONF Protocol over Transport Layer Security (TLS) with 487 Mutual X.509 Authentication", RFC 7589, June 2015. 489 [RFC793] Postel, J., "TRANSMISSION CONTROL PROTOCOL", STD 7, 490 September 1981, . 492 [draft-ietf-netconf-restconf] 493 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 494 Protocol", draft-ieft-netconf-restconf-04 (work in 495 progress), 2014, . 498 7.2. Informative References 500 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 501 Network Configuration Protocol (NETCONF)", RFC 6020, 502 October 2010. 504 [Std-802.1AR-2009] 505 IEEE SA-Standards Board, "IEEE Standard for Local and 506 metropolitan area networks - Secure Device Identity", 507 December 2009, . 510 [draft-ietf-netconf-server-model] 511 Watsen, K. and J. Schoenwaelder, "NETCONF Server 512 Configuration Model", 2014, . 515 Appendix A. Change Log 517 A.1. 00 to 01 519 o The term "TCP connection" is now used throughout. 521 o The terms "network element" and "management system" are now only 522 used in the Motivation section. 524 o Restructured doc a little to create an Introduction section. 526 o Fixed reference in Applicability Statement so it would work 527 equally well for SSH and TLS. 529 o Fixed reported odd wording and three references. 531 A.2. 01 to 02 533 o Added call home support for the RESTCONF protocol. 535 o Fixed paragraph 3 of Security Considerations to equally apply to 536 the TLS protocol. 538 A.3. 02 to 03 540 o Tried to improve readability (issue #6) 542 o Removed "FIXME" in section 1.3 (issue #7) 544 o Added RFC Editor notes (issue #8) 546 o Removed "TCP session" term (issue #9) 548 o Improved language for usage of IANA-assigned ports (issue #10) 550 A.4. 03 to 04 552 o Replaced "verify credentials" with "verify identity" (issue #11) 554 A.5. 04 to 05 556 o Applied many suggestions from WGLC 558 o Removed essay like "Server Identification and Verification" 559 section 561 o Added text about keep-alives 562 o Added Configuration Data Model section for client protocol 564 o Improved Security Considerations section 566 A.6. 05 to 06 568 o Addressed comments raised by Alan Luchuk. 570 A.7. 06 to 07 572 o replaced "reference identifier" with "identifier" 574 o added reference to RFC6125 576 o moved reference to 6020 to Informative section 578 A.8. 07 to 08 580 o Added text regarding client authentication 582 o Now says client-initiated (not standard) NETCONF/RESTCONF 583 connections 585 o Now says server must send all (not any) intermediate certificates 587 o Improved wording based on suggestions from Jonathan and Tom 589 A.9. 08 to 09 591 o Added dynamic DNS as an example for an IP mapping service 593 o Replaced draft-ietf-netconf-rfc5539bis with RFC7589 595 o Recharacterized this draft's relationship to RFC4253 597 Appendix B. Open Issues 599 All issues with this draft are tracked using GitHub issues. Please 600 see: https://github.com/netconf-wg/call-home/issues to see currently 601 opened issues. 603 Author's Address 605 Kent Watsen 606 Juniper Networks 608 EMail: kwatsen@juniper.net