idnits 2.17.1 draft-ietf-netconf-http-client-server-03.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 ([2], [3], [4], [5], [6], [7], [8], [9], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 199 has weird spacing: '...assword str...' == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (May 20, 2020) is 1435 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) -- Looks like a reference, but probably isn't: '1' on line 797 -- Looks like a reference, but probably isn't: '2' on line 799 -- Looks like a reference, but probably isn't: '3' on line 801 -- Looks like a reference, but probably isn't: '4' on line 803 -- Looks like a reference, but probably isn't: '5' on line 805 -- Looks like a reference, but probably isn't: '6' on line 807 -- Looks like a reference, but probably isn't: '7' on line 809 -- Looks like a reference, but probably isn't: '8' on line 811 -- Looks like a reference, but probably isn't: '9' on line 814 == Outdated reference: A later version (-35) exists of draft-ietf-netconf-keystore-16 == Outdated reference: A later version (-28) exists of draft-ietf-netconf-trust-anchors-09 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETCONF Working Group K. Watsen 3 Internet-Draft Watsen Networks 4 Intended status: Standards Track May 20, 2020 5 Expires: November 21, 2020 7 YANG Groupings for HTTP Clients and HTTP Servers 8 draft-ietf-netconf-http-client-server-03 10 Abstract 12 This document defines two YANG modules: the first defines a minimal 13 grouping for configuring an HTTP client, and the second defines a 14 minimal grouping for configuring an HTTP server. It is intended that 15 these groupings will be used to help define the configuration for 16 simple HTTP-based protocols (not for complete web servers or 17 browsers). 19 Editorial Note (To be removed by RFC Editor) 21 This draft contains placeholder values that need to be replaced with 22 finalized values at the time of publication. This note summarizes 23 all of the substitutions that are needed. No other RFC Editor 24 instructions are specified elsewhere in this document. 26 Artwork in this document contains shorthand references to drafts in 27 progress. Please apply the following replacements (note: not all may 28 be present): 30 o "AAAA" --> the assigned RFC value for draft-ietf-netconf-crypto- 31 types 33 o "BBBB" --> the assigned RFC value for draft-ietf-netconf-trust- 34 anchors 36 o "CCCC" --> the assigned RFC value for draft-ietf-netconf-keystore 38 o "DDDD" --> the assigned RFC value for draft-ietf-netconf-tcp- 39 client-server 41 o "EEEE" --> the assigned RFC value for draft-ietf-netconf-ssh- 42 client-server 44 o "FFFF" --> the assigned RFC value for draft-ietf-netconf-tls- 45 client-server 47 o "GGGG" --> the assigned RFC value for this draft 48 Artwork in this document contains placeholder values for the date of 49 publication of this draft. Please apply the following replacement: 51 o "2020-05-20" --> the publication date of this draft 53 The following Appendix section is to be removed prior to publication: 55 o Appendix A. Change Log 57 Note to Reviewers (To be removed by RFC Editor) 59 This document presents a YANG module or modules that is/are part of a 60 collection of drafts that work together to produce the ultimate goal 61 of the NETCONF WG: to define configuration modules for NETCONF client 62 and servers, and RESTCONF client and servers. 64 The relationship between the various drafts in the collection is 65 presented in the below diagram. 67 crypto-types 68 ^ ^ 69 / \ 70 / \ 71 trust-anchors keystore 72 ^ ^ ^ ^ 73 | +---------+ | | 74 | | | | 75 | +------------+ | 76 tcp-client-server | / | | 77 ^ ^ ssh-client-server | | 78 | | ^ tls-client-server 79 | | | ^ ^ http-client-server 80 | | | | | ^ 81 | | | +-----+ +---------+ | 82 | | | | | | 83 | +-----------|--------|--------------+ | | 84 | | | | | | 85 +-----------+ | | | | | 86 | | | | | | 87 | | | | | | 88 netconf-client-server restconf-client-server 90 Full draft names and link to drafts: 92 o draft-ietf-netconf-crypto-types (html [1]) 94 o draft-ietf-netconf-trust-anchors (html [2]) 95 o draft-ietf-netconf-keystore (html [3]) 97 o draft-ietf-netconf-tcp-client-server (html [4]) 99 o draft-ietf-netconf-ssh-client-server (html [5]) 101 o draft-ietf-netconf-tls-client-server (html [6]) 103 o draft-ietf-netconf-http-client-server (html [7]) 105 o draft-ietf-netconf-netconf-client-server (html [8]) 107 o draft-ietf-netconf-restconf-client-server (html [9]) 109 Status of This Memo 111 This Internet-Draft is submitted in full conformance with the 112 provisions of BCP 78 and BCP 79. 114 Internet-Drafts are working documents of the Internet Engineering 115 Task Force (IETF). Note that other groups may also distribute 116 working documents as Internet-Drafts. The list of current Internet- 117 Drafts is at https://datatracker.ietf.org/drafts/current/. 119 Internet-Drafts are draft documents valid for a maximum of six months 120 and may be updated, replaced, or obsoleted by other documents at any 121 time. It is inappropriate to use Internet-Drafts as reference 122 material or to cite them other than as "work in progress." 124 This Internet-Draft will expire on November 21, 2020. 126 Copyright Notice 128 Copyright (c) 2020 IETF Trust and the persons identified as the 129 document authors. All rights reserved. 131 This document is subject to BCP 78 and the IETF Trust's Legal 132 Provisions Relating to IETF Documents 133 (https://trustee.ietf.org/license-info) in effect on the date of 134 publication of this document. Please review these documents 135 carefully, as they describe your rights and restrictions with respect 136 to this document. Code Components extracted from this document must 137 include Simplified BSD License text as described in Section 4.e of 138 the Trust Legal Provisions and are provided without warranty as 139 described in the Simplified BSD License. 141 Table of Contents 143 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 144 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 145 3. The HTTP Client Model . . . . . . . . . . . . . . . . . . . . 5 146 3.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 5 147 3.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 5 148 3.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 7 149 4. The HTTP Server Model . . . . . . . . . . . . . . . . . . . . 10 150 4.1. Tree Diagram . . . . . . . . . . . . . . . . . . . . . . 10 151 4.2. Example Usage . . . . . . . . . . . . . . . . . . . . . . 11 152 4.3. YANG Module . . . . . . . . . . . . . . . . . . . . . . . 11 153 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 154 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 155 6.1. The IETF XML Registry . . . . . . . . . . . . . . . . . . 15 156 6.2. The YANG Module Names Registry . . . . . . . . . . . . . 16 157 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 158 7.1. Normative References . . . . . . . . . . . . . . . . . . 16 159 7.2. Informative References . . . . . . . . . . . . . . . . . 17 160 7.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 161 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 19 162 A.1. 00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 19 163 A.2. 01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 19 164 A.3. 02 to 03 . . . . . . . . . . . . . . . . . . . . . . . . 19 165 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19 166 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 168 1. Introduction 170 This document defines two YANG 1.1 [RFC7950] modules: the first 171 defines a minimal grouping for configuring an HTTP client, and the 172 second defines a minimal grouping for configuring an HTTP server. It 173 is intended that these groupings will be used to help define the 174 configuration for simple HTTP-based protocols (not for complete web 175 servers or browsers). 177 2. Terminology 179 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 180 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 181 "OPTIONAL" in this document are to be interpreted as described in BCP 182 14 [RFC2119] [RFC8174] when, and only when, they appear in all 183 capitals, as shown here. 185 3. The HTTP Client Model 187 3.1. Tree Diagram 189 This section provides a tree diagram [RFC8340] for the "ietf-http- 190 client" module. 192 module: ietf-http-client 194 grouping client-identity-grouping 195 +-- (auth-type)? 196 +--:(basic) 197 +-- basic {basic-auth}? 198 +-- user-id string 199 +-- password string 200 grouping http-client-grouping 201 +-- client-identity! 202 | +---u client-identity-grouping 203 +-- proxy-server! {proxy-connect}? 204 +-- tcp-client-parameters 205 | +---u tcpc:tcp-client-grouping 206 +-- tls-client-parameters 207 | +---u tlsc:tls-client-grouping 208 +-- http-client-parameters 209 +-- client-identity! 210 +---u client-identity-grouping 212 3.2. Example Usage 214 This section presents two examples showing the http-client-grouping 215 populated with some data. 217 The following example illustrates an HTTP client connecting directly 218 to an HTTP server. 220 221 222 223 bob 224 secret 225 226 227 229 The following example illustrates the same client connecting through 230 an HTTP proxy. This example is consistent with examples presented in 231 Section 2 of [I-D.ietf-netconf-trust-anchors] and Section 3.2 of 232 [I-D.ietf-netconf-keystore]. 234 ========== NOTE: '\' line wrapping per BCP XXX (RFC XXXX) =========== 236 237 238 239 bob 240 secret 241 242 243 244 245 corp-fw2.example.com 246 247 15 248 3 249 30 250 251 252 253 254 255 256 rsa-asymmetric-key 257 ex-rsa-cert 258 259 260 261 262 263 trusted-server-ca-certs 265 266 267 trusted-server-ee-certs 269 270 271 272 273 274 275 local-app-1 276 secret 277 278 279 280 281 283 3.3. YANG Module 285 This YANG module has normative references to [RFC6991]. 287 file "ietf-http-client@2020-05-20.yang" 289 module ietf-http-client { 290 yang-version 1.1; 291 namespace "urn:ietf:params:xml:ns:yang:ietf-http-client"; 292 prefix httpc; 294 import ietf-netconf-acm { 295 prefix nacm; 296 reference 297 "RFC 8341: Network Configuration Access Control Model"; 298 } 300 import ietf-tcp-client { 301 prefix tcpc; 302 reference 303 "RFC AAAA: YANG Groupings for TCP Clients and TCP Servers"; 304 } 306 import ietf-tls-client { 307 prefix tlsc; 308 reference 309 "RFC BBBB: YANG Groupings for TLS Clients and TLS Servers"; 310 } 312 organization 313 "IETF NETCONF (Network Configuration) Working Group"; 315 contact 316 "WG Web: 317 WG List: 318 Author: Kent Watsen "; 320 description 321 "This module defines reusable groupings for HTTP clients that 322 can be used as a basis for specific HTTP client instances. 324 Copyright (c) 2020 IETF Trust and the persons identified 325 as authors of the code. All rights reserved. 327 Redistribution and use in source and binary forms, with 328 or without modification, is permitted pursuant to, and 329 subject to the license terms contained in, the Simplified 330 BSD License set forth in Section 4.c of the IETF Trust's 331 Legal Provisions Relating to IETF Documents 332 (https://trustee.ietf.org/license-info). 334 This version of this YANG module is part of RFC GGGG 335 (https://www.rfc-editor.org/info/rfcGGGG); see the RFC 336 itself for full legal notices. 338 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 339 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 340 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 341 are to be interpreted as described in BCP 14 (RFC 2119) 342 (RFC 8174) when, and only when, they appear in all 343 capitals, as shown here."; 345 revision 2020-05-20 { 346 description 347 "Initial version"; 348 reference 349 "RFC GGGG: YANG Groupings for HTTP Clients and HTTP Servers"; 350 } 352 // Features 354 feature proxy-connect { 355 description 356 "Proxy connection configuration is configurable for 357 HTTP clients on the server implementing this feature."; 358 } 360 feature basic-auth { 361 description 362 "The 'basic-auth' feature indicates that the client 363 may be configured to use the 'basic' HTTP authentication 364 scheme."; 365 reference 366 "RFC 7617: The 'Basic' HTTP Authentication Scheme"; 367 } 369 // Groupings 371 grouping client-identity-grouping { 372 description 373 "The credentials used by the client to authenticate 374 itself to the HTTP server."; 375 choice auth-type { 376 nacm:default-deny-write; 377 description 378 "The authentication type."; 380 case basic { 381 container basic { 382 if-feature "basic-auth"; 383 leaf user-id { 384 type string; 385 mandatory true; 386 description 387 "The user-id for the authenticating client."; 388 } 389 leaf password { 390 nacm:default-deny-all; 391 type string; 392 mandatory true; 393 description 394 "The password for the authenticating client."; 395 } 396 description 397 "The 'basic' HTTP scheme credentials."; 398 reference 399 "RFC 7617: The 'Basic' HTTP Authentication Scheme"; 400 } 401 } 402 } 403 } // grouping client-identity-grouping 405 grouping http-client-grouping { 406 description 407 "A reusable grouping for configuring a HTTP client, 408 including the IP address and port number it initiates 409 a connections to. 411 Note that this grouping uses fairly typical descendent 412 node names such that a stack of 'uses' statements will 413 have name conflicts. It is intended that the consuming 414 data model will resolve the issue (e.g., by wrapping 415 the 'uses' statement in a container called 416 'http-client-parameters'). This model purposely does 417 not do this itself so as to provide maximum flexibility 418 to consuming models."; 420 container client-identity { 421 presence 422 "Indicates that HTTP-level client authenticate is sent."; 423 description 424 "The identity the HTTP client should use when 425 authenticating itself to the HTTP server."; 426 uses client-identity-grouping; 427 } 428 container proxy-server { 429 nacm:default-deny-write; 430 if-feature "proxy-connect"; 431 presence true; // only so ex-http-client can pass validation? 432 container tcp-client-parameters { 433 description 434 "A wrapper around the TCP parameters to avoid 435 name collisions."; 436 uses "tcpc:tcp-client-grouping"; 437 } 438 container tls-client-parameters { 439 description 440 "A wrapper around the TLS parameters to avoid 441 name collisions."; 442 uses "tlsc:tls-client-grouping"; 443 } 444 container http-client-parameters { 445 description 446 "A wrapper around the HTTP parameters to avoid 447 name collisions."; 448 container client-identity { 449 presence 450 "Indicates that HTTP-level client authenticate is sent."; 451 description 452 "The identity the HTTP client should use when 453 authenticating itself to the HTTP server."; 454 uses client-identity-grouping; 455 } 456 } 457 description 458 "Proxy server settings."; 459 } 460 } // grouping http-client-grouping 462 } // module ietf-http-client 464 466 4. The HTTP Server Model 468 4.1. Tree Diagram 470 This section provides a tree diagram [RFC8340] for the "ietf-http- 471 server" module. 473 module: ietf-http-server 475 grouping http-server-grouping 476 +-- server-name? string 477 +-- client-authentication! {client-auth-config-supported}? 478 +-- users 479 +-- user* [user-id] 480 +-- user-id? string 481 +-- (auth-type)? 482 +--:(basic) 483 +-- basic {basic-auth}? 484 +-- user-id? string 485 +-- password? ianach:crypt-hash 487 4.2. Example Usage 489 This section presents an example showing the http-server-grouping 490 populated with some data. 492 493 foo.example.com 494 496 4.3. YANG Module 498 This YANG module has normative references to [RFC6991]. 500 file "ietf-http-server@2020-05-20.yang" 502 module ietf-http-server { 503 yang-version 1.1; 504 namespace "urn:ietf:params:xml:ns:yang:ietf-http-server"; 505 prefix https; 507 import iana-crypt-hash { 508 prefix ianach; 509 reference 510 "RFC 7317: A YANG Data Model for System Management"; 511 } 513 import ietf-netconf-acm { 514 prefix nacm; 515 reference 516 "RFC 8341: Network Configuration Access Control Model"; 517 } 519 organization 520 "IETF NETCONF (Network Configuration) Working Group"; 522 contact 523 "WG Web: 524 WG List: 525 Author: Kent Watsen "; 527 description 528 "This module defines reusable groupings for HTTP servers that 529 can be used as a basis for specific HTTP server instances. 531 Copyright (c) 2020 IETF Trust and the persons identified 532 as authors of the code. All rights reserved. 534 Redistribution and use in source and binary forms, with 535 or without modification, is permitted pursuant to, and 536 subject to the license terms contained in, the Simplified 537 BSD License set forth in Section 4.c of the IETF Trust's 538 Legal Provisions Relating to IETF Documents 539 (https://trustee.ietf.org/license-info). 541 This version of this YANG module is part of RFC GGGG 542 (https://www.rfc-editor.org/info/rfcGGGG); see the RFC 543 itself for full legal notices. 545 The key words 'MUST', 'MUST NOT', 'REQUIRED', 'SHALL', 546 'SHALL NOT', 'SHOULD', 'SHOULD NOT', 'RECOMMENDED', 547 'NOT RECOMMENDED', 'MAY', and 'OPTIONAL' in this document 548 are to be interpreted as described in BCP 14 (RFC 2119) 549 (RFC 8174) when, and only when, they appear in all 550 capitals, as shown here."; 552 revision 2020-05-20 { 553 description 554 "Initial version"; 555 reference 556 "RFC GGGG: YANG Groupings for HTTP Clients and HTTP Servers"; 557 } 559 // Features 561 feature client-auth-config-supported { 562 description 563 "Indicates that the configuration for how to authenticate 564 clients can be configured herein, as opposed to in an 565 application specific location. That is, to support the 566 consuming data models that prefer to place client 567 authentication with client definitions, rather then 568 in a data model principally concerned with configuring 569 the transport."; 571 } 573 feature basic-auth { 574 description 575 "The 'basic-auth' feature indicates that the server 576 may be configured authenticate users using the 'basic' 577 HTTP authentication scheme."; 578 reference 579 "RFC 7617: The 'Basic' HTTP Authentication Scheme"; 580 } 582 // Groupings 584 grouping http-server-grouping { 585 description 586 "A reusable grouping for configuring an HTTP server. 588 Note that this grouping uses fairly typical descendent 589 node names such that a stack of 'uses' statements will 590 have name conflicts. It is intended that the consuming 591 data model will resolve the issue (e.g., by wrapping 592 the 'uses' statement in a container called 593 'http-server-parameters'). This model purposely does 594 not do this itself so as to provide maximum flexibility 595 to consuming models."; 597 leaf server-name { 598 nacm:default-deny-write; 599 type string; 600 description 601 "The value of the 'Server' header field. If not set, then 602 underlying software's default value is used. Set to the 603 empty string to disable."; 604 } 606 container client-authentication { 607 if-feature "client-auth-config-supported"; 608 nacm:default-deny-write; 609 presence 610 "Indicates that HTTP based client authentication is 611 supported (i.e., the server will request that the 612 HTTP client send authenticate when needed). This 613 is needed as some HTTP-based protocols may only 614 support, e.g., TLS-level client authentication."; 615 description 616 "Specifies how the HTTP server can authenticate HTTP 617 clients."; 619 container users { 620 description 621 "A list of locally configured users."; 622 list user { 623 key user-id; 624 description 625 "The list of local users configured on this device."; 626 leaf user-id { 627 type string; 628 description 629 "The user-id for the authenticating client."; 630 } 631 choice auth-type { 632 description 633 "The authentication type."; 634 container basic { 635 if-feature "basic-auth"; 636 leaf user-id { 637 type string; 638 description 639 "The user-id for the authenticating client."; 640 } 641 leaf password { 642 nacm:default-deny-write; 643 type ianach:crypt-hash; 644 description 645 "The password for the authenticating client."; 646 } 647 description 648 "The 'basic' HTTP scheme credentials."; 649 reference 650 "RFC 7617: 651 The 'Basic' HTTP Authentication Scheme"; 652 } 653 } 654 } 655 } 656 } // container client-authentication 657 } // grouping http-server-grouping 658 } 660 662 5. Security Considerations 664 The YANG modules defined in this document are designed to be accessed 665 via YANG based management protocols, such as NETCONF [RFC6241] and 666 RESTCONF [RFC8040]. Both of these protocols have mandatory-to- 667 implement secure transport layers (e.g., SSH, HTTP) with mutual 668 authentication. 670 The NETCONF access control model (NACM) [RFC8341] provides the means 671 to restrict access for particular users to a pre-configured subset of 672 all available protocol operations and content. 674 Since the modules defined in this document only define groupings, 675 these considerations are primarily for the designers of other modules 676 that use these groupings. 678 There are a number of data nodes defined in the YANG modules that are 679 writable/creatable/deletable (i.e., config true, which is the 680 default). These data nodes may be considered sensitive or vulnerable 681 in some network environments. Write operations (e.g., edit-config) 682 to these data nodes without proper protection can have a negative 683 effect on network operations. These are the subtrees and data nodes 684 and their sensitivity/vulnerability: 686 FIXME: (pending - TBD) 688 Some of the readable data nodes in the YANG modules may be considered 689 sensitive or vulnerable in some network environments. It is thus 690 important to control read access (e.g., via get, get-config, or 691 notification) to these data nodes. These are the subtrees and data 692 nodes and their sensitivity/vulnerability: 694 FIXME: (pending client auth params?) 696 Some of the RPC operations in this YANG module may be considered 697 sensitive or vulnerable in some network environments. It is thus 698 important to control access to these operations. These are the 699 operations and their sensitivity/vulnerability: 701 The modules defined in this document do not define any 'RPC' or 702 'action' statements. 704 6. IANA Considerations 706 6.1. The IETF XML Registry 708 This document registers two URIs in the "ns" subregistry of the IETF 709 XML Registry [RFC3688]. Following the format in [RFC3688], the 710 following registrations are requested: 712 URI: urn:ietf:params:xml:ns:yang:ietf-http-client 713 Registrant Contact: The NETCONF WG of the IETF. 714 XML: N/A, the requested URI is an XML namespace. 716 URI: urn:ietf:params:xml:ns:yang:ietf-http-server 717 Registrant Contact: The NETCONF WG of the IETF. 718 XML: N/A, the requested URI is an XML namespace. 720 6.2. The YANG Module Names Registry 722 This document registers two YANG modules in the YANG Module Names 723 registry [RFC6020]. Following the format in [RFC6020], the following 724 registrations are requested: 726 name: ietf-http-client 727 namespace: urn:ietf:params:xml:ns:yang:ietf-http-client 728 prefix: httpc 729 reference: RFC XXXX 731 name: ietf-http-server 732 namespace: urn:ietf:params:xml:ns:yang:ietf-http-server 733 prefix: https 734 reference: RFC XXXX 736 7. References 738 7.1. Normative References 740 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 741 Requirement Levels", BCP 14, RFC 2119, 742 DOI 10.17487/RFC2119, March 1997, 743 . 745 [RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for 746 the Network Configuration Protocol (NETCONF)", RFC 6020, 747 DOI 10.17487/RFC6020, October 2010, 748 . 750 [RFC6991] Schoenwaelder, J., Ed., "Common YANG Data Types", 751 RFC 6991, DOI 10.17487/RFC6991, July 2013, 752 . 754 [RFC7950] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language", 755 RFC 7950, DOI 10.17487/RFC7950, August 2016, 756 . 758 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 759 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 760 May 2017, . 762 [RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration 763 Access Control Model", STD 91, RFC 8341, 764 DOI 10.17487/RFC8341, March 2018, 765 . 767 7.2. Informative References 769 [I-D.ietf-netconf-keystore] 770 Watsen, K., "A YANG Data Model for a Keystore", draft- 771 ietf-netconf-keystore-16 (work in progress), March 2020. 773 [I-D.ietf-netconf-trust-anchors] 774 Watsen, K., "A YANG Data Model for a Truststore", draft- 775 ietf-netconf-trust-anchors-09 (work in progress), March 776 2020. 778 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 779 DOI 10.17487/RFC3688, January 2004, 780 . 782 [RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed., 783 and A. Bierman, Ed., "Network Configuration Protocol 784 (NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011, 785 . 787 [RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 788 Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017, 789 . 791 [RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams", 792 BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018, 793 . 795 7.3. URIs 797 [1] https://tools.ietf.org/html/draft-ietf-netconf-crypto-types 799 [2] https://tools.ietf.org/html/draft-ietf-netconf-trust-anchors 801 [3] https://tools.ietf.org/html/draft-ietf-netconf-keystore 803 [4] https://tools.ietf.org/html/draft-ietf-netconf-tcp-client-server 805 [5] https://tools.ietf.org/html/draft-ietf-netconf-ssh-client-server 807 [6] https://tools.ietf.org/html/draft-ietf-netconf-tls-client-server 809 [7] https://tools.ietf.org/html/draft-ietf-netconf-http-client-server 811 [8] https://tools.ietf.org/html/draft-ietf-netconf-netconf-client- 812 server 814 [9] https://tools.ietf.org/html/draft-ietf-netconf-restconf-client- 815 server 817 Appendix A. Change Log 819 A.1. 00 to 01 821 o Modified Abstract and Intro to be more accurate wrt intended 822 applicability. 824 o In ietf-http-client, removed "protocol-version" and all auth 825 schemes except "basic". 827 o In ietf-http-client, factored out "client-identity-grouping" for 828 proxy connections. 830 o In ietf-http-server, removed "choice required-or-optional" and 831 "choice local-or-external". 833 o In ietf-http-server, moved the basic auth under a "choice auth- 834 type" limited by new "feature basic-auth". 836 A.2. 01 to 02 838 o Removed the unused "external-client-auth-supported" feature from 839 ietf-http-server. 841 A.3. 02 to 03 843 o Removed "protocol-versions" from ietf-http-server based on HTTP WG 844 feedback. 846 o Slightly restructured the "proxy-server" definition in ietf-http- 847 client. 849 o Added http-client example show proxy server use. 851 o Added a "Note to Reviewers" note to first page. 853 Acknowledgements 855 The authors would like to thank for following for lively discussions 856 on list and in the halls (ordered by last name): Mark Nottingham, Ben 857 Schwartz, and Willy Tarreau. 859 Author's Address 861 Kent Watsen 862 Watsen Networks 864 EMail: kent+ietf@watsen.net