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