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
1001
1002
1003
1004
1005
1006
1007
1008
1009
1010
1011
1012
1013
1014
1015
1016
1017
1018
1019
1020
1021
1022
1023
1024
1025
1026
1027
1028
1029
1030
1031
1032
1033
1034
1035
1036
1037
1038
1039
1040
1041
1042
1043
1044
1045
1046
1047
1048
1049
1050
1051
1052
1053
1054
1055
1056
1057
1058
1059
1060
1061
1062
1063
1064
1065
1066
1067
1068
1069
1070
1071
1072
1073
1074
1075
1076
1077
1078
1079
1080
1081
1082
1083
1084
1085
1086
1087
1088
1089
1090
1091
1092
1093
1094
1095
1096
1097
1098
1099
1100
1101
1102
1103
1104
1105
1106
1107
1108
1109
1110
1111
1112
1113
1114
1115
1116
1117
1118
1119
1120
1121
1122
1123
1124
1125
1126
1127
1128
1129
1130
1131
1132
1133
1134
1135
1136
1137
1138
1139
1140
1141
1142
1143
1144
1145
1146
1147
1148
1149
1150
1151
1152
1153
1154
1155
1156
1157
1158
1159
1160
1161
1162
1163
1164
1165
1166
1167
1168
1169
1170
1171
1172
1173
|
<pre>Internet Engineering Task Force (IETF) L. Lhotka
Request for Comments: 7952 CZ.NIC
Updates: <a href="./rfc6110">6110</a> August 2016
Category: Standards Track
ISSN: 2070-1721
<span class="h1">Defining and Using Metadata with YANG</span>
Abstract
This document defines a YANG extension that allows for defining
metadata annotations in YANG modules. The document also specifies
XML and JSON encoding of annotations and other rules for annotating
instances of YANG data nodes.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in <a href="./rfc7841#section-2">Section 2 of RFC 7841</a>.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
<a href="http://www.rfc-editor.org/info/rfc7952">http://www.rfc-editor.org/info/rfc7952</a>.
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to <a href="https://www.rfc-editor.org/bcp/bcp78">BCP 78</a> and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>) 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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
<span class="grey">Lhotka Standards Track [Page 1]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-2" ></span>
<span class="grey"><a href="./rfc7952">RFC 7952</a> YANG Metadata August 2016</span>
Table of Contents
<a href="#section-1">1</a>. Introduction . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-3">3</a>
<a href="#section-2">2</a>. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-2.1">2.1</a>. Key Words . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-2.2">2.2</a>. Terms Defined in Other Documents . . . . . . . . . . . . <a href="#page-5">5</a>
<a href="#section-2.3">2.3</a>. Namespaces and Prefixes . . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-2.4">2.4</a>. Definitions of New Terms . . . . . . . . . . . . . . . . <a href="#page-7">7</a>
<a href="#section-3">3</a>. Defining Annotations in YANG . . . . . . . . . . . . . . . . <a href="#page-8">8</a>
<a href="#section-3.1">3.1</a>. Example Definition . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-4">4</a>. Using Annotations . . . . . . . . . . . . . . . . . . . . . . <a href="#page-9">9</a>
<a href="#section-5">5</a>. The Encoding of Annotations . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-5.1">5.1</a>. XML Encoding . . . . . . . . . . . . . . . . . . . . . . <a href="#page-10">10</a>
<a href="#section-5.2">5.2</a>. JSON Encoding . . . . . . . . . . . . . . . . . . . . . . <a href="#page-11">11</a>
<a href="#section-5.2.1">5.2.1</a>. Metadata Object and Annotations . . . . . . . . . . . <a href="#page-11">11</a>
5.2.2. Adding Annotations to anydata, container, and list
Entries . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-12">12</a>
<a href="#section-5.2.3">5.2.3</a>. Adding Annotations to anyxml and leaf Instances . . . <a href="#page-12">12</a>
<a href="#section-5.2.4">5.2.4</a>. Adding Annotations to leaf-list Entries . . . . . . . <a href="#page-13">13</a>
<a href="#section-6">6</a>. Representing Annotations in DSDL Schemas . . . . . . . . . . <a href="#page-14">14</a>
<a href="#section-7">7</a>. Metadata YANG Module . . . . . . . . . . . . . . . . . . . . <a href="#page-16">16</a>
<a href="#section-8">8</a>. IANA Considerations . . . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-9">9</a>. Security Considerations . . . . . . . . . . . . . . . . . . . <a href="#page-18">18</a>
<a href="#section-10">10</a>. References . . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
<a href="#section-10.1">10.1</a>. Normative References . . . . . . . . . . . . . . . . . . <a href="#page-19">19</a>
<a href="#section-10.2">10.2</a>. Informative References . . . . . . . . . . . . . . . . . <a href="#page-20">20</a>
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . <a href="#page-21">21</a>
<span class="grey">Lhotka Standards Track [Page 2]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-3" ></span>
<span class="grey"><a href="./rfc7952">RFC 7952</a> YANG Metadata August 2016</span>
<span class="h2"><a class="selflink" id="section-1" href="#section-1">1</a>. Introduction</span>
There is a need to be able to annotate instances of YANG [<a href="./rfc7950" title=""The YANG 1.1 Data Modeling Language"">RFC7950</a>]
data nodes with metadata. Typical use cases are as follows:
o Complementing regular data model information with
instance-specific metadata, comments, etc.
o Providing information about the rendering of data in user
interfaces.
o Deactivating a subtree in a configuration datastore while keeping
the data in place.
o Network management protocols often use metadata annotations for
various purposes in both operation requests and responses. For
example, the <edit-config> operation in the Network Configuration
Protocol (NETCONF) (see <a href="./rfc6241#section-7.2">Section 7.2 of [RFC6241]</a>) uses annotations
in the form of XML attributes for identifying the location in a
configuration datastore and the type of the operation.
However, metadata annotations could potentially lead to
interoperability problems if they are used in an ad hoc fashion by
different parties and/or without proper documentation. A sound
metadata framework for YANG should therefore satisfy these
requirements:
1. The set of annotations must be extensible in a decentralized
manner so as to allow for defining new annotations without
running the risk of collisions with annotations defined and used
by others.
2. The syntax and semantics of annotations must be documented, and
the documentation must be easily accessible.
3. Clients of network management protocols such as NETCONF [<a href="./rfc6241" title=""Network Configuration Protocol (NETCONF)"">RFC6241</a>]
or RESTCONF [<a href="#ref-RESTCONF" title=""RESTCONF Protocol"">RESTCONF</a>] must be able to discover all annotations
supported by a given server and identify each of them correctly.
4. Annotations sent by a server should not break clients that don't
support them.
This document proposes a systematic way to define metadata
annotations. For this purpose, the YANG extension "annotation" is
defined in the module "ietf-yang-metadata" (<a href="#section-7">Section 7</a>). Other YANG
modules importing this module can use the "annotation" statement for
defining one or more annotations.
<span class="grey">Lhotka Standards Track [Page 3]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-4" ></span>
<span class="grey"><a href="./rfc7952">RFC 7952</a> YANG Metadata August 2016</span>
The benefits of defining the metadata annotations in a YANG module
are the following:
o Each annotation is bound to a YANG module name and namespace URI.
This makes its encoding in instance documents (both XML and JSON)
straightforward and consistent with the encoding of YANG data node
instances.
o Annotations defined in IETF Standards Track documents are
indirectly registered through IANA in the "YANG Module Names"
registry [<a href="./rfc6020" title=""YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)"">RFC6020</a>].
o Annotations are included in the data model. YANG compilers and
tools supporting a certain annotation can thus take them into
account and modify their behavior accordingly.
o The semantics of an annotation are defined in the "description"
and "reference" statements.
o An annotation can be declared as conditional by using the
"if-feature" statement.
o The type of each annotation is explicitly specified; any YANG
built-in or derived type that is available for leaf or leaf-list
data nodes may be specified for annotations as well.
In the XML encoding, XML attributes are a natural instrument for
attaching annotations to data node instances. This document
deliberately adopts some restrictions in order to remain compatible
with the XML encoding of YANG data node instances and limitations of
XML attributes. Specifically,
o annotations can only be scalar values.
o annotations cannot be attached to a whole list or leaf-list
instance, only to individual list or leaf-list entries.
Due to the rules for YANG extensions (see <a href="./rfc7950#section-6.3.1">Section 6.3.1 in
[RFC7950]</a>), annotation definitions posit relatively weak conformance
requirements. The alternative of introducing a new built-in YANG
statement for defining annotations was considered, but it was seen as
a major change to the language that is inappropriate for YANG 1.1,
which was chartered as a maintenance revision. After evaluating
real-life usage of metadata annotations, it is conceivable that such
a new built-in statement might be added in a future revision of YANG.
<span class="grey">Lhotka Standards Track [Page 4]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-5" ></span>
<span class="grey"><a href="./rfc7952">RFC 7952</a> YANG Metadata August 2016</span>
<span class="h2"><a class="selflink" id="section-2" href="#section-2">2</a>. Terminology</span>
<span class="h3"><a class="selflink" id="section-2.1" href="#section-2.1">2.1</a>. Key Words</span>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [<a href="./rfc2119" title=""Key words for use in RFCs to Indicate Requirement Levels"">RFC2119</a>].
<span class="h3"><a class="selflink" id="section-2.2" href="#section-2.2">2.2</a>. Terms Defined in Other Documents</span>
The following terms are defined in [<a href="./rfc6241" title=""Network Configuration Protocol (NETCONF)"">RFC6241</a>]:
o capability
o client
o datastore
o message
o protocol operation
o server
The following terms are defined in [<a href="./rfc7950" title=""The YANG 1.1 Data Modeling Language"">RFC7950</a>]:
o action
o anydata
o anyxml
o built-in type
o container
o data model
o data node
o data tree
o derived type
o extension
o leaf
<span class="grey">Lhotka Standards Track [Page 5]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-6" ></span>
<span class="grey"><a href="./rfc7952">RFC 7952</a> YANG Metadata August 2016</span>
o leaf-list
o list
o module
o Remote Procedure Call (RPC) input and output
The following terms are defined in [<a href="#ref-XML-INFOSET">XML-INFOSET</a>]:
o attribute
o document
o element
The following terms are defined in [<a href="#ref-XML-NAMES">XML-NAMES</a>]:
o local name
o namespace name
o prefix
o qualified name
The following terms are defined in [<a href="./rfc7159" title=""The JavaScript Object Notation (JSON) Data Interchange Format"">RFC7159</a>]:
o array
o member
o object
o primitive type
<span class="grey">Lhotka Standards Track [Page 6]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-7" ></span>
<span class="grey"><a href="./rfc7952">RFC 7952</a> YANG Metadata August 2016</span>
<span class="h3"><a class="selflink" id="section-2.3" href="#section-2.3">2.3</a>. Namespaces and Prefixes</span>
In the following text, XML element names and YANG extension
statements are always written with explicit namespace prefixes that
are assumed to be bound to URI references as shown in Table 1.
+--------+------------------------------------------------+
| Prefix | URI Reference |
+--------+------------------------------------------------+
| elm | http://example.org/example-last-modified |
| md | urn:ietf:params:xml:ns:yang:ietf-yang-metadata |
| rng | <a href="http://relaxng.org/ns/structure/1.0">http://relaxng.org/ns/structure/1.0</a> |
+--------+------------------------------------------------+
Table 1: Used Namespace Prefixes and Corresponding URI References
<span class="h3"><a class="selflink" id="section-2.4" href="#section-2.4">2.4</a>. Definitions of New Terms</span>
o annotation: a single item of metadata that is attached to YANG
data node instances.
o metadata: additional information that complements a data tree.
o metadata object: an object in JSON encoding that contains all
annotations attached to a given data node instance.
<span class="grey">Lhotka Standards Track [Page 7]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-8" ></span>
<span class="grey"><a href="./rfc7952">RFC 7952</a> YANG Metadata August 2016</span>
<span class="h2"><a class="selflink" id="section-3" href="#section-3">3</a>. Defining Annotations in YANG</span>
Metadata annotations are defined by the YANG extension
"md:annotation". This YANG language extension is defined in the
module "ietf-yang-metadata" (<a href="#section-7">Section 7</a>).
Substatements of "md:annotation" are shown in Table 2. They are all
core YANG statements, and the numbers in the second column refer to
the corresponding section in [<a href="./rfc7950" title=""The YANG 1.1 Data Modeling Language"">RFC7950</a>] where each statement is
described.
+--------------+---------------------+-------------+
| substatement | section in <a href="./rfc7950">RFC 7950</a> | cardinality |
+--------------+---------------------+-------------+
| description | 7.21.3 | 0..1 |
| if-feature | 7.20.2 | 0..n |
| reference | 7.21.4 | 0..1 |
| status | 7.21.2 | 0..1 |
| type | 7.6.3 | 1 |
| units | 7.3.3 | 0..1 |
+--------------+---------------------+-------------+
Table 2: Substatements of "md:annotation"
An annotation carries a single value. The "type" substatement, which
MUST be present, takes as an argument the name of an existing
built-in or derived type, and the value of the annotation MUST match
this type. See <a href="./rfc7950#section-7.4">Section 7.4 of [RFC7950]</a> for details.
An annotation can be made conditional by using one or more
"if-feature" statements; the annotation is then supported only by
servers that advertise the corresponding feature.
The semantics and usage rules for an annotation SHOULD be fully
specified in "description", "reference", and "units" statements.
An annotation MUST NOT change the data tree semantics defined by
YANG. For example, it is illegal to define and use an annotation
that allows for overriding uniqueness of leaf-list entries.
The "status" statement can be used exactly as it is used for YANG
data nodes.
A YANG module containing one or more "md:annotation" statements
SHOULD NOT be used for defining data nodes or groupings. Also,
derived types, identities, and features SHOULD NOT be defined in such
a module unless they are used by the definitions of annotations in
that module.
<span class="grey">Lhotka Standards Track [Page 8]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-9" ></span>
<span class="grey"><a href="./rfc7952">RFC 7952</a> YANG Metadata August 2016</span>
<span class="h3"><a class="selflink" id="section-3.1" href="#section-3.1">3.1</a>. Example Definition</span>
The following module defines the "last-modified" annotation:
module example-last-modified {
namespace "http://example.org/example-last-modified";
prefix "elm";
import ietf-yang-types {
prefix "yang";
}
import ietf-yang-metadata {
prefix "md";
}
md:annotation last-modified {
type yang:date-and-time;
description
"This annotation contains the date and time when the
annotated instance was last modified (or created).";
}
}
<span class="h2"><a class="selflink" id="section-4" href="#section-4">4</a>. Using Annotations</span>
By advertising a YANG module in which a metadata annotation is
defined using the "md:annotation" statement, a server indicates that
it is prepared to handle that annotation according to the
annotation's definition. That is, an annotation advertised by the
server may be attached to an instance of a data node defined in any
YANG module that is implemented by the server.
Depending on its semantics, an annotation may have an effect only in
certain data trees and/or on instances of specific types of data
nodes.
A client MUST NOT add a specific annotation to data node instances if
the server didn't advertise it.
Due care has to be exercised when introducing annotations in network
management systems in order to avoid interoperability problems and
software failures caused by a client that does not understand the
annotations' semantics. Generally, it is safe for a server to use
annotations in the following cases:
o An annotation is an integral part of a built-in or negotiated
protocol capability.
o An annotation contains auxiliary information that is not critical
for protocol operation.
<span class="grey">Lhotka Standards Track [Page 9]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-10" ></span>
<span class="grey"><a href="./rfc7952">RFC 7952</a> YANG Metadata August 2016</span>
o The client explicitly asks the server, e.g., via a parameter of a
protocol operation request, to include an annotation in the
response.
<span class="h2"><a class="selflink" id="section-5" href="#section-5">5</a>. The Encoding of Annotations</span>
XML attributes are a natural choice for encoding metadata in XML
instance documents. For JSON [<a href="./rfc7159" title=""The JavaScript Object Notation (JSON) Data Interchange Format"">RFC7159</a>], there is no generally
established method for encoding metadata. This document thus
introduces a special encoding method that is consistent with the JSON
encoding of YANG data node instances as defined in [<a href="./rfc7951" title=""JSON Encoding of Data Modeled with YANG"">RFC7951</a>].
<span class="h3"><a class="selflink" id="section-5.1" href="#section-5.1">5.1</a>. XML Encoding</span>
Metadata annotations are added to XML-encoded instances of YANG data
nodes as XML attributes according to these rules:
o The local name of the attribute SHALL be the same as the name of
the annotation specified in the argument of the corresponding
"md:annotation" statement.
o The namespace of the attribute SHALL be identified by the URI that
appears as the argument of the "namespace" statement in the YANG
module where the annotation is defined. It is RECOMMENDED that
the prefix specified by the "prefix" statement in the same module
be used in the qualified name of the attribute.
o The attribute value SHALL be encoded in the same way as the value
of a YANG leaf instance having the same type; see <a href="./rfc7950#section-9">Section 9 of
[RFC7950]</a>.
For example, the "last-modified" annotation defined in <a href="#section-3.1">Section 3.1</a>
may be encoded as follows:
<foo xmlns:elm="http://example.org/example-last-modified"
elm:last-modified="2015-09-16T10:27:35+02:00">
...
</foo>
<span class="grey">Lhotka Standards Track [Page 10]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-11" ></span>
<span class="grey"><a href="./rfc7952">RFC 7952</a> YANG Metadata August 2016</span>
<span class="h3"><a class="selflink" id="section-5.2" href="#section-5.2">5.2</a>. JSON Encoding</span>
The JSON metadata encoding defined in this section has the following
properties:
1. The encoding of YANG data node instances as defined in [<a href="./rfc7951" title=""JSON Encoding of Data Modeled with YANG"">RFC7951</a>]
does not change.
2. Namespaces of metadata annotations are encoded in the same way as
namespaces of YANG data node instances; see [<a href="./rfc7951" title=""JSON Encoding of Data Modeled with YANG"">RFC7951</a>].
<span class="h4"><a class="selflink" id="section-5.2.1" href="#section-5.2.1">5.2.1</a>. Metadata Object and Annotations</span>
All metadata annotations assigned to a YANG data node instance are
encoded as members (name/value pairs) of a single JSON object,
henceforth denoted as the metadata object. The placement and name of
this object depend on the type of the data node as specified in the
following subsections.
The name of a metadata annotation (as a member of the metadata
object) has the following ABNF syntax [<a href="./rfc5234" title=""Augmented BNF for Syntax Specifications: ABNF"">RFC5234</a>], where the production
for "identifier" is defined in <a href="./rfc7950#section-14">Section 14 of [RFC7950]</a>:
annotation-name = identifier ":" identifier
where the left identifier is the name of the YANG module in which the
annotation is defined and the identifier on the right is the name of
the annotation specified in the argument of the corresponding
"md:annotation" statement.
Note that unlike member names of YANG data node instances in JSON
encoding (see <a href="./rfc7951#section-4">Section 4 in [RFC7951]</a>), for annotations the explicit
namespace identifier (module name) must always be present.
The value of a metadata annotation SHALL be encoded in exactly the
same way as the value of a YANG leaf node having the same type as the
annotation; see <a href="./rfc7951#section-6">Section 6 of [RFC7951]</a>.
<span class="grey">Lhotka Standards Track [Page 11]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-12" ></span>
<span class="grey"><a href="./rfc7952">RFC 7952</a> YANG Metadata August 2016</span>
<span class="h4"><a class="selflink" id="section-5.2.2" href="#section-5.2.2">5.2.2</a>. Adding Annotations to anydata, container, and list Entries</span>
For a data node instance that is encoded as a JSON object (i.e., a
container, list entry, or anydata node), the metadata object is added
as a new member of that object with the name "@".
Examples:
o "cask" is a container or anydata node:
"cask": {
"@": {
"example-last-modified:last-modified":
"2015-09-16T10:27:35+02:00"
},
...
}
o "seq" is a list whose key is "name"; annotation "last-modified" is
added only to the first entry:
"seq": [
{
"@": {
"example-last-modified:last-modified":
"2015-09-16T10:27:35+02:00"
},
"name": "one",
...
},
{
"name": "two",
...
}
]
<span class="h4"><a class="selflink" id="section-5.2.3" href="#section-5.2.3">5.2.3</a>. Adding Annotations to anyxml and leaf Instances</span>
For an anyxml or leaf instance, the metadata object is added as a
sibling name/value pair whose name is the symbol "@" concatenated
with the name of the leaf or anyxml member that is being annotated.
The namespace part (module name) is included if and only if it is in
the name of the annotated member.
<span class="grey">Lhotka Standards Track [Page 12]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-13" ></span>
<span class="grey"><a href="./rfc7952">RFC 7952</a> YANG Metadata August 2016</span>
Examples:
o "flag" is a leaf node of the "boolean" type defined in module
"foo", and we assume that the namespace name has to be expressed
in its JSON encoding:
"foo:flag": true,
"@foo:flag": {
"example-last-modified:last-modified":
"2015-09-16T10:27:35+02:00"
}
o "stuff" is an anyxml node:
"stuff": [1, null, "three"],
"@stuff": {
"example-last-modified:last-modified":
"2015-09-16T10:27:35+02:00"
}
<span class="h4"><a class="selflink" id="section-5.2.4" href="#section-5.2.4">5.2.4</a>. Adding Annotations to leaf-list Entries</span>
For a leaf-list entry, which is represented as a JSON array with
values of a primitive type, annotations may be assigned to one or
more entries by adding a name/array pair as a sibling of the
leaf-list entry, where the name is the symbol "@" concatenated with
the name of the leaf-list that is being annotated, and the value is a
JSON array whose i-th element is the metadata object with annotations
assigned to the i-th entry of the leaf-list entry, or null if the
i-th entry has no annotations.
Trailing null values in that array, i.e., those following the last
non-null metadata object, MAY be omitted.
For example, in the following leaf-list instance with four entries,
the "last-modified" annotation is added to the second and third
entries in the following way:
"bibliomod:folio": [6, 3, 7, 8],
"@bibliomod:folio": [
null,
{ "example-last-modified:last-modified":
"2015-06-18T17:01:14+02:00"
},
{ "example-last-modified:last-modified":
"2015-09-16T10:27:35+02:00"
}
]
<span class="grey">Lhotka Standards Track [Page 13]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-14" ></span>
<span class="grey"><a href="./rfc7952">RFC 7952</a> YANG Metadata August 2016</span>
<span class="h2"><a class="selflink" id="section-6" href="#section-6">6</a>. Representing Annotations in DSDL Schemas</span>
[<a id="ref-RFC6110">RFC6110</a>] defines the standard mapping of YANG data models to
Document Schema Definition Languages (DSDL) [<a href="#ref-ISO.19757-1">ISO.19757-1</a>]. This
section specifies the mapping for the extension statement
"md:annotation" (<a href="#section-7">Section 7</a>), which enables validation of XML instance
documents containing metadata annotations.
The first step of the DSDL mapping procedure, i.e., the
transformation of the YANG data model to the hybrid schema (see
<a href="./rfc6110#section-6">Section 6 in [RFC6110]</a>), is modified as follows:
1. If the data model contains at least one "md:annotation"
statement, then a RELAX NG [<a href="#ref-ISO.19757-2">ISO.19757-2</a>] named pattern definition
MUST be added as a child of the root <rng:grammar> element in the
hybrid schema. It is RECOMMENDED to use the name
"__yang_metadata__" for this named pattern.
2. A reference to the named pattern described in item 1 MUST be
included as a child of every <rng:element> pattern that
corresponds to an anydata, container, leaf, leaf-list, or list
data node.
3. Every metadata annotation definition in the form
md:annotation ARGUMENT {
...
}
is mapped to the following RELAX NG [<a href="#ref-ISO.19757-2">ISO.19757-2</a>] pattern:
<rng:optional>
<rng:attribute name="PREFIX:ARGUMENT">
...
</rng:attribute>
</rng:optional>
where PREFIX is the prefix bound to the namespace URI of the YANG
module that contains the "md:annotation" statement. The above
pattern SHALL be inserted as a child of the named pattern
described in item 1.
4. Substatements of "md:annotation" SHALL be mapped to children of
the "rng:attribute" pattern exactly as described in <a href="./rfc6110#section-10">Section 10 of
[RFC6110]</a>.
<span class="grey">Lhotka Standards Track [Page 14]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-15" ></span>
<span class="grey"><a href="./rfc7952">RFC 7952</a> YANG Metadata August 2016</span>
For example, the named pattern (item 1), when constructed only for
the "last-modified" annotation, will have the following definition:
<rng:define name="__yang_metadata__">
<rng:optional>
<rng:attribute name="elm:last-modified">
<rng:ref name="ietf-yang-types__date-and-time"/>
</rng:attribute>
</rng:optional>
</rng:define>
Every "rng:element" pattern that corresponds to an anydata,
container, leaf, list, or leaf-list data node will then contain a
reference to the above named pattern; for example:
<rng:element name="foo:bar">
<rng:ref name="__yang_metadata__"/>
...
</rng:element>
Note that it is not necessary to use such a reference for
"rng:element" patterns corresponding to anyxml data nodes because
they already permit any XML attributes to be attached to their
instances.
The second step of the DSDL mapping procedure, i.e., the
transformation of the hybrid schema to RELAX NG [<a href="#ref-ISO.19757-2">ISO.19757-2</a>],
Schematron [<a href="#ref-ISO.19757-3">ISO.19757-3</a>], and Document Semantics Renaming Language
(DSRL) [<a href="#ref-ISO.19757-8">ISO.19757-8</a>] schemas, is unaffected by the inclusion of
"md:annotation".
<span class="grey">Lhotka Standards Track [Page 15]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-16" ></span>
<span class="grey"><a href="./rfc7952">RFC 7952</a> YANG Metadata August 2016</span>
<span class="h2"><a class="selflink" id="section-7" href="#section-7">7</a>. Metadata YANG Module</span>
<CODE BEGINS> file "ietf-yang-metadata@2016-08-05.yang"
module ietf-yang-metadata {
namespace "urn:ietf:params:xml:ns:yang:ietf-yang-metadata";
prefix "md";
organization
"IETF NETMOD (NETCONF Data Modeling Language) Working Group";
contact
"WG Web: <<a href="https://datatracker.ietf.org/wg/netmod/">https://datatracker.ietf.org/wg/netmod/</a>>
WG List: <mailto:netmod@ietf.org>
WG Chair: Lou Berger
<mailto:lberger@labn.net>
WG Chair: Kent Watsen
<mailto:kwatsen@juniper.net>
Editor: Ladislav Lhotka
<mailto:lhotka@nic.cz>";
description
"This YANG module defines an 'extension' statement that allows
for defining metadata annotations.
Copyright (c) 2016 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 Simplified BSD License set
forth in <a href="#section-4">Section 4</a>.c of the IETF Trust's Legal Provisions
Relating to IETF Documents
(<a href="http://trustee.ietf.org/license-info">http://trustee.ietf.org/license-info</a>).
This version of this YANG module is part of <a href="./rfc7952">RFC 7952</a>
(<a href="http://www.rfc-editor.org/info/rfc7952">http://www.rfc-editor.org/info/rfc7952</a>); see the RFC itself
for full legal notices.";
<span class="grey">Lhotka Standards Track [Page 16]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-17" ></span>
<span class="grey"><a href="./rfc7952">RFC 7952</a> YANG Metadata August 2016</span>
revision 2016-08-05 {
description
"Initial revision.";
reference
"<a href="./rfc7952">RFC 7952</a>: Defining and Using Metadata with YANG";
}
extension annotation {
argument name;
description
"This extension allows for defining metadata annotations in
YANG modules. The 'md:annotation' statement can appear only
at the top level of a YANG module or submodule, i.e., it
becomes a new alternative in the ABNF production rule for
'body-stmts' (<a href="./rfc7950#section-14">Section 14 in RFC 7950</a>).
The argument of the 'md:annotation' statement defines the name
of the annotation. Syntactically, it is a YANG identifier as
defined in <a href="./rfc7950#section-6.2">Section 6.2 of RFC 7950</a>.
An annotation defined with this 'extension' statement inherits
the namespace and other context from the YANG module in which
it is defined.
The data type of the annotation value is specified in the same
way as for a leaf data node using the 'type' statement.
The semantics of the annotation and other documentation can be
specified using the following standard YANG substatements (all
are optional): 'description', 'if-feature', 'reference',
'status', and 'units'.
A server announces support for a particular annotation by
including the module in which the annotation is defined among
the advertised YANG modules, e.g., in a NETCONF <hello>
message or in the YANG library (<a href="./rfc7950">RFC 7950</a>). The annotation can
then be attached to any instance of a data node defined in any
YANG module that is advertised by the server.
XML encoding and JSON encoding of annotations are defined in
<a href="./rfc7952">RFC 7952</a>.";
}
}
<CODE ENDS>
<span class="grey">Lhotka Standards Track [Page 17]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-18" ></span>
<span class="grey"><a href="./rfc7952">RFC 7952</a> YANG Metadata August 2016</span>
<span class="h2"><a class="selflink" id="section-8" href="#section-8">8</a>. IANA Considerations</span>
This document registers a URI in the "IETF XML Registry" [<a href="./rfc3688" title=""The IETF XML Registry"">RFC3688</a>].
Following the format in <a href="./rfc3688">RFC 3688</a>, the following registration has been
made.
---------------------------------------------------------------------
URI: urn:ietf:params:xml:ns:yang:ietf-yang-metadata
Registrant Contact: The NETMOD WG of the IETF.
XML: N/A, the requested URI is an XML namespace.
---------------------------------------------------------------------
This document registers a YANG module in the "YANG Module Names"
registry [<a href="./rfc6020" title=""YANG - A Data Modeling Language for the Network Configuration Protocol (NETCONF)"">RFC6020</a>].
---------------------------------------------------------------------
Name: ietf-yang-metadata
Namespace: urn:ietf:params:xml:ns:yang:ietf-yang-metadata
Prefix: md
Reference: <a href="./rfc7952">RFC 7952</a>
---------------------------------------------------------------------
<span class="h2"><a class="selflink" id="section-9" href="#section-9">9</a>. Security Considerations</span>
This document introduces a mechanism for defining metadata
annotations in YANG modules and attaching them to instances of YANG
data nodes. By itself, this mechanism represents no security threat.
Security implications of a particular annotation defined using this
mechanism MUST be duly considered and documented in the annotation's
definition.
An annotation SHOULD be subject to the same or stricter access
control rules as the data node instance to which the annotation is
attached. It is RECOMMENDED that security-sensitive or privacy-
sensitive data be modeled as regular YANG data nodes rather than
annotations.
<span class="grey">Lhotka Standards Track [Page 18]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-19" ></span>
<span class="grey"><a href="./rfc7952">RFC 7952</a> YANG Metadata August 2016</span>
<span class="h2"><a class="selflink" id="section-10" href="#section-10">10</a>. References</span>
<span class="h3"><a class="selflink" id="section-10.1" href="#section-10.1">10.1</a>. Normative References</span>
[<a id="ref-RFC2119">RFC2119</a>] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", <a href="https://www.rfc-editor.org/bcp/bcp14">BCP 14</a>, <a href="./rfc2119">RFC 2119</a>,
DOI 10.17487/RFC2119, March 1997,
<<a href="http://www.rfc-editor.org/info/rfc2119">http://www.rfc-editor.org/info/rfc2119</a>>.
[<a id="ref-RFC3688">RFC3688</a>] Mealling, M., "The IETF XML Registry", <a href="https://www.rfc-editor.org/bcp/bcp81">BCP 81</a>, <a href="./rfc3688">RFC 3688</a>,
DOI 10.17487/RFC3688, January 2004,
<<a href="http://www.rfc-editor.org/info/rfc3688">http://www.rfc-editor.org/info/rfc3688</a>>.
[<a id="ref-RFC5234">RFC5234</a>] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, <a href="./rfc5234">RFC 5234</a>,
DOI 10.17487/RFC5234, January 2008,
<<a href="http://www.rfc-editor.org/info/rfc5234">http://www.rfc-editor.org/info/rfc5234</a>>.
[<a id="ref-RFC6020">RFC6020</a>] Bjorklund, M., Ed., "YANG - A Data Modeling Language for
the Network Configuration Protocol (NETCONF)", <a href="./rfc6020">RFC 6020</a>,
DOI 10.17487/RFC6020, October 2010,
<<a href="http://www.rfc-editor.org/info/rfc6020">http://www.rfc-editor.org/info/rfc6020</a>>.
[<a id="ref-RFC6110">RFC6110</a>] Lhotka, L., Ed., "Mapping YANG to Document Schema
Definition Languages and Validating NETCONF Content",
<a href="./rfc6110">RFC 6110</a>, DOI 10.17487/RFC6110, February 2011,
<<a href="http://www.rfc-editor.org/info/rfc6110">http://www.rfc-editor.org/info/rfc6110</a>>.
[<a id="ref-RFC7159">RFC7159</a>] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", <a href="./rfc7159">RFC 7159</a>, DOI 10.17487/RFC7159, March
2014, <<a href="http://www.rfc-editor.org/info/rfc7159">http://www.rfc-editor.org/info/rfc7159</a>>.
[<a id="ref-RFC7950">RFC7950</a>] Bjorklund, M., Ed., "The YANG 1.1 Data Modeling Language",
<a href="./rfc7950">RFC 7950</a>, DOI 10.17487/RFC7950, August 2016,
<<a href="http://www.rfc-editor.org/info/rfc7950">http://www.rfc-editor.org/info/rfc7950</a>>.
[<a id="ref-RFC7951">RFC7951</a>] Lhotka, L., "JSON Encoding of Data Modeled with YANG",
<a href="./rfc7951">RFC 7951</a>, DOI 10.17487/RFC7951, August 2016,
<<a href="http://www.rfc-editor.org/info/rfc7951">http://www.rfc-editor.org/info/rfc7951</a>>.
[<a id="ref-XML-INFOSET">XML-INFOSET</a>]
Cowan, J. and R. Tobin, "XML Information Set (Second
Edition)", World Wide Web Consortium Recommendation
REC-xml-infoset-20040204, February 2004,
<<a href="http://www.w3.org/TR/2004/REC-xml-infoset-20040204">http://www.w3.org/TR/2004/REC-xml-infoset-20040204</a>>.
<span class="grey">Lhotka Standards Track [Page 19]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-20" ></span>
<span class="grey"><a href="./rfc7952">RFC 7952</a> YANG Metadata August 2016</span>
[<a id="ref-XML-NAMES">XML-NAMES</a>]
Bray, T., Hollander, D., Layman, A., Tobin, R., and H.
Thompson, "Namespaces in XML 1.0 (Third Edition)", World
Wide Web Consortium Recommendation REC-xml-names-20091208,
December 2009,
<<a href="http://www.w3.org/TR/2009/REC-xml-names-20091208">http://www.w3.org/TR/2009/REC-xml-names-20091208</a>>.
<span class="h3"><a class="selflink" id="section-10.2" href="#section-10.2">10.2</a>. Informative References</span>
[<a id="ref-ISO.19757-1">ISO.19757-1</a>]
International Organization for Standardization,
"Information Technology - Document Schema Definition
Languages (DSDL) - Part 1: Overview", ISO/IEC 19757-1,
September 2008.
[<a id="ref-ISO.19757-2">ISO.19757-2</a>]
International Organization for Standardization,
"Information technology -- Document Schema Definition
Language (DSDL) -- Part 2: Regular-grammar-based
validation -- RELAX NG", ISO/IEC 19757-2:2008, December
2008.
[<a id="ref-ISO.19757-3">ISO.19757-3</a>]
International Organization for Standardization,
"Information technology -- Document Schema Definition
Languages (DSDL) -- Part 3: Rule-based validation --
Schematron", ISO/IEC 19757-3:2016, January 2016.
[<a id="ref-ISO.19757-8">ISO.19757-8</a>]
International Organization for Standardization,
"Information Technology - Document Schema Definition
Languages (DSDL) - Part 8: Document Semantics Renaming
Language - DSRL", ISO/IEC 19757-8:2008(E), December 2008.
[<a id="ref-RESTCONF">RESTCONF</a>] Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF
Protocol", Work in Progress,
<a href="./draft-ietf-netconf-restconf-16">draft-ietf-netconf-restconf-16</a>, August 2016.
[<a id="ref-RFC6241">RFC6241</a>] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", <a href="./rfc6241">RFC 6241</a>, DOI 10.17487/RFC6241, June 2011,
<<a href="http://www.rfc-editor.org/info/rfc6241">http://www.rfc-editor.org/info/rfc6241</a>>.
<span class="grey">Lhotka Standards Track [Page 20]</span></pre>
<hr class='noprint'/><!--NewPage--><pre class='newpage'><span id="page-21" ></span>
<span class="grey"><a href="./rfc7952">RFC 7952</a> YANG Metadata August 2016</span>
Acknowledgements
The author wishes to thank Andy Bierman, Martin Bjorklund, Benoit
Claise, Juergen Schoenwaelder, and Kent Watsen for their helpful
comments and suggestions.
Author's Address
Ladislav Lhotka
CZ.NIC
Email: lhotka@nic.cz
Lhotka Standards Track [Page 21]
</pre>
|
