-
Notifications
You must be signed in to change notification settings - Fork 1
/
draft-ietf-netconf-yang-library-augmentedby-01.txt
1568 lines (1050 loc) · 56.7 KB
/
draft-ietf-netconf-yang-library-augmentedby-01.txt
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
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
NETCONF Z. Lin
Internet-Draft B. Claise
Intended status: Standards Track Huawei
Expires: 24 April 2025 I. D. Martinez-Casanueva
Telefonica
21 October 2024
Augmented-by Addition into the IETF-YANG-Library
draft-ietf-netconf-yang-library-augmentedby-01
Abstract
This document augments the ietf-yang-library to provide the
augmented-by list. It facilitates the process of obtaining the
entire dependencies between YANG modules, by directly querying the
server's YANG module.
Discussion Venues
This note is to be removed before publishing as an RFC.
Source for this draft and an issue tracker can be found at
https://github.com/Zephyre777/draft-lincla-netconf-yang-library-
augmentation.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 24 April 2025.
Copyright Notice
Copyright (c) 2024 IETF Trust and the persons identified as the
document authors. All rights reserved.
Lin, et al. Expires 24 April 2025 [Page 1]
Internet-Draft Augmented-by Addition into the IETF-YANG October 2024
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Data Mesh Telemetry Architecture . . . . . . . . . . . . 5
3.2. Data Catalog . . . . . . . . . . . . . . . . . . . . . . 7
4. The "ietf-yang-library-augmentedby" YANG module . . . . . . . 9
4.1. Data Model Overview . . . . . . . . . . . . . . . . . . . 9
4.1.1. Tree View . . . . . . . . . . . . . . . . . . . . . . 9
4.1.2. Full Tree View . . . . . . . . . . . . . . . . . . . 9
4.1.3. YANG Module . . . . . . . . . . . . . . . . . . . . . 10
5. Implementation Status . . . . . . . . . . . . . . . . . . . . 12
5.1. Netopeer2 at IETF119 Hackathon . . . . . . . . . . . . . 12
5.2. Netopeer2 at IETF120 Hackathon . . . . . . . . . . . . . 13
5.3. Libyangpush Find-dependency . . . . . . . . . . . . . . . 13
6. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. draft-lincla-netconf-yang-library-augmentation: Changes
from 00 to 01 . . . . . . . . . . . . . . . . . . . . . . 13
6.2. draft-lincla-netconf-yang-library-augmentedby version
00 . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6.3. draft-lincla-netconf-yang-library-augmentedby: Changes from
00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 14
6.4. draft-lincla-netconf-yang-library-augmentedby: Changes from
01 to 02 . . . . . . . . . . . . . . . . . . . . . . . . 14
6.5. draft-ietf-netconf-yang-library-augmentedby version 00 . 14
6.6. draft-ietf-netconf-yang-library-augmentedby: Changes from
00 to 01 . . . . . . . . . . . . . . . . . . . . . . . . 14
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
9.1. Normative References . . . . . . . . . . . . . . . . . . 16
9.2. Informative References . . . . . . . . . . . . . . . . . 17
Appendix A. YANG module validation with yanglint . . . . . . . . 21
A.1. A valid ietf-yang-library data example . . . . . . . . . 21
A.2. An invalid ietf-yang-library data example . . . . . . . . 22
Appendix B. YANG Module augmenting RFC7895 . . . . . . . . . . . 23
B.1. Tree View for YANG module augmenting RFC7895 . . . . . . 23
Lin, et al. Expires 24 April 2025 [Page 2]
Internet-Draft Augmented-by Addition into the IETF-YANG October 2024
B.2. Full Tree View for ietf-yang-library with augmentation to
RFC7895 . . . . . . . . . . . . . . . . . . . . . . . . . 24
B.3. YANG module augmenting RFC7895 . . . . . . . . . . . . . 24
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 27
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 27
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction
The YANG Library [RFC8525] specifies a YANG module that provides the
information about the YANG modules and datastores to facilitate a
client application to fully utilize and understand the YANG data
modelling language. To know the YANG dependencies, [RFC8525] has
defined and provided the submodule list and the YANG modules
deviation list. However, the YANG modules augmentation is not
provided.
According to [RFC7950], both augmentations and deviations are
defining contents external to the model, but applying internally for
the model. It is important to know the augmentation and deviation as
they are dependencies between modules, but it is also difficult
because they are defined externally. When we try to use the ietf-
yang-library in [RFC8525] to obtain the reverse dependencies (i.e.,
augmentations and deviations), the augmentations are not defined in
it.
However, both the augmentation and the deviation work as YANG module
dependencies. Therefore, it is reasonable to document them the same
way in the IETF YANG Library. Besides, it will be easier to
determine the reverse dependency if the augmentation is directly
available in the YANG Library.
This draft augments the ietf-yang-library YANG module to include the
YANG module augmentation information.
1.1. Terminology
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.
The terminology from [RFC8525] is used in this document
Tree diagrams in this document use the notation defined in [RFC8340]
.
Lin, et al. Expires 24 April 2025 [Page 3]
Internet-Draft Augmented-by Addition into the IETF-YANG October 2024
2. Motivation
When using a YANG module, it is necessary to make sure that all its
dependencies are presented. [RFC7950] identifies four types of
dependencies between YANG modules:
* Import: the "import" statement allows a module or submodule to
reference definitions defined in other modules.
* Include: the "include" statement is used in a module to identify
each submodule that belongs to it.
* Augmentation: the "augment" statement defines the location in the
data model hierarchy where additional nodes are inserted.
* Deviation: the "deviation" statement defines a fragment of a
module that the server does not implement.
The import and include are direct dependencies while the augmentation
and deviation are reverse dependencies. To know the direct
dependencies of specific YANG module, we can parse this YANG module
as the dependencies are directly specified (import and include
statements").
As for the reverse dependencies, since they are defined externally,
we cannot parse the YANG module itself to discover them. The current
way to discover the reverse denpendencies is to query all YANG
modules from the server and to parse them. This is a lenthy process,
which must be repeated for each client that requires that
information.
According to the definition of module ietf-yang-library defined in
[RFC8525], in the schema of a module in YANG library, the deviation
is provided to tell this module is deviated by which other modules.
If YANG library can directly report all reverse dependencies, it
could provide a much easier and light-weight solution to find module
entire dependency, compared to getting and parsing all modules.
Right now, the YANG Library only provides the deviation list, but not
the augmentation. With augmentation being more widly used and
defined, and with some use cases arise as the requirement of automate
network management, the augmentation becomes essential information to
be learnt by client what has been additionally implemented, and for
it to better understand the device module relationship. Thus, the
YANG Library should be extended to also provide the augmentation
information.
Lin, et al. Expires 24 April 2025 [Page 4]
Internet-Draft Augmented-by Addition into the IETF-YANG October 2024
The implementation is not difficult since both augmentation and
deviation have similar way of working (both are applied to the
original module but invisible to them).
3. Use Cases
As the demand for YANG-based telemetry [RFC8641] arises, there is a
need for real-time knowledge of a specific YANG module's dependency
list when a specific YANG-Push notification is received.
The alternative for a YANG-Push receiver is to collect and store the
entire module set for every single server who could be streaming
data. This approach is not always practical due to the following
reasons:
* For a YANG-Push collector => we never know in advance which
telemetry content will be received and from whom.
* Querying all the YANG modules is time consuming => we lose the
real-time.
This section introduces two use cases that reflect the motivation for
extending YANG Library. One targets solving dependency problems in a
data mesh telemetry system while the other aims at building a data
catalog that makes YANG module information easily accessible.
3.1. Data Mesh Telemetry Architecture
A network analytics architecture that integrates YANG-Push and Kafka
is proposed and is continuously growing and gaining influence, refer
to the draft: An Architecture for YANG-Push to Apache Kafka
Integration [I-D.ietf-nmop-yang-message-broker-integration-03]. This
open-source project encompasses contributions such as Support of
Versioning in YANG Notifications Subscription
[I-D.ietf-netconf-yang-notifications-versioning] or Support of
Network Observation Timestamping in YANG Notifications
[I-D.netconf-tgraf-yang-push-observation-time], among others.
Lin, et al. Expires 24 April 2025 [Page 5]
Internet-Draft Augmented-by Addition into the IETF-YANG October 2024
The purpose of this project is to provide adequate information in the
YANG-Push notification so that when it is received, the module and
its dependency can be parsed and found automatically from the vantage
point. The architecture relies on the information of YANG module and
their dependency to realize, as one of its main goals is to solve the
problem of missing YANG semantics when data is received in Time
Series Database in the end. To solve the problem, a schema registry
is introduced to store YANG modules and all their relationships
(direct and reverse dependencies). The schema is obtained by the
NETCONF <get-schema> of the subscribed YANG module, which is obtained
by parsing the <subscription-started> message of each YANG-Push
subscription.
The scope of this draft is limited to configured subscriptions as
defined in Section 2.5 of [RFC8639], as opposed to dynamic
subscription defined in Section 2.4 of [RFC8639]. Configured
subscriptions are configured by a YANG client on the YANG server via
the supported network protocol. In this scenario, once the
subscription is set up, the YANG-Push notification (or event record)
is sent over the connections specified by the transport and receiver
of the configured subscription. This technique differs from dynamic
subscriptions, where the notification messages are sent over the
session that has been used to establish the subscription.
Section 3 of draft
[I-D.ietf-nmop-yang-message-broker-integration-03], defines a
separate network orchestrator and data collector in its architecture,
which means subscription and data collection are done separately.
Therefore, only configured subscription, with which user can
configure the subscription from one YANG client and receive the
telemetry data in another YANG collector indicated in the
subscription, could work with this architecture.
As a method for massively streaming telemetry data, the UDP-based
Transport for configured Subscription defined in draft
[I-D.ietf-netconf-udp-notif](UDP-notif) has been applied in
[I-D.ietf-nmop-yang-message-broker-integration-03] as the transport
method and streaming message type. With the same spirit as applying
the configured subscription, the UDP-notif has introduced more
flexibility into the architecture by defining useful metadata in the
message content such as the receiver address, port etc. In this way,
at the same time when the Data Mesh architecture is handling massive
data, it has the ability to trace the publisher of each message.
By explaining the above, we have gone back to the beginning of this
section, where we explained the schema registry, that contains the
YANG modules concerned in each YANG-Push subscription which are
obtained by NETCONF <get-schema> operation. UDP-notif has provided
Lin, et al. Expires 24 April 2025 [Page 6]
Internet-Draft Augmented-by Addition into the IETF-YANG October 2024
the ability to know the publisher of message. Therefore, an
independent process containing multiple <get-schema> operations is
launched after each new YANG-Push subscription module has been known.
However, the complexity still remains at:
* How we are going to find dependency of the YANG modules (so that
the YANG-Push subscription message has the complete module
dependencies for its set of YANG modules)?
* How do we conduct <get-schema>?
Currently, the method used for obtaining modules and finding module
dependencies is "get-all-schemas", where the YANG client retrieves
all YANG modules from the network device to enable later the client
can fully understand and utilize all modules and module dependencies
of device. This process is very heavy because in a real situation,
each device may implement hundreds of YANG modules, requiring up to
several minutes to complete, in the worse cases. Besides, the need
of parsing all YANG modules and finding all the dependencies adds a
small extra delay. Applying this method to obtain YANG module will
make the operation very costly, since after each subscribed module is
learned, "get-all-schemas" needs to be re-performed.
Therefore, considering the telemetry real-time aspects, this extra
delay in collecting (and processing) the dependencies through a get-
all-schemas approach is not ideal.
It's more efficient to get dependencies only for the required modules
in the telemetry.
By using the provided the augmentation information in ietf-yang-
library, the collector can directly obtain the YANG reverse
dependencies by fetching the contents of YANG Library, saving
collection (and processing time) at the collector, and therefore
helping with the near real-time aspects of the closed loop action.
3.2. Data Catalog
Finding the YANG modules implemented by a network device is paramount
for configuring and monitoring the status of a network. However,
since the inception of YANG the network industry has experienced a
tsunami of YANG modules developed by SDOs, open-source communities,
and network vendors. This heterogeneity of YANG modules, that vary
from one network device model to another, makes the management of a
multi-vendor network a big challenge for operators.
[Martinez-Casanueva2023]
Lin, et al. Expires 24 April 2025 [Page 7]
Internet-Draft Augmented-by Addition into the IETF-YANG October 2024
In this regard, a data catalog provides a registry of the datasets
exposed by remote data sources for consumers to discover data of
interest. Besides the location of the dataset (i.e., the data
source), the data catalog registers additional metadata such as the
data model (or schema) followed in the dataset or even related terms
defined in a business glossary.
Data catalog solutions typically implement collectors that ingest
metadata from the data sources themselves and also external metadata
sources. For example, a Kafka Schema Registry is a metadata source
that provides metadata about the data models followed by some data
stored in a Kafka topic.
In this sense, a YANG-enabled network device can be considered as
another kind of data source, which the Data Catalog can pull metadata
from. For instance, the data catalog can include a connector that
fetches metadata about the YANG modules implemented by the network
device. Combining these metadata with other such as the business
concept "interface", would enable data consumers to discover which
datasets related to the concept "interface" are exposed by the
network device.
Network devices that implement YANG Library expose metadata about
which YANG modules are implemented, and which are only imported.
However, what a data consumer needs at the end are the YANG modules
implemented by the device, hence, the combination of implemented YANG
modules with other YANG modules that might deviate or augment the
formers.
Coming back to the example of datasets related to the "interface"
concept, say we have a network device that implements the ietf-
interfaces module [RFC8343] and the ietf-ip module [RFC8344], where
the latter augments the former. For a data catalog to collect these
metadata, a connector would retrieve YANG Library data from the
target device. However, the current version of YANG Library would
not satisfy the use case as it would tell that the device implements
both ietf-interfaces and ietf-ip modules, but will miss the augment
dependency between them.
The current workaround to this limitation is to, in combination with
the YANG Library data, additionally fetch both YANG modules and
process them to discover that there is an augment dependency. This
adds extra burden on the connector, which is forced to combine
multiple metadata collection mechanisms. This process could be
softened by extending YANG Library to also capture augment
dependencies, in a similar fashion to deviation dependencies.
Lin, et al. Expires 24 April 2025 [Page 8]
Internet-Draft Augmented-by Addition into the IETF-YANG October 2024
4. The "ietf-yang-library-augmentedby" YANG module
This YANG module augments the ietf-yang-library module by adding the
augmented-by list in the "yang-library/module-set". The name
"augmented-by" indicates the modules by which the current module is
being augmented. Note that this module only augments the ietf-yang-
library defined in [RFC8525]. At the time of writing this document,
most vendors support [RFC7895], a previous revision of the ietf-yang-
library YANG module; The module that augments [RFC7895] is provided
in the Appendix B.
4.1. Data Model Overview
4.1.1. Tree View
The following is the YANG tree diagram for model ietf-yang-library-
augmentedby.
module: ietf-yang-library-augmentedby
augment /yanglib:yang-library/yanglib:module-set/yanglib:module:
+--ro augmented-by* -> ../../yanglib:module/name
4.1.2. Full Tree View
The following is the YANG tree diagram[RFC8340] for the ietf-yang-
library with the augmentation defined in module ietf-yang-library-
augmentedby, including the RPCs and notifications.
module: ietf-yang-library
+--ro yang-library
| +--ro module-set* [name]
| | +--ro name string
| | +--ro module* [name]
| | | +--ro name yang:yang-identifier
| | | +--ro revision? revision-identifier
| | | +--ro namespace inet:uri
| | | +--ro location* inet:uri
| | | +--ro submodule* [name]
| | | | +--ro name yang:yang-identifier
| | | | +--ro revision? revision-identifier
| | | | +--ro location* inet:uri
| | | +--ro feature* yang:yang-identifier
| | | +--ro deviation* -> ../../module/name
| | | +--ro yanglib-aug:augmented-by*
-> ../../yanglib:module/name
| | +--ro import-only-module* [name revision]
| | +--ro name yang:yang-identifier
Lin, et al. Expires 24 April 2025 [Page 9]
Internet-Draft Augmented-by Addition into the IETF-YANG October 2024
| | +--ro revision union
| | +--ro namespace inet:uri
| | +--ro location* inet:uri
| | +--ro submodule* [name]
| | +--ro name yang:yang-identifier
| | +--ro revision? revision-identifier
| | +--ro location* inet:uri
| +--ro schema* [name]
| | +--ro name string
| | +--ro module-set* -> ../../module-set/name
| +--ro datastore* [name]
| | +--ro name ds:datastore-ref
| | +--ro schema -> ../../schema/name
| +--ro content-id string
x--ro modules-state
x--ro module-set-id string
x--ro module* [name revision]
x--ro name yang:yang-identifier
x--ro revision union
+--ro schema? inet:uri
x--ro namespace inet:uri
x--ro feature* yang:yang-identifier
x--ro deviation* [name revision]
| x--ro name yang:yang-identifier
| x--ro revision union
x--ro conformance-type enumeration
x--ro submodule* [name revision]
x--ro name yang:yang-identifier
x--ro revision union
+--ro schema? inet:uri
notifications:
+---n yang-library-update
| +--ro content-id -> /yang-library/content-id
x---n yang-library-change
x--ro module-set-id -> /modules-state/module-set-id
4.1.3. YANG Module
The YANG module source code of ietf-yang-library-augmentedby in which
augmentation to the ietf-yang-library of [RFC8525] is defined.
<CODE BEGINS> file "[email protected]"
module ietf-yang-library-augmentedby {
yang-version 1.1;
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-library-augmentedby";
prefix yanglib-aug;
Lin, et al. Expires 24 April 2025 [Page 10]
Internet-Draft Augmented-by Addition into the IETF-YANG October 2024
import ietf-yang-library {
prefix yanglib;
reference
"RFC 8525: YANG Library";
}
organization
"IETF NETCONF (Network Configuration) Working Group";
contact
"WG Web: <https://datatracker.ietf.org/wg/netconf/>
WG List: <mailto:[email protected]>
Author: Zhuoyao Lin
<mailto:[email protected]>
Benoit Claise
<mailto:[email protected]>
IGNACIO DOMINGUEZ MARTINEZ-CASANUEVA
<matilto:[email protected]>";
description
"This module augments the ietf-yang-library defined in
[RFC8525] to provide not only the deviation list, but also
the augmented-by list, in order to give sufficient
information about the YANG modules reverse dependency. It
facilitates the process of obtaining the entire
dependencies of YANG module.
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 (RFC 2119)
(RFC 8174) when, and only when, they appear in all
capitals, as shown here.
Copyright (c) 2022 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
(https://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 2023-10-27 {
description
Lin, et al. Expires 24 April 2025 [Page 11]
Internet-Draft Augmented-by Addition into the IETF-YANG October 2024
"Added list augmented-by in yang-library/module-set/module to
make the module store the entire reverse dependency information
(augmented-by and deviation).";
reference
"RFC XXXX: Support of augmentedby in ietf-yang-library";
}
augment "/yanglib:yang-library/yanglib:module-set/yanglib:module" {
description
"Augment the augmented-by list from module info with the
module-augmented-by grouping" ;
leaf-list augmented-by {
type leafref {
path "../../yanglib:module/yanglib:name";
}
description
"Leaf-list of the augmentation used by this server to
modify the conformance of the module associated with
this entry. Note that the same module can be used for
augmented-by for multiple modules, so the same
entry MAY appear within multiple 'module' entries.
This reference MUST NOT (directly or indirectly)
refer to the module being augmented.
Robust clients may want to make sure that they handle a
situation where a module augments itself (directly or
indirectly) gracefully.";
}
}
}
<CODE ENDS>
5. Implementation Status
Note to the RFC-Editor: Please remove this section before publishing
(This follows the template in RFC7942).
5.1. Netopeer2 at IETF119 Hackathon
Zhuoyao Lin did the prototype implementation of the augmented-by list
feature of this draft and demonstrated it based on Netopeer2 in IETF
119 Hackathon.
Lin, et al. Expires 24 April 2025 [Page 12]
Internet-Draft Augmented-by Addition into the IETF-YANG October 2024
Netopeer2 is a NETCONF server & client implementation developed by
CESNET. Source code is here: [NTP17]. The actual feature is
implemented by extending the libyang [LY16] and sysrepo [SR16] which
are the base libraries for Netopeer2 to support populating the
augmented-by list.
5.2. Netopeer2 at IETF120 Hackathon
Zhuoyao Lin did a docker image of netopeer2 that integrates the
augmented-by feauture in sysrepo and libyang. The result is
presented at IETF 120 hackathon.
The source code can be obtained here: [NP24]
5.3. Libyangpush Find-dependency
Zhuoyao Lin did an implementation of find-dependency based on the
ietf-yang-library with augmented-by feature in the YANG-Push message
parser library libyangpush. The result is presented in IETF 120
hackathon.
The source code can be obtained here: [NP24]
6. Changes
6.1. draft-lincla-netconf-yang-library-augmentation: Changes from 00 to
01
The list name has been updated from "augmentation" to "augmented-by",
in order to represent the usage clearly.
The leafref has been changed from absolute path "/yanglib:yang-
libraray/yanglib:module-set/yanglib:module/yanglib:name" to relative
path "../../yanglib:module/yanglib:name". The YANG validation in the
appendix A shows that this path can work as expected.
Section 5 Implementation and section 6 Changes has been added.
6.2. draft-lincla-netconf-yang-library-augmentedby version 00
Updated the Use case content in Section 3.1. Add explanation: the
scope of use case "Data Mesh Architecture" is limited to configured
subscription.
Updated Implementation status content.
Lin, et al. Expires 24 April 2025 [Page 13]
Internet-Draft Augmented-by Addition into the IETF-YANG October 2024
6.3. draft-lincla-netconf-yang-library-augmentedby: Changes from 00 to
01
Updated affiliations
Update content of Section 3.1 Data Mesh use case. Explain the
limitation of applying get-all-schemas solution under the background
of using UDP-notif of configured subscription, and how the feature
proposed in the draft can improve the solution.
Full review of document. Nits and refinement of sections.
6.4. draft-lincla-netconf-yang-library-augmentedby: Changes from 01 to
02
Rewrite Section 2 Motivation.
Update Section 6 Changes's subsection title.
Update the Section 7 security consideration and section 8 IANA
Considerations.
Added in the appendix the Impact Analysis of ietf-yang-library and
proposal for the RFC8525bis draft.
6.5. draft-ietf-netconf-yang-library-augmentedby version 00
Resubmitted the draft name from:
draft-lincla-netconf-yang-library-augmentedby-02
to:
draft-ietf-netconf-yang-library-augmentedby-00
6.6. draft-ietf-netconf-yang-library-augmentedby: Changes from 00 to 01
Correct the yanglint validation invalid example.
Updated the explaination to the yanglint validation example
principle.
Delete Section "ietf-yang-library Impact Analysis, as an evaluation
for RFC8525bis". The idea of updating the RFC8525 is paused.
Lin, et al. Expires 24 April 2025 [Page 14]
Internet-Draft Augmented-by Addition into the IETF-YANG October 2024
7. Security Considerations
The YANG module specified in this document defines a schema for data
that is designed to be accessed via network management protocols such
as NETCONF [RFC6241] or RESTCONF [RFC8040]. The lowest NETCONF layer
is the secure transport layer, and the mandatory-to-implement secure
transport is Secure Shell (SSH) [RFC6242]. The lowest RESTCONF layer
is HTTPS, and the mandatory-to-implement secure transport is TLS
[RFC8446].
The Network Configuration Access Control Model (NACM) [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.
The readable node defined in this YANG module may be considered
sensitive or vulnerable in some network environments. It is thus
important to control read access(e.g., via get, get-config, or
notification) to this data node. The following is the explanation to
data node's sensitivity/vulnerability:
The "augmented-by" node in this YANG module could reveal all modules
that are augmenting one module. It could help attacker identify the
relationship between modules and server implementations known bugs.
Server vulnerabilities may include but not restricted to: 1. Too
many augmented-by records causes buffer overflow. 2. The augmented-
by node help identify through the inter-relation of modules how to
cause the server to crash or significantly degrade device
performance.
8. IANA Considerations
This document registers one URI in the "IETF XML Registry" [RFC3688].
Following the formate in [RFC3688], the following registration has
been made.
URI: urn:ietf:params:xml:ns:yang:ietf-yang-library-augmentedby
Registration Contact: The NETCONF WG of the IETF.
XML: N/A, the requested URI is an XML namespace.
This document registers one YANG module in the "YANG Module Names"
registry [RFC6020]
name: ietf-yang-library-augmentedby
namespace: urn:ietf:params:xml:ns:yang:ietf-yang-library-augmentedby
Lin, et al. Expires 24 April 2025 [Page 15]
Internet-Draft Augmented-by Addition into the IETF-YANG October 2024
prefix: yanglib-aug
reference: [I-D.lincla-netconf-yang-library-augmentedby]
9. References
9.1. Normative References
[LY16] Vasko, M., "libyang", BSD-3-Clause license, November 2016,
<https://github.com/CESNET/libyang.git>.
[NP24] Lin, Z., "Netopeer2-docker-ietf120", July 2024,
<https://github.com/network-
analytics/libyangpush/tree/feature/draft_augmentedby>.
[NTP17] Vasko, M., "Netopeer2", BSD-3-Clause license, May 2017,
<https://github.com/CESNET/netopeer2>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
DOI 10.17487/RFC3688, January 2004,
<https://www.rfc-editor.org/info/rfc3688>.
[RFC6020] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", RFC 6020,
DOI 10.17487/RFC6020, October 2010,
<https://www.rfc-editor.org/info/rfc6020>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6242] Wasserman, M., "Using the NETCONF Protocol over Secure
Shell (SSH)", RFC 6242, DOI 10.17487/RFC6242, June 2011,
<https://www.rfc-editor.org/info/rfc6242>.
[RFC7895] Bierman, A., Bjorklund, M., and K. Watsen, "YANG Module
Library", RFC 7895, DOI 10.17487/RFC7895, June 2016,
<https://www.rfc-editor.org/info/rfc7895>.
[RFC8040] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", RFC 8040, DOI 10.17487/RFC8040, January 2017,
<https://www.rfc-editor.org/info/rfc8040>.
Lin, et al. Expires 24 April 2025 [Page 16]
Internet-Draft Augmented-by Addition into the IETF-YANG October 2024
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8340] Bjorklund, M. and L. Berger, Ed., "YANG Tree Diagrams",
BCP 215, RFC 8340, DOI 10.17487/RFC8340, March 2018,
<https://www.rfc-editor.org/info/rfc8340>.
[RFC8341] Bierman, A. and M. Bjorklund, "Network Configuration
Access Control Model", STD 91, RFC 8341,
DOI 10.17487/RFC8341, March 2018,
<https://www.rfc-editor.org/info/rfc8341>.
[RFC8343] Bjorklund, M., "A YANG Data Model for Interface
Management", RFC 8343, DOI 10.17487/RFC8343, March 2018,
<https://www.rfc-editor.org/info/rfc8343>.
[RFC8344] Bjorklund, M., "A YANG Data Model for IP Management",
RFC 8344, DOI 10.17487/RFC8344, March 2018,
<https://www.rfc-editor.org/info/rfc8344>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[SR16] Vasko, M., "sysrepo", BSD-3-Clause license, January 2016,
<https://github.com/sysrepo/sysrepo.git>.
9.2. Informative References
[I-D.bjorklund-netmod-structural-mount-02]
Bjorklund, M., "YANG Structural Mount", Work in Progress,
Internet-Draft, draft-bjorklund-netmod-structural-mount-
02, 26 February 2016,
<https://datatracker.ietf.org/doc/html/draft-bjorklund-
netmod-structural-mount-02>.
[I-D.clacla-netmod-model-catalog-03]
Clarke, J. and B. Claise, "YANG module for
yangcatalog.org", Work in Progress, Internet-Draft, draft-
clacla-netmod-model-catalog-03, 3 April 2018,
<https://datatracker.ietf.org/doc/html/draft-clacla-
netmod-model-catalog-03>.
[I-D.ietf-netconf-udp-notif]
Zheng, G., Zhou, T., Graf, T., Francois, P., Feng, A. H.,
and P. Lucente, "UDP-based Transport for Configured
Subscriptions", Work in Progress, Internet-Draft, draft-
Lin, et al. Expires 24 April 2025 [Page 17]
Internet-Draft Augmented-by Addition into the IETF-YANG October 2024
ietf-netconf-udp-notif-14, 4 July 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
udp-notif-14>.
[I-D.ietf-netconf-yang-notifications-versioning]
Graf, T., Claise, B., and A. H. Feng, "Support of
Versioning in YANG Notifications Subscription", Work in
Progress, Internet-Draft, draft-ietf-netconf-yang-
notifications-versioning-05, 16 June 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-netconf-
yang-notifications-versioning-05>.
[I-D.ietf-netmod-module-tags-00]
Hopps, C., Berger, L., and D. Bogdanovic, "YANG Module
Tags", Work in Progress, Internet-Draft, draft-ietf-
netmod-module-tags-00, 6 March 2018,
<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
module-tags-00>.
[I-D.ietf-netmod-rfc6087bis]
Bierman, A., "Guidelines for Authors and Reviewers of
Documents Containing YANG Data Models", Work in Progress,
Internet-Draft, draft-ietf-netmod-rfc6087bis-20, 13 March
2018, <https://datatracker.ietf.org/doc/html/draft-ietf-
netmod-rfc6087bis-20>.
[I-D.ietf-netmod-yang-module-versioning-10]
Wilton, R., Rahman, R., Lengyel, B., Clarke, J., and J.
Sterne, "Updated YANG Module Revision Handling", Work in
Progress, Internet-Draft, draft-ietf-netmod-yang-module-
versioning-10, 17 October 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
yang-module-versioning-10>.
[I-D.ietf-netmod-yang-module-versioning-12]
Wilton, R., Rahman, R., Lengyel, B., Clarke, J., and J.
Sterne, "Updated YANG Module Revision Handling", Work in
Progress, Internet-Draft, draft-ietf-netmod-yang-module-
versioning-12, 24 June 2024,
<https://datatracker.ietf.org/doc/html/draft-ietf-netmod-
yang-module-versioning-12>.
[I-D.ietf-netmod-yang-packages-03]
Wilton, R., Rahman, R., Clarke, J., Sterne, J., and B. Wu,