-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathdraft-netana-netconf-yp-transport-capabilities-01.xml
624 lines (515 loc) · 21.7 KB
/
draft-netana-netconf-yp-transport-capabilities-01.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
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2697 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2697.xml">
<!ENTITY RFC2698 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2698.xml">
<!ENTITY RFC6020 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6020.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc tocompact="yes"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-netana-netconf-yp-transport-capabilities-01"
ipr="trust200902">
<front>
<title abbrev="YANG Notification Transport Capabilities">YANG Notification Transport Capabilities</title>
<author fullname="Qin Wu" initials="Q." surname="Wu">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Qiufang Ma" initials="Q." surname="Ma">
<organization>Huawei</organization>
<address>
<postal>
<street>101 Software Avenue, Yuhua District</street>
<city>Nanjing</city>
<region>Jiangsu</region>
<code>210012</code>
<country>China</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Alex Huang Feng" initials="A." surname="Huang Feng">
<organization>INSA-Lyon</organization>
<address>
<postal>
<street/>
<city>Lyon</city>
<region/>
<code/>
<country>France</country>
</postal>
<phone/>
<facsimile/>
<email>[email protected]</email>
<uri/>
</address>
</author>
<author fullname="Thomas Graf" initials="T" surname="Graf">
<organization>Swisscom</organization>
<address>
<postal>
<street>Binzring 17</street>
<city>Zurich</city>
<code>8045</code>
<country>Switzerland</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<date day="17" month="January" year="2025"/>
<area>OPS Area</area>
<workgroup>NETCONF Working Group</workgroup>
<abstract>
<t>This document specifies a YANG module for YANG notifications transport
capabilities which augments "ietf-system-capabilities" YANG module
defined in <xref target="RFC9196"/>. The module provides transport,
encoding, and encryption system capabilities for transport-specific
notification. This YANG module can be used by the client to learn
capability information from the server at runtime or at implementation
time, by making use of the YANG instance data file format.</t>
</abstract>
</front>
<middle>
<section anchor="intro" title="Introduction">
<t>The notification capabilities model
allows a client to discover a set of capabilities supported by a
server (e.g., basic system capabilities and YANG-Push related
capabilities) both at implementation time and at runtime. These
capabilities allow a client to adjust its behavior to take advantage
of the features exposed by the server.</t>
<t>However, clients and servers may still support various different
transport specific parameters (e.g., transport protocol, encoding
format or encryption). As described in <xref section="3.1"
sectionFormat="of" target="RFC8641"/>, a simple negotiation (e.g.,
inserting hints into error responses to a failed RPC request) between
subscribers and publishers for subscription parameters increases the
likelihood of success for subsequent RPC requests, but not guaranteed,
which may cause unexpected failure or additional message exchange
between client and server.</t>
<t>This document defines a more deterministic solution that relies
upon a YANG module for YANG notifications transport capabilities that
is built on top of <xref target="RFC9196"/>. The module can be used by
a client to discover capability information from a server at runtime
or at implementation time, by making use of the YANG instance data file
format.</t>
<section title="Terminology">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.</t>
<t>The terms "subscriber", "publisher", and "receiver" are used as
defined in <xref target="RFC8639"/>.</t>
<t>The terms "client", and "server" are used as defined in <xref
target="RFC8342"/>.</t>
</section>
</section>
<!-- intro -->
<section title="Capabilities for Systems and Datastore Update Notifications">
<t><xref section="3.1"
sectionFormat="of" target="RFC8641"/> lists the server capabilities related
to YANG-Push that are supported in the YANG module
"ietf-notification-capabilities".</t>
<t>These server capabilities are transport independent, session level
capabilities. They can be provided either at the implementation time or
reported at runtime.</t>
<t>This document provides
additional transport related attributes associated with system
capabilities:<list style="symbols">
<t>Specification of transport protocols that a client can request to
establish an HTTPS-based <xref
target="I-D.ietf-netconf-https-notif"/> or UDP-based <xref
target="I-D.ietf-netconf-udp-notif"/> configured transport
connection.</t>
<t>Specification of transport encoding, such as JSON or XML as
defined in <xref target="RFC8040"/> or CBOR as defined in <xref
target="RFC9254"/> the client can request to encode YANG
notifications;</t>
<t>Specification of secure transport mechanisms that are needed by
a client to communicate with a server such as DTLS 1.2
<xref target="RFC6347"/>, DTLS 1.3 <xref target="RFC9147"/>, TLS 1.2
<xref target="RFC5246"/>, TLS 1.3 <xref target="RFC8446"/>, or SSH
<xref target="RFC4254"/>.</t>
<t>To that aim, the model defined in this document augments the System
Capabilities model<xref target="RFC9196"/>.</t>
</list></t>
<section title="Tree Diagram">
<t>The following tree diagram <xref target="RFC8340"/> provides an
overview of the data model.</t>
<sourcecode type="yangtree"><![CDATA[
module: ietf-notification-transport-capabilities
augment /sysc:system-capabilities/notc:subscription-capabilities:
+--ro transport-capabilities
+--ro transport-capability* [transport-protocol]
+--ro transport-protocol identityref
+--ro security-protocol? identityref
+--ro encoding-format* identityref
]]></sourcecode>
</section>
</section>
<section title="YANG Module">
<sourcecode type="yang" markers="true" name="[email protected]"><![CDATA[
module ietf-notification-transport-capabilities {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-notification-transport-capabilities";
prefix ntc;
import ietf-subscribed-notifications {
prefix sn;
reference
"RFC 8639: Subscription to YANG Notifications";
}
import ietf-system-capabilities {
prefix sysc;
reference
"RFC 9196: YANG Modules Describing Capabilities for
Systems and Datastore Update Notifications";
}
import ietf-notification-capabilities {
prefix notc;
reference
"RFC 9196: YANG Modules Describing Capabilities for
Systems and Datastore Update Notifications";
}
organization "IETF NETCONF (Network Configuration) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/group/netconf/>
WG List: <mailto:[email protected]>
Authors: Qin Wu
<mailto:[email protected]>
Qiufang Ma
<mailto:[email protected]>
Alex Huang Feng
<mailto:[email protected]>
Thomas Graf
<mailto:[email protected]>";
description
"This module defines an extension to YANG-Push
Notification Capabilities model that provides additional
transport specific capabilities for YANG notifications.
Copyright (c) 2024 IETF Trust and the persons identified as
authors of the code. All rights reserved.
Redistribution and use in source and binary forms, with or
without modification, is permitted pursuant to, and subject
to the license terms contained in, the Revised BSD License
set forth in Section 4.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(http://trustee.ietf.org/license-info).
This version of this YANG module is part of RFC XXXX;
see the RFC itself for full legal notices.";
revision 2025-01-05 {
description
"Initial revision.";
reference
"RFC XXXX: YANG Notifications Transport Capabilities";
}
identity security-protocol {
description
"Identity for security protocols.";
}
identity tls12 {
base security-protocol;
description
"Indicates TLS Protocol Version 1.2. TLS 1.2 is obsolete,
and thus it is NOT RECOMMENDED to enable this feature.";
reference
"RFC 5246: The Transport Layer Security (TLS) Protocol
Version 1.2";
}
identity tls13 {
base security-protocol;
description
"Indicates TLS Protocol Version 1.3.";
reference
"RFC 8446: The Transport Layer Security (TLS)
Protocol Version 1.3";
}
identity dtls12 {
base security-protocol;
description
"Indicates DTLS Protocol Version 1.2. TLS 1.2 is obsolete,
and thus it is NOT RECOMMENDED to enable this feature.";
reference
"RFC 6347: The Datagram Transport Layer Security (TLS) Protocol
Version 1.2";
}
identity dtls13 {
base security-protocol;
description
"Indicates DTLS Protocol Version 1.3.";
reference
"RFC 9147: The Datagram Transport Layer Security (TLS)
Protocol Version 1.3";
}
identity ssh {
base security-protocol;
description
"Indicates SSH.";
}
augment "/sysc:system-capabilities/notc:subscription-capabilities" {
description
"Adds system level capabilities.";
container transport-capabilities {
description
"Specifies capabilities related to YANG-Push transports.";
list transport-capability {
key "transport-protocol";
description
"Indicates a list of capabilities related to notification
transport.";
leaf transport-protocol {
type identityref {
base sn:transport;
}
description
"Indicates supported transport protocol for YANG-Push.";
}
leaf security-protocol {
type identityref {
base security-protocol;
}
description
"Indicates transport security protocol.";
}
leaf-list encoding-format {
type identityref {
base sn:encoding;
}
description
"Indicates supported encoding formats.";
}
}
}
}
}
]]></sourcecode>
</section>
<section title="IANA Considerations">
<section anchor="xml" title="Updates to the IETF XML Registry">
<t>This document registers a URI in the "IETF XML Registry" [RFC3688].
Following the format in [RFC3688], the following registration has been
made:</t>
<figure>
<artwork> URI:
urn:ietf:params:xml:ns:yang:ietf-notification-transport-capabilities
Registrant Contact:
The IESG.
XML:
N/A; the requested URI is an XML namespace.</artwork>
</figure>
</section>
<section anchor="module"
title="Updates to the YANG Module Names Registry">
<t>This document registers one YANG module in the "YANG Module Names"
registry [RFC6020]. Following the format in [RFC6020], the following
registration has been made:</t>
<figure>
<artwork> name:
ietf-notification-transport-capabilities
namespace:
urn:ietf:params:xml:ns:yang:ietf-notification-transport-capabilities
prefix:
ntc
reference:
RFC XXXX (RFC Ed.: replace XXX with actual RFC number and remove
this note.)</artwork>
</figure>
</section>
</section>
<section anchor="security" title="Security Considerations">
<t>This section is modeled after the template described in <xref
section="3.7" sectionFormat="of"
target="I-D.ietf-netmod-rfc8407bis"/></t>
<t>The "ietf-notification-transport-capabilities" YANG module defines a
data model that is designed to be accessed via YANG-based management
protocols, such as NETCONF <xref target="RFC6241"/> and RESTCONF <xref
target="RFC8040"/>. These protocols have to use a secure transport layer
(e.g., SSH <xref target="RFC4252"/>, TLS <xref target="RFC8446"/>, and
QUIC <xref target="RFC9000"/>) and have to use mutual
authentication.</t>
<t>The Network Configuration Access Control Model (NACM) <xref
target="RFC8341"/> provides the means to restrict access for particular
NETCONF or RESTCONF users to a preconfigured subset of all available
NETCONF or RESTCONF protocol operations and content.</t>
<t>All protocol-accessible data nodes are read-only and cannot be
modified. The data in the module is not security sensitive. It inherits
all the security considerations of <xref target="RFC9196"/>.</t>
</section>
<section title="Contributors">
<figure>
<artwork> Ran Tao
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: [email protected]
Liang Geng
China Mobile
32 Xuanwumen West St, Xicheng District
Beijing 10053
China
Email: [email protected]
Peng Liu
China Mobile
Beiqijia Town, Changping District
Beijing 10053
China
Email: [email protected]
Wei Wang
China Telecom
32 Xuanwumen West St, Xicheng District
Beijing 102209
China
Email: [email protected]</artwork>
</figure>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank Mohamed Boucadair
and Kent Watson for their review and valuable comments.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119.xml"?>
<?rfc include="reference.RFC.8174.xml"?>
<?rfc include="reference.RFC.4254.xml"?>
<?rfc include="reference.RFC.5246.xml"?>
<?rfc include="reference.RFC.6241.xml"?>
<?rfc include="reference.RFC.6242.xml"?>
<?rfc include="reference.RFC.6347.xml"?>
<?rfc include="reference.RFC.8040.xml"?>
<?rfc include="reference.RFC.8341.xml"?>
<?rfc include="reference.RFC.8342.xml"?>
<?rfc include="reference.RFC.8446.xml"?>
<?rfc include="reference.RFC.8639.xml"?>
<?rfc include="reference.RFC.8641.xml"?>
<?rfc include="reference.RFC.9147.xml"?>
<?rfc include="reference.RFC.9196.xml"?>
<?rfc include="reference.RFC.9254.xml"?>
</references>
<references title="Informative References">
<?rfc include="reference.RFC.3688.xml"?>
<?rfc include="reference.RFC.4252.xml"?>
<?rfc include="reference.RFC.6020.xml"?>
<?rfc include="reference.RFC.8340.xml"?>
<?rfc include="reference.RFC.9000.xml"?>
<?rfc include="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-netconf-udp-notif.xml"?>
<?rfc include="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-netconf-https-notif.xml"?>
<?rfc include="https://bib.ietf.org/public/rfc/bibxml-ids/reference.I-D.ietf-netmod-rfc8407bis.xml"?>
</references>
<section title="Usage Example of interaction with UDP-Notif and HTTPS-Notif for Configured Subscription">
<t>The following instance-data example describes the notification
transport capabilities of a hypothetical "acme-router".</t>
<figure>
<artwork><?xml version="1.0" encoding="UTF-8"?>
<instance-data-set xmlns=
"urn:ietf:params:xml:ns:yang:ietf-yang-instance-data">
<name>acme-router-notification-capabilities</name>
<content-schema>
<module>ietf-system-capabilities@2020-03-23</module>
<module>ietf-notification-capabilities@2020-03-23</module>
<module>ietf-notification-transport-capabilities@2024-10-14</module>
</content-schema>
<!-- revision date, contact, etc. -->
<description>Server Capability Discovery</description>
<content-data>
<system-capabilities xmlns="urn:ietf:params:xml:ns:yang:ietf-system\
-capabilities">
<subscription-capabilities xmlns="urn:ietf:params:xml:ns:yang:iet\
f-notification-capabilities">
<transport-capabilities xmlns="urn:ietf:params:xml:ns:yang:ietf\
-notification-transport-capabilities">
<transport-capability>
<transport-protocol xmlns:hnt="urn:ietf:params:xml:ns:yang:\
ietf-https-notif-transport">hnt:https</transport-protocol>
<encoding-format xmlns:sn="urn:ietf:params:xml:ns:yang:ietf\
-subscribed-notifications">sn:encode-xml</encoding-format>
<encoding-format xmlns:sn="urn:ietf:params:xml:ns:yang:ietf\
-subscribed-notifications">sn:encode-json</encoding-format>
</transport-capability>
<transport-capability>
<transport-protocol xmlns:unt="urn:ietf:params:xml:ns:yang:\
ietf-udp-notif-transport">unt:udp-notif</transport-protocol>
<encoding-format xmlns:unt="urn:ietf:params:xml:ns:yang:iet\
f-udp-notif-transport">unt:encode-cbor</encoding-format>
</transport-capability>
</transport-capabilities>
</subscription-capabilities>
</system-capabilities>
</content-data>
</instance-data-set></artwork>
</figure>
<t>In addition, the client could also query notification transport
capabilities from the server. For example, the client sends <get>
request message to the the server to query from the server.</t>
<figure>
<artwork> <rpc message-id="101" xmlns="urn:ietf:params:xml:ns:netconf:base:1.0">
<get>
<filter type="subtree">
<system-capabilities xmlns="urn:ietf:params:xml:ns:yang:ietf-syste\
m-capabilities">
<subscription-capabilities xmlns="urn:ietf:params:xml:ns:yang:ie\
tf-notification-capabilities">
<transport-capabilities/>
</subscription-capabilities>
</system-capabilities>
</filter>
</get>
</rpc></artwork>
</figure>
<t>The server returns server data export capability using
<rpc-reply> as follows:</t>
<figure>
<artwork><rpc-reply xmlns="urn:ietf:params:xml:ns:netconf:base:1.0"
message-id="101">
<data>
<system-capabilities xmlns="urn:ietf:params:xml:ns:yang:ietf-system\
-capabilities">
<subscription-capabilities xmlns="urn:ietf:params:xml:ns:yang:iet\
f-notification-capabilities">
<transport-capabilities xmlns="urn:ietf:params:xml:ns:yang:ietf\
-notification-transport-capabilities">
<transport-capability>
<transport-protocol xmlns:hnt="urn:ietf:params:xml:ns:yang:\
ietf-https-notif-transport">hnt:https</transport-protocol>
<encoding-format xmlns:sn="urn:ietf:params:xml:ns:yang:ietf\
-subscribed-notifications">sn:encode-xml</encoding-format>
<encoding-format xmlns:sn="urn:ietf:params:xml:ns:yang:ietf\
-subscribed-notifications">sn:encode-json</encoding-format>
</transport-capability>
<transport-capability>
<transport-protocol xmlns:unt="urn:ietf:params:xml:ns:yang:\
ietf-udp-notif-transport">unt:udp-notif</transport-protocol>
<encoding-format xmlns:unt="urn:ietf:params:xml:ns:yang:iet\
f-udp-notif-transport">unt:encode-cbor</encoding-format>
</transport-capability>
</transport-capabilities>
</subscription-capabilities>
</system-capabilities>
</data>
</rpc-reply></artwork>
</figure>
</section>
</back>
</rfc>