-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathdraft-ietf-netconf-http-client-server.xml
798 lines (745 loc) · 36.5 KB
/
draft-ietf-netconf-http-client-server.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
<?xml version="1.0" encoding="UTF-8"?>
<?rfc toc="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc linkmailto="no" ?>
<?rfc editing="no" ?>
<?rfc comments="yes" ?>
<?rfc inline="yes"?>
<?rfc rfcedstyle="yes"?>
<?rfc-ext allow-markup-in-artwork="yes" ?>
<?rfc-ext include-index="no" ?>
<!--<?rfc strict="no"?> -->
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
category="std"
consensus="true"
submissionType="IETF"
docName="draft-ietf-netconf-http-client-server-latest"
ipr="trust200902">
<front>
<title abbrev="Groupings for HTTP Clients and Servers">YANG Groupings for
HTTP Clients and HTTP Servers</title>
<author fullname="Kent Watsen" initials="K." surname="Watsen">
<organization>Watsen Networks</organization>
<address>
<email>[email protected]</email>
</address>
</author>
<date/>
<area>Operations</area>
<workgroup>NETCONF Working Group</workgroup>
<abstract>
<t>This document presents two YANG modules: the first defines a minimal
grouping for configuring an HTTP client, and the second defines
a minimal grouping for configuring an HTTP server. It is
intended that these groupings will be used to help define the
configuration for simple HTTP-based protocols (not for complete
web servers or browsers).</t>
</abstract>
<note title="Editorial Note (To be removed by RFC Editor)">
<t>This draft contains placeholder values that need to be replaced
with finalized values at the time of publication. This note summarizes
all of the substitutions that are needed. No other RFC Editor
instructions are specified elsewhere in this document.</t>
<t>Artwork in this document contains shorthand references to drafts in
progress. Please apply the following replacements (note: not all may be present):
<list style="symbols">
<t><spanx style="verb">AAAA</spanx> --> the assigned RFC value for draft-ietf-netconf-crypto-types</t>
<t><spanx style="verb">DDDD</spanx> --> the assigned RFC value for draft-ietf-netconf-tcp-client-server</t>
<t><spanx style="verb">FFFF</spanx> --> the assigned RFC value for draft-ietf-netconf-tls-client-server</t>
<t><spanx style="verb">GGGG</spanx> --> the assigned RFC value for this draft</t>
</list>
</t>
<t>Artwork in this document contains placeholder values for the date of
publication of this draft. Please apply the following replacement:
<list style="symbols">
<t><spanx style="verb">YYYY-MM-DD</spanx> --> the publication date of this draft</t>
</list>
</t>
<t>The "Relation to other RFCs" section <xref target="collective-effort"/> contains
the text "one or more YANG modules" and, later, "modules". This text is sourced
from a file in a context where it is unknown how many modules a draft defines.
The text is not wrong as is, but it may be improved by stating more directly how
many modules are defined.</t>
<t>The "Relation to other RFCs" section <xref target="collective-effort"/> contains
a self-reference to this draft, along with a corresponding reference in
the Appendix. Please replace the self-reference in this section with "This RFC"
(or similar) and remove the self-reference in the "Normative/Informative References"
section, whichever it is in.</t>
<t>Tree-diagrams in this draft may use the '\' line-folding mode defined in RFC 8792.
However, nicer-to-the-eye is when the '\\' line-folding mode is used. The AD suggested
suggested putting a request here for the RFC Editor to help convert "ugly" '\' folded
examples to use the '\\' folding mode. "Help convert" may be interpreted as, identify
what looks ugly and ask the authors to make the adjustment.</t>
<t>The following Appendix section is to be removed prior to publication:
<list style="symbols">
<t><xref target="change-log"/>. Change Log</t>
</list>
</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>This document presents two YANG 1.1 <xref target="RFC7950"/> modules: the first defines a minimal
grouping for configuring an HTTP client, and the second defines
a minimal grouping for configuring an HTTP server. It is
intended that these groupings will be used to help define the
configuration for simple HTTP-based protocols.</t>
INSERT_TEXT_FROM_FILE(../common-intro-snippet.xml,150)
<section title="Adherence to the NMDA">
<t>This document is compliant with the Network Management Datastore
Architecture (NMDA) <xref target="RFC8342"/>. For instance, as
described in <xref target="I-D.ietf-netconf-trust-anchors"/> and
<xref target="I-D.ietf-netconf-keystore"/>, trust anchors and keys
installed during manufacturing are expected to appear
in <operational> (<xref section="5.3" target="RFC8342"/>), and <system>
<xref target="I-D.ietf-netmod-system-config"/>, if implemented.</t>
</section>
</section>
<section anchor="http-client-model" title="The "ietf-http-client" Module">
<t>This section defines a YANG 1.1 module called
"ietf-http-client". A high-level overview of the module is provided in
<xref target="client-overview"/>. Examples illustrating the module's use
are provided in <xref target="client-examples"/>. The YANG
module itself is defined in <xref target="client-yang-module"/>.</t>
<section title="Data Model Overview" anchor="client-overview">
<t>This section provides an overview of the "ietf-http-client" module
in terms of its features and groupings.</t>
<section title="Features" anchor="client-features" toc="exclude">
<t>The following diagram lists all the "feature" statements
defined in the "ietf-http-client" module:</t>
<t>
<figure>
<artwork><![CDATA[
Features:
+-- tls-supported
+-- http-11-supported
+-- http-2-supported
+-- http-3-supported
+-- proxy-connect
]]></artwork>
</figure>
</t>
<!--<aside>-->
<t>The diagram above uses syntax that is similar to but not
defined in <xref target="RFC8340"/>.</t>
<!--</aside>-->
</section>
<section title="Groupings" toc="exclude">
<t>The "ietf-http-client" module defines the following "grouping" statements:</t>
<ul spacing="compact">
<li>http-client-common-grouping</li>
<li>http-client-grouping</li>
</ul>
<t>These groupings are presented in the following subsections.</t>
<section title="The "http-client-common-grouping" Grouping" anchor="http-client-common-grouping">
<t>The following tree diagram <xref target="RFC8340"/> illustrates the
"http-client-common-grouping" grouping:</t>
<t>
<figure>
<artwork><![CDATA[
INSERT_TEXT_FROM_FILE(refs/tree-http-client-common-grouping.no-expand.txt)
]]></artwork>
</figure>
</t>
<t>Comments:</t>
<ul>
<li>The "http-client-common-grouping" grouping defines a mandatory "uri" leaf.
Unlike other "client" groupings in the suite a "client-server"
drafts mentioned in <xref target="collective-effort"/>, this client
grouping encodes configuration for most of the protocol stack. For instance,
the "scheme", "userinfo", "host" and "port" parts of the URI syntax
encode information that portains to transport layers.</li>
<li>The "http-client-common-grouping" grouping defines an optional
protocol-versions leaf, enabling a client to specify which HTTP
protocol versions it is willing to use. When unspecified, the
default is for the HTTP client can use any version.</li>
<li>The "http-client-common-grouping" defines an optional "tls-client-parameters"
container, enabling trust anchors and client certificates to be
configured, for server that enable the "tls-supported" feature.
When unspecified, TLS-based connections are not possible.</li>
<li>For the referenced grouping statement(s):
<ul spacing="compact">
<li>The "tls-client-grouping" grouping is discussed in
<relref section="3.1.2.1" target="I-D.ietf-netconf-tls-client-server"/>.</li>
</ul>
</li>
</ul>
</section>
<section title="The "http-client-grouping" Grouping" anchor="http-client-grouping">
<t>The following tree diagram <xref target="RFC8340"/> illustrates the
"http-client-grouping" grouping:</t>
<t>
<figure>
<artwork><![CDATA[
INSERT_TEXT_FROM_FILE(refs/tree-http-client-grouping.no-expand.txt)
]]></artwork>
</figure>
</t>
<t>Comments:</t>
<ul>
<li>The "http-client-grouping" defines an optional "proxy-connect" container,
enabling connections through proxies, for servers that enable the
"proxy-connect" feature.</li>
<li>For the referenced grouping statement(s):
<ul spacing="compact">
<li>The "http-client-common-grouping" grouping is discussed in
<xref target="http-client-common-grouping"/> in this document.</li>
</ul>
</li>
</ul>
</section>
</section>
<section title="Protocol-accessible Nodes" toc="exclude">
<t>The "ietf-http-client" module defines only "grouping" statements that are
used by other modules to instantiate protocol-accessible nodes. Thus this
module, when implemented, does not define any protocol-accessible nodes.</t>
</section>
</section>
<section title="Example Usage" anchor="client-examples">
<t>This section presents three examples showing the http-client-grouping
populated with some data.</t>
<t>The first example illustrates the case where the HTTP client
is configured to connect directly to an HTTP server without TLS.</t>
<t>
<figure>
<artwork><![CDATA[
INSERT_TEXT_FROM_FILE(refs/ex-http-client-tcp.xml)
]]></artwork>
</figure>
</t>
<t>The second example illustrates the case where the HTTP client
is configured to connect directly to an HTTP server with TLS.</t>
<t>This example is consistent with examples presented in
<relref section="2.2.1" target="I-D.ietf-netconf-trust-anchors"/> and
<relref section="2.2.1" target="I-D.ietf-netconf-keystore"/>.</t>
<t>
<figure>
<artwork><![CDATA[
INSERT_TEXT_FROM_FILE(refs/ex-http-client-tls.xml)
]]></artwork>
</figure>
</t>
<t>The following example illustrates the case where the HTTP client
is configured to connect through an HTTP proxy.</t>
<t>This example also is consistent with examples presented in
<relref section="2.2.1" target="I-D.ietf-netconf-trust-anchors"/> and
<relref section="2.2.1" target="I-D.ietf-netconf-keystore"/>.</t>
<t>
<figure>
<artwork><![CDATA[
INSERT_TEXT_FROM_FILE(refs/ex-http-client-proxy.xml)
]]></artwork>
</figure>
</t>
</section>
<section anchor="client-yang-module" title="YANG Module">
<t>This YANG module has references to <xref target="RFC3986"/>,
<xref target="RFC6991"/>, <xref target="RFC8341"/>, <xref target="RFC9110"/>,
and <xref target="I-D.ietf-netconf-tls-client-server"/>.</t>
<t>
<figure>
<preamble><CODE BEGINS> file "[email protected]"</preamble>
<artwork><![CDATA[
INSERT_TEXT_FROM_FILE([email protected])
]]></artwork>
<postamble><CODE ENDS></postamble>
</figure>
</t>
</section>
</section>
<section anchor="http-server-model" title="The "ietf-http-server" Module">
<t>This section defines a YANG 1.1 module called
"ietf-http-server". A high-level overview of the module is provided in
<xref target="server-overview"/>. Examples illustrating the module's use
are provided in <xref target="server-examples"/>. The YANG
module itself is defined in <xref target="server-yang-module"/>.</t>
<section title="Data Model Overview" anchor="server-overview">
<t>This section provides an overview of the "ietf-http-server" module
in terms of its features and groupings.</t>
<section title="Features" anchor="server-features" toc="exclude">
<t>The following diagram lists all the "feature" statements
defined in the "ietf-http-server" module:</t>
<t>
<figure>
<artwork><![CDATA[
Features:
+-- client-auth-supported
+-- local-users-supported
+-- basic-auth
+-- tcp-supported
+-- tls-supported
+-- quic-supported
]]></artwork>
</figure>
</t>
<!--<aside>-->
<t>The diagram above uses syntax that is similar to but not
defined in <xref target="RFC8340"/>.</t>
<!--</aside>-->
</section>
<section title="Groupings" toc="exclude">
<t>The "ietf-http-server" module defines the following "grouping" statements:</t>
<ul spacing="compact">
<li>http-server-grouping</li>
<li>http-server-stack-grouping</li>
</ul>
<t>Each of these groupings are presented in the following subsections.</t>
<section title="The "http-server-grouping" Grouping" anchor="http-server-grouping">
<t>The following tree diagram <xref target="RFC8340"/> illustrates the
"http-server-grouping" grouping:</t>
<t>
<figure>
<artwork><![CDATA[
INSERT_TEXT_FROM_FILE(refs/tree-http-server-grouping.no-expand.txt)
]]></artwork>
</figure>
</t>
<t>Comments:</t>
<ul>
<li>The "http-server-grouping" defines the configuration for just the
"HTTP" part of a protocol stack. It does not, for instance,
define any configuration for the "TCP" or "TLS" protocol layers
(for that, see <xref target="http-server-stack-grouping"/>).</li>
<li>The "server-name" node defines the HTTP server's name, as
presented to HTTP clients.</li>
<li>The "client-authentication" node, which must by enabled by
a feature, defines a very simple user-database. Only the
"basic" authentication scheme is supported, albeit it must
be enabled by a "feature". Other authentication schemes
MAY be augmented in.</li>
</ul>
</section>
<section title="The "http-server-stack-grouping" Grouping" anchor="http-server-stack-grouping">
<t>The following tree diagram <xref target="RFC8340"/> illustrates the
"http-server-stack-grouping" grouping:</t>
<t>
<figure>
<artwork><![CDATA[
INSERT_TEXT_FROM_FILE(refs/tree-http-server-stack-grouping.no-expand.txt)
]]></artwork>
</figure>
</t>
<t>Comments:</t>
<ul>
<li>The "http-server-stack-grouping" is a convenience grouping for consuming
modules. It defines protocol stacks for HTTP/1.1, HTTP/2, and HTTP/3, with each
option enabled by a "feature" statement for application control. Other
protocols may be added by future work using the YANG "augment" statement.</li>
<li>For the referenced grouping statement(s):
<ul spacing="compact">
<li>The "udp-server-grouping" grouping is discussed in
<relref section="3" target="I-D.ietf-netconf-udp-client-server"/>.</li>
<li>The "tcp-server-grouping" grouping is discussed in
<relref section="4.1.2.1" target="I-D.ietf-netconf-tcp-client-server"/>.</li>
<li>The "tls-server-grouping" grouping is discussed in
<relref section="4.1.2.1" target="I-D.ietf-netconf-tls-client-server"/>.</li>
<li>The "http-server-grouping" grouping is discussed in
<xref target="http-server-grouping"/> in this document.</li>
</ul>
</li>
</ul>
</section>
</section>
<section title="Protocol-accessible Nodes" toc="exclude">
<t>The "ietf-http-server" module defines only "grouping" statements that are
used by other modules to instantiate protocol-accessible nodes. Thus this
module, when implemented, does not define any protocol-accessible nodes.</t>
</section>
</section>
<section title="Example Usage" anchor="server-examples">
<t>This section presents an example showing the http-server-grouping
populated with some data.</t>
<t>
<figure>
<artwork><![CDATA[
INSERT_TEXT_FROM_FILE(refs/ex-http-server.xml)
]]></artwork>
</figure></t>
</section>
<section anchor="server-yang-module" title="YANG Module">
<t>This YANG module has references to <xref target="RFC6991"/>,
<xref target="RFC7317"/>, <xref target="RFC7617"/>, <xref target="RFC8341"/>,
<xref target="RFC9110"/>, <xref target="I-D.ietf-netconf-tcp-client-server"/>,
<xref target="I-D.ietf-netconf-tls-client-server"/>, and
<xref target="I-D.ietf-netconf-udp-client-server"/>.</t>
<t>
<figure>
<preamble><CODE BEGINS> file "[email protected]"</preamble>
<artwork><![CDATA[
INSERT_TEXT_FROM_FILE([email protected])
]]></artwork>
<postamble><CODE ENDS></postamble>
</figure>
</t>
</section>
</section>
<section title="Security Considerations">
<t>The two YANG modules in this document define groupings and will
not be deployed as standalone modules. Their security implications
may be context dependent based on their use in other modules. The
designers of modules which import these grouping must conduct their
own analysis of the security considerations.</t>
<section title="Considerations for the "ietf-http-client" YANG Module">
<t>This section follows the template defined in <xref section="3.7.1" target="RFC8407"/>.</t>
<t>The "ietf-http-client" YANG module defines "grouping" statements
that are designed to be accessed via YANG based management
protocols, such as NETCONF <xref target="RFC6241"/> and RESTCONF
<xref target="RFC8040"/>. Both of these protocols have
mandatory-to-implement secure transport layers (e.g., SSH, TLS)
with mutual authentication.</t>
<t>The Network Access Control Model (NACM) <xref target="RFC8341"/>
provides the means to restrict access for particular users to a
pre-configured subset of all available protocol operations and
content.</t>
<t>Please be aware that this YANG module uses groupings from
other YANG modules that define nodes that may be considered
sensitive or vulnerable in network environments. Please
review the Security Considerations for dependent YANG modules
for information as to which nodes may be considered sensitive
or vulnerable in network environments.</t>
<t>Some of the readable data nodes defined in this YANG module,
i.e., excluding imported modules, may be considered sensitive
or vulnerable in some network environments. It is thus important
to control read access to these data nodes. The following data
nodes have particular sensitivity/vulnerability:
<list style="symbols">
<t>The "uri" node:
<ul empty="true">
<li>The "uri" node may encode a cleartext password (basic
or digest authentication). For this reason, the NACM
extension "default-deny-all" was applied to it.</li>
</ul>
</t>
<t>The "proxy-connect/uri" node:
<ul empty="true">
<li>The "proxy-connect/uri" node may encode a cleartext password (basic
or digest authentication). For this reason, the NACM
extension "default-deny-all" was applied to it.</li>
</ul>
</t>
</list>
</t>
<t>The follwing writable data nodes defined in this YANG module, i.e.,
excluding imported modules, are considered sensitive or vulnerable
in network environments:
<list style="symbols">
<t>The "proxy-connect" node in the "http-client-grouping"
grouping may be considered sensitive or vulnerable in some
network environments. For this reason, the NACM extension
"default-deny-all" has been applied to it. A misconfigured
"proxy-connect" node may result in loss of connectivity
or, perhaps, unexpectedly elevated authorization.</t>
</list>
</t>
<t>This module does not define any RPCs, actions, or notifications,
and thus the security consideration for such is not provided here.</t>
</section>
<section title="Considerations for the "ietf-http-server" YANG Module">
<t>This section follows the template defined in <xref section="3.7.1" target="RFC8407"/>.</t>
<t>The "ietf-http-server" YANG module defines "grouping" statements
that are designed to be accessed via YANG based management
protocols, such as NETCONF <xref target="RFC6241"/> and RESTCONF
<xref target="RFC8040"/>. Both of these protocols have
mandatory-to-implement secure transport layers (e.g., SSH, TLS)
with mutual authentication.</t>
<t>The Network Access Control Model (NACM) <xref target="RFC8341"/>
provides the means to restrict access for particular users to a
pre-configured subset of all available protocol operations and
content.</t>
<t>Please be aware that this YANG module uses groupings from
other YANG modules that define nodes that may be considered
sensitive or vulnerable in network environments. Please
review the Security Considerations for dependent YANG modules
for information as to which nodes may be considered sensitive
or vulnerable in network environments.</t>
<t>None of the readable data nodes defined in this YANG module,
i.e., excluding imported modules, are
considered sensitive or vulnerable in network environments.
The NACM "default-deny-all" extension has not been set for
any data nodes defined in this module.</t>
<t>The follwing writable data nodes defined in this YANG module,
i.e., excluding imported modules, are considered sensitive or
vulnerable in network environments:
<list style="symbols">
<t>The "server-name" node in the "http-server-grouping"
grouping may be considered sensitive or vulnerable in some
network environments. For this reason, the NACM extension
"default-deny-write" has been applied to it. A misconfigured
"server-name" may mislead clients into not knowing how to
interoperate with the server (e.g., "foo v1.0" vs "foo 2.0").</t>
<t>The "client-authentication" node in the "http-server-grouping"
grouping may be considered sensitive or vulnerable in some
network environments. For this reason, the NACM extension
"default-deny-write" has been applied to it. The feature
"tls-supported" is not required, in order to support
cases where an external device is used to terminate TLS
connections, but such arrangements leave the client-
credentials to be unprotected by the transport. Misconfigured
"client-authentication" may lead the server to authenticate
invalid client credentials.</t>
</list>
</t>
<t>This module does not define any RPCs, actions, or notifications,
and thus the security consideration for such is not provided here.</t>
</section>
</section>
<section title="IANA Considerations">
<section title='The "IETF XML" Registry'>
<t>This document registers two URIs in the "ns" subregistry of the
IETF XML Registry <xref target="RFC3688"/>. Following the format in
<xref target="RFC3688"/>, the following registrations are
requested:</t>
<t><figure>
<artwork>
URI: urn:ietf:params:xml:ns:yang:ietf-http-client
Registrant Contact: The IESG
XML: N/A, the requested URI is an XML namespace.
URI: urn:ietf:params:xml:ns:yang:ietf-http-server
Registrant Contact: The IESG
XML: N/A, the requested URI is an XML namespace.
</artwork>
</figure></t>
</section>
<section title='The "YANG Module Names" Registry'>
<t>This document registers two YANG modules in the YANG Module Names
registry <xref target="RFC6020"/>. Following the format in <xref
target="RFC6020"/>, the following registrations are requested:</t>
<t><figure>
<artwork>
name: ietf-http-client
namespace: urn:ietf:params:xml:ns:yang:ietf-http-client
prefix: httpc
reference: RFC GGGG
name: ietf-http-server
namespace: urn:ietf:params:xml:ns:yang:ietf-http-server
prefix: https
reference: RFC GGGG
</artwork>
</figure></t>
</section>
</section>
</middle>
<back>
<references title="Normative References">
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6020.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6991.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7317.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7617.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7950.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8341.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-netconf-crypto-types.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-netconf-tcp-client-server.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-netconf-tls-client-server.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-netconf-udp-client-server.xml"/>
</references>
<references title="Informative References">
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3688.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3986.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6241.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8040.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8340.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8342.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8407.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-netconf-trust-anchors.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-netconf-keystore.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-netconf-ssh-client-server.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-netconf-http-client-server.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-netconf-netconf-client-server.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-netconf-restconf-client-server.xml"/>
<xi:include href="https://datatracker.ietf.org/doc/bibxml3/reference.I-D.ietf-netmod-system-config.xml"/>
</references>
<section title="Change Log" anchor="change-log">
<section title="00 to 01">
<t>
<list style="symbols">
<t>Modified Abstract and Intro to be more accurate wrt intended applicability.</t>
<t>In ietf-http-client, removed "protocol-version" and all auth schemes except "basic".</t>
<t>In ietf-http-client, factored out "client-identity-grouping" for proxy connections.</t>
<t>In ietf-http-server, removed "choice required-or-optional" and "choice inline-or-external".</t>
<t>In ietf-http-server, moved the basic auth under a "choice auth-type" limited by new "feature basic-auth".</t>
</list>
</t>
</section>
<section title="01 to 02">
<t>
<list style="symbols">
<t>Removed the unused "external-client-auth-supported" feature from ietf-http-server.</t>
</list>
</t>
</section>
<section title="02 to 03">
<t>
<list style="symbols">
<t>Removed "protocol-versions" from ietf-http-server based on HTTP WG feedback.</t>
<t>Slightly restructured the "proxy-server" definition in ietf-http-client.</t>
<t>Added http-client example show proxy server use.</t>
<t>Added a "Note to Reviewers" note to first page.</t>
</list>
</t>
</section>
<section title="03 to 04">
<t>
<list style="symbols">
<t>Added a parent "container" to "client-identity-grouping" so that it could be
better used by the proxy model.</t>
<t>Added a "choice" to the proxy model enabling selection of proxy types.</t>
<t>Added 'http-client-stack-grouping' and 'http-server-stack-grouping' convenience groupings.</t>
<t>Expanded "Data Model Overview section(s) [remove "wall" of tree diagrams].</t>
<t>Updated the Security Considerations section.</t>
</list>
</t>
</section>
<section title="04 to 05">
<t>
<list style="symbols">
<t>Fixed titles and a ref in the IANA Considerations section</t>
<t>Cleaned up examples (e.g., removed FIXMEs)</t>
<t>Fixed issues found by the SecDir review of the "keystore" draft.</t>
<t>Updated the "ietf-http-client" module to use the new "password-grouping"
grouping from the "crypto-types" module.</t>
</list>
</t>
</section>
<section title="05 to 06">
<t>
<list style="symbols">
<t>Removed note questioning if okay for app to augment-in a 'path' node
when needed, discussed during the 108 session.</t>
<t>Addressed comments raised by YANG Doctor in the ct/ts/ks drafts.</t>
</list>
</t>
</section>
<section title="06 to 07">
<t>
<list style="symbols">
<t>Added XML-comment above examples explaining the reason for the unusual top-most element's presence.</t>
<t>Renamed 'client-auth-config-supported' to 'client-auth-supported' consistent with other drafts.</t>
<t>Wrapped 'container basic' choice inside a 'case basic' per best practice.</t>
<t>Aligned modules with `pyang -f` formatting.</t>
<t>Fixed nits found by YANG Doctor reviews.</t>
</list>
</t>
</section>
<section title="07 to 08">
<t>
<list style="symbols">
<t>Replaced "base64encodedvalue==" with "BASE64VALUE=" in examples.</t>
<t>Minor editorial nits</t>
</list>
</t>
</section>
<section title="08 to 09">
<t>
<list style="symbols">
<t>Fixed up the 'WG Web' and 'WG List' lines in YANG module(s)</t>
<t>Fixed up copyright (i.e., s/Simplified/Revised/) in YANG module(s)</t>
</list>
</t>
</section>
<section title="09 to 10">
<t>
<list style="symbols">
<t>NO UPDATE.</t>
</list>
</t>
</section>
<section title="10 to 11">
<t>
<list style="symbols">
<t>Updated per Shepherd reviews impacting the suite of drafts.</t>
</list>
</t>
</section>
<section title="11 to 12">
<t>
<list style="symbols">
<t>Updated per Shepherd reviews impacting the suite of drafts.</t>
</list>
</t>
</section>
<section title="12 to 13">
<t>
<list style="symbols">
<t>Updated per Tom Petch reviews.</t>
<t>Renamed draft title to limit to HTTP 1.1 and 2.0.</t>
<t>Added refs to RFCs 7317, 7617, and 9110.</t>
<t>Added "if-feature local-users-supported" to "feature basic-auth".</t>
</list>
</t>
</section>
<section title="13 to 14">
<t>
<list style="symbols">
<t>Addresses AD review comments.</t>
<t>Added note to Editor to fix line foldings.</t>
<t>Removed "Conventions" section as there are no "BASE64VALUE=" values used in draft.</t>
<t>Clarified that the modules, when implemented, do not define any protocol-accessible nodes.</t>
<t>Added Security Considerations text to also look a SC-section from imported modules.</t>
<t>Removed "A wrapper around the foobar parameters to avoid name collisions" text.</t>
<t>Removed "public-key-format" and "public-key" nodes from examples.</t>
</list>
</t>
</section>
<section title="14 to 15">
<t>
<list style="symbols">
<t>Addresses AD review by Rob Wilton.</t>
</list>
</t>
</section>
<section title="15 to 16">
<t>
<list style="symbols">
<t>Addresses 1st-round of IESG reviews.</t>
</list>
</t>
</section>
<section title="16 to 18">
<t>
<list style="symbols">
<t>Addresses issues found in OpsDir review of the ssh-client-server draft.</t>
<t>s/defines/presents/ in a few places.</t>
<t>Add refs to where the 'operational' and 'system' datastores are defined.</t>
<t>Renamed Security Considerations section s/Template for/Considerations for/.</t>
<t>Updated "http-client-stack-grouping" and "http-server-stack-grouping" for HTTP/3.</t>
</list>
</t>
</section>
<section title="18 to 19">
<t>
<list style="symbols">
<t>Address IESG review comments.</t>
</list>
</t>
</section>
<section title="19 to 20">
<t>
<list style="symbols">
<t>Updated to reflect comments from Paul Wouters.</t>
</list>
</t>
</section>
</section>
<section title="Acknowledgements" numbered="no">
<t>The authors would like to thank the following for lively discussions
on list and in the halls (ordered by first name):
Ben Schwartz,
Éric Vyncke,
Mark Nottingham,
Mahesh Jethanandani,
Murray Kucherawy,
Orie Steele,
Rob Wilton,
Roman Danyliw,
Shivan Sahib,
and Willy Tarreau.
</t>
</section>
</back>
</rfc>