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