File: rfc3216.txt

package info (click to toggle)
doc-rfc 20181229-2
  • links: PTS, VCS
  • area: non-free
  • in suites: buster
  • size: 570,944 kB
  • sloc: xml: 285,646; sh: 107; python: 90; perl: 42; makefile: 14
file content (1851 lines) | stat: -rw-r--r-- 58,551 bytes parent folder | download | duplicates (5)
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
1174
1175
1176
1177
1178
1179
1180
1181
1182
1183
1184
1185
1186
1187
1188
1189
1190
1191
1192
1193
1194
1195
1196
1197
1198
1199
1200
1201
1202
1203
1204
1205
1206
1207
1208
1209
1210
1211
1212
1213
1214
1215
1216
1217
1218
1219
1220
1221
1222
1223
1224
1225
1226
1227
1228
1229
1230
1231
1232
1233
1234
1235
1236
1237
1238
1239
1240
1241
1242
1243
1244
1245
1246
1247
1248
1249
1250
1251
1252
1253
1254
1255
1256
1257
1258
1259
1260
1261
1262
1263
1264
1265
1266
1267
1268
1269
1270
1271
1272
1273
1274
1275
1276
1277
1278
1279
1280
1281
1282
1283
1284
1285
1286
1287
1288
1289
1290
1291
1292
1293
1294
1295
1296
1297
1298
1299
1300
1301
1302
1303
1304
1305
1306
1307
1308
1309
1310
1311
1312
1313
1314
1315
1316
1317
1318
1319
1320
1321
1322
1323
1324
1325
1326
1327
1328
1329
1330
1331
1332
1333
1334
1335
1336
1337
1338
1339
1340
1341
1342
1343
1344
1345
1346
1347
1348
1349
1350
1351
1352
1353
1354
1355
1356
1357
1358
1359
1360
1361
1362
1363
1364
1365
1366
1367
1368
1369
1370
1371
1372
1373
1374
1375
1376
1377
1378
1379
1380
1381
1382
1383
1384
1385
1386
1387
1388
1389
1390
1391
1392
1393
1394
1395
1396
1397
1398
1399
1400
1401
1402
1403
1404
1405
1406
1407
1408
1409
1410
1411
1412
1413
1414
1415
1416
1417
1418
1419
1420
1421
1422
1423
1424
1425
1426
1427
1428
1429
1430
1431
1432
1433
1434
1435
1436
1437
1438
1439
1440
1441
1442
1443
1444
1445
1446
1447
1448
1449
1450
1451
1452
1453
1454
1455
1456
1457
1458
1459
1460
1461
1462
1463
1464
1465
1466
1467
1468
1469
1470
1471
1472
1473
1474
1475
1476
1477
1478
1479
1480
1481
1482
1483
1484
1485
1486
1487
1488
1489
1490
1491
1492
1493
1494
1495
1496
1497
1498
1499
1500
1501
1502
1503
1504
1505
1506
1507
1508
1509
1510
1511
1512
1513
1514
1515
1516
1517
1518
1519
1520
1521
1522
1523
1524
1525
1526
1527
1528
1529
1530
1531
1532
1533
1534
1535
1536
1537
1538
1539
1540
1541
1542
1543
1544
1545
1546
1547
1548
1549
1550
1551
1552
1553
1554
1555
1556
1557
1558
1559
1560
1561
1562
1563
1564
1565
1566
1567
1568
1569
1570
1571
1572
1573
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584
1585
1586
1587
1588
1589
1590
1591
1592
1593
1594
1595
1596
1597
1598
1599
1600
1601
1602
1603
1604
1605
1606
1607
1608
1609
1610
1611
1612
1613
1614
1615
1616
1617
1618
1619
1620
1621
1622
1623
1624
1625
1626
1627
1628
1629
1630
1631
1632
1633
1634
1635
1636
1637
1638
1639
1640
1641
1642
1643
1644
1645
1646
1647
1648
1649
1650
1651
1652
1653
1654
1655
1656
1657
1658
1659
1660
1661
1662
1663
1664
1665
1666
1667
1668
1669
1670
1671
1672
1673
1674
1675
1676
1677
1678
1679
1680
1681
1682
1683
1684
1685
1686
1687
1688
1689
1690
1691
1692
1693
1694
1695
1696
1697
1698
1699
1700
1701
1702
1703
1704
1705
1706
1707
1708
1709
1710
1711
1712
1713
1714
1715
1716
1717
1718
1719
1720
1721
1722
1723
1724
1725
1726
1727
1728
1729
1730
1731
1732
1733
1734
1735
1736
1737
1738
1739
1740
1741
1742
1743
1744
1745
1746
1747
1748
1749
1750
1751
1752
1753
1754
1755
1756
1757
1758
1759
1760
1761
1762
1763
1764
1765
1766
1767
1768
1769
1770
1771
1772
1773
1774
1775
1776
1777
1778
1779
1780
1781
1782
1783
1784
1785
1786
1787
1788
1789
1790
1791
1792
1793
1794
1795
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1811
1812
1813
1814
1815
1816
1817
1818
1819
1820
1821
1822
1823
1824
1825
1826
1827
1828
1829
1830
1831
1832
1833
1834
1835
1836
1837
1838
1839
1840
1841
1842
1843
1844
1845
1846
1847
1848
1849
1850
1851






Network Working Group                                         C. Elliott
Request for Comments: 3216                                 Cisco Systems
Category: Informational                                    D. Harrington
                                                      Enterasys Networks
                                                                J. Jason
                                                       Intel Corporation
                                                        J. Schoenwaelder
                                                              F. Strauss
                                                         TU Braunschweig
                                                                W. Weiss
                                                       Ellacoya Networks
                                                           December 2001


                            SMIng Objectives

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

Abstract

   This document describes the objectives for a new data definition
   language, suitable for the modeling of network management constructs,
   that can be directly mapped into SNMP and COPS-PR protocol
   operations.

   The purpose of this document is to serve as a set of objectives that
   a subsequent language specification should try to address.  It
   captures the results of the working group discussions towards
   consensus on the SMIng objectives.

Table of Contents

   1.     Introduction . . . . . . . . . . . . . . . . . . . . . . .   3
   2.     Motivation . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.     Background . . . . . . . . . . . . . . . . . . . . . . . .   4
   4.     Specific Objectives for SMIng  . . . . . . . . . . . . . .   4
   4.1    Accepted Objectives  . . . . . . . . . . . . . . . . . . .   5
   4.1.1  The Set of Specification Documents . . . . . . . . . . . .   6
   4.1.2  Textual Representation . . . . . . . . . . . . . . . . . .   6
   4.1.3  Human Readability  . . . . . . . . . . . . . . . . . . . .   6



Elliott, et al.              Informational                      [Page 1]

RFC 3216                    SMIng Objectives               December 2001


   4.1.4  Rigorously Defined Syntax  . . . . . . . . . . . . . . . .   6
   4.1.5  Accessibility  . . . . . . . . . . . . . . . . . . . . . .   7
   4.1.6  Language Extensibility . . . . . . . . . . . . . . . . . .   7
   4.1.7  Special Characters in Text . . . . . . . . . . . . . . . .   7
   4.1.8  Naming . . . . . . . . . . . . . . . . . . . . . . . . . .   8
   4.1.9  Namespace Control  . . . . . . . . . . . . . . . . . . . .   8
   4.1.10 Modules  . . . . . . . . . . . . . . . . . . . . . . . . .   8
   4.1.11 Module Conformance . . . . . . . . . . . . . . . . . . . .   9
   4.1.12 Arbitrary Unambiguous Identities . . . . . . . . . . . . .   9
   4.1.13 Protocol Independence  . . . . . . . . . . . . . . . . . .   9
   4.1.14 Protocol Mapping . . . . . . . . . . . . . . . . . . . . .  10
   4.1.15 Translation to Other Data Definition Languages . . . . . .  10
   4.1.16 Base Data Types  . . . . . . . . . . . . . . . . . . . . .  10
   4.1.17 Enumerations . . . . . . . . . . . . . . . . . . . . . . .  11
   4.1.18 Discriminated Unions . . . . . . . . . . . . . . . . . . .  11
   4.1.19 Instance Pointers  . . . . . . . . . . . . . . . . . . . .  11
   4.1.20 Row Pointers . . . . . . . . . . . . . . . . . . . . . . .  12
   4.1.21 Constraints on Pointers  . . . . . . . . . . . . . . . . .  12
   4.1.22 Base Type Set  . . . . . . . . . . . . . . . . . . . . . .  12
   4.1.23 Extended Data Types  . . . . . . . . . . . . . . . . . . .  12
   4.1.24 Units, Formats, and Default Values of Defined Types and
          Attributes . . . . . . . . . . . . . . . . . . . . . . . .  13
   4.1.25 Table Existence Relationships  . . . . . . . . . . . . . .  13
   4.1.26 Table Existence Relationships (2)  . . . . . . . . . . . .  14
   4.1.27 Attribute Groups . . . . . . . . . . . . . . . . . . . . .  14
   4.1.28 Containment  . . . . . . . . . . . . . . . . . . . . . . .  14
   4.1.29 Single Inheritance . . . . . . . . . . . . . . . . . . . .  15
   4.1.30 Reusable vs. Final Attribute Groups  . . . . . . . . . . .  15
   4.1.31 Events . . . . . . . . . . . . . . . . . . . . . . . . . .  16
   4.1.32 Creation/Deletion  . . . . . . . . . . . . . . . . . . . .  16
   4.1.33 Range and Size Constraints . . . . . . . . . . . . . . . .  16
   4.1.34 Uniqueness . . . . . . . . . . . . . . . . . . . . . . . .  16
   4.1.35 Extension Rules  . . . . . . . . . . . . . . . . . . . . .  17
   4.1.36 Deprecate Use of IMPLIED Keyword . . . . . . . . . . . . .  17
   4.1.37 No Redundancy  . . . . . . . . . . . . . . . . . . . . . .  17
   4.1.38 Compliance and Conformance . . . . . . . . . . . . . . . .  17
   4.1.39 Allow Refinement of All Definitions in Conformance
          Statements . . . . . . . . . . . . . . . . . . . . . . . .  18
   4.1.40 Categories . . . . . . . . . . . . . . . . . . . . . . . .  18
   4.1.41 Core Language Keywords vs. Defined Identifiers . . . . . .  19
   4.1.42 Instance Naming  . . . . . . . . . . . . . . . . . . . . .  19
   4.1.43 Length of Identifiers  . . . . . . . . . . . . . . . . . .  19
   4.1.44 Assign OIDs in the Protocol Mappings . . . . . . . . . . .  20
   4.2    Nice-to-Have Objectives  . . . . . . . . . . . . . . . . .  20
   4.2.1  Methods  . . . . . . . . . . . . . . . . . . . . . . . . .  20
   4.2.2  Unions . . . . . . . . . . . . . . . . . . . . . . . . . .  21
   4.2.3  Float Data Types . . . . . . . . . . . . . . . . . . . . .  21
   4.2.4  Comments . . . . . . . . . . . . . . . . . . . . . . . . .  22



Elliott, et al.              Informational                      [Page 2]

RFC 3216                    SMIng Objectives               December 2001


   4.2.5  Referencing Tagged Rows  . . . . . . . . . . . . . . . . .  22
   4.2.6  Arrays . . . . . . . . . . . . . . . . . . . . . . . . . .  22
   4.2.7  Internationalization . . . . . . . . . . . . . . . . . . .  23
   4.2.8  Separate Data Modelling from Management Protocol Mapping .  23
   4.3    Rejected Objectives  . . . . . . . . . . . . . . . . . . .  24
   4.3.1  Incomplete Translations  . . . . . . . . . . . . . . . . .  24
   4.3.2  Attribute Value Constraints  . . . . . . . . . . . . . . .  24
   4.3.3  Attribute Transaction Constraints  . . . . . . . . . . . .  25
   4.3.4  Method Constraints . . . . . . . . . . . . . . . . . . . .  25
   4.3.5  Agent Capabilities . . . . . . . . . . . . . . . . . . . .  25
   4.3.6  Relationships  . . . . . . . . . . . . . . . . . . . . . .  26
   4.3.7  Procedures . . . . . . . . . . . . . . . . . . . . . . . .  26
   4.3.8  Associations . . . . . . . . . . . . . . . . . . . . . . .  26
   4.3.9  Association Cardinalities  . . . . . . . . . . . . . . . .  27
   4.3.10 Categories of Modules  . . . . . . . . . . . . . . . . . .  27
   4.3.11 Mapping Modules to Files . . . . . . . . . . . . . . . . .  27
   4.3.12 Simple Grammar . . . . . . . . . . . . . . . . . . . . . .  28
   4.3.13 Place of Module Information  . . . . . . . . . . . . . . .  28
   4.3.14 Module Namespace . . . . . . . . . . . . . . . . . . . . .  29
   4.3.15 Hyphens in Identifiers . . . . . . . . . . . . . . . . . .  29
   5.     Security Considerations  . . . . . . . . . . . . . . . . .  30
   6.     Acknowledgements . . . . . . . . . . . . . . . . . . . . .  30
   7.     References . . . . . . . . . . . . . . . . . . . . . . . .  30
   8.     Authors' Addresses . . . . . . . . . . . . . . . . . . . .  31
   9.     Full Copyright Statement . . . . . . . . . . . . . . . . .  33

1. Introduction

   This document describes the objectives for a new data definition
   language that can be mapped into SNMP [1], [2] and COPS-PR [3]
   protocol operations.  It may also be translated into SMIv2 [4], [5],
   [6] MIBs and SPPI [7] PIBs.  Concepts such as attributes, attribute
   groups, methods, conventions for organization into reusable data
   structures, and mechanisms for representing relationships are
   discussed.

2. Motivation

   As networking technology has evolved, a diverse set of technologies
   has been deployed to manage the resulting products.  These vary from
   Web based products, to standard management protocols and text
   scripts.  The underlying systems to be manipulated are represented in
   varying ways including implicitly in the system programming, via
   proprietary data descriptions, or with standardized descriptions
   using a range of technologies including MIBs, PIBs, or LDAP schemas.
   The result is that management interfaces for network protocols,
   services, and applications such as Differentiated Services may be
   represented in many different, inconsistent fashions.



Elliott, et al.              Informational                      [Page 3]

RFC 3216                    SMIng Objectives               December 2001


   The SMIng working group has been chartered to define a new data
   definition language that will eliminate the need for a separate SMIv2
   and SPPI language.  That is, the new language should address the
   needs for the current SMIv2 and SPPI languages so that over time we
   can all use the new language instead.

   Another motivation is to permit a more expressive and complete
   representation of the modeled information.  Examples of additional
   expressiveness and completeness that are considered are the ability
   to formally define table existence relationships, the expression of
   instance creation/deletion capabilities, and the ability to define
   attribute groups using inheritance.  These additional features are
   discussed in subsequent sections.

   It has been recognized that the two main goals of (a) merging
   SMIv2/SPPI and (b) enhancing the state of art in network management
   data modeling can lead to conflicts.  In such cases, the SMIng
   working group's consensus is to focus on enhancing the state of art
   in network management data modeling.

3. Background

   The Network Management Research Group (NMRG) of the Internet Research
   Task Force (IRTF) has researched the issues of creating a protocol-
   independent data definition language that could be used by multiple
   protocols.  Because SMIv2 and SPPI are very similar, the NMRG focused
   on merging these two languages, but also researched ways to abstract
   the objectives to produce a language that could be used for other
   protocols, such as LDAP and Diameter.  The NMRG has published the
   results of their work in a meanwhile expired Internet Draft, but has
   submitted their specification as one proposal to consider in the
   development of the SMIng language.

   The SMIng Working Group has accepted their submission for
   consideration, and to use their proposal to better understand the
   objectives and possible obstacles to be overcome.  Where useful, the
   NMRG proposal has been referenced in the details below.

4. Specific Objectives for SMIng

   The following sections define the objectives for the definition of a
   new data definition language.  The objectives have been organized as
   follows: accepted objectives (Section 4.1), nice-to-have objectives
   (Section 4.2), and rejected objectives (Section 4.3).  Each objective
   has the following information:

   o  Type: a field that identifies the type of objective, using one of
      the following values:



Elliott, et al.              Informational                      [Page 4]

RFC 3216                    SMIng Objectives               December 2001


      *  basic: considered a basic objective for SMIng and is contained
         in SMIv2 and/or SPPI.

      *  align: supported in different ways in SMIv2 and SPPI and they
         must be aligned.

      *  fix: considered a fix for a known problem in SMIv2 and/or SPPI.

      *  new: considered a new feature.

   o  From: a field that defines the origin of the objective and that
      contains one or more of the following values:

      *  SMI: exists in SMIv2.

      *  SPPI: exists in SPPI.

      *  NMRG: exists in the NMRG proposal, but not in SMIv2 or SPPI.

      *  Charter: exists in working group charter.

      *  WG: proposed during working group discussions.

   o  Description: a quick description of the objective.

   o  Motivation: rationale for the objective.

   o  Notes: optional notes about an objective.  For example, for nice-
      to-have or rejected this may contain reasoning why this objective
      is not required by the SMIng working group, but justification why
      it should be considered anyway.  Notes may be the opinions of the
      participants in the discussion on objectives and as such should
      not be taken as consensus of the working group or the
      recommendation of the objectives editing team.

4.1 Accepted Objectives

   This section represents the list of objectives that have been
   accepted by the SMIng working group as worthwhile and therefore
   deserving of further consideration.  Each of these objectives must be
   evaluated by the working group to determine if the benefit incurs an
   acceptable level of cost.  An accepted objective may subsequently be
   rejected if the cost/benefit analysis determines that the benefit
   does not justify the cost or that the objective is in direct conflict
   with one or more other accepted objectives that are deemed more
   important.





Elliott, et al.              Informational                      [Page 5]

RFC 3216                    SMIng Objectives               December 2001


4.1.1 The Set of Specification Documents

   Type: new

   From: NMRG

   Description: SMIv2 is defined in three documents, based on an
      obsolete ITU ASN.1 specification.  SPPI is defined in one
      document, based on SMIv2.  The core of SMIng must be defined in
      one document and must be independent of external specifications.

   Motivation: Self-containment.

4.1.2 Textual Representation

   Type: basic

   From: SMI, SPPI, WG

   Description: SMIng definitions must be represented in a textual
      format.

   Motivation: General IETF consensus.

4.1.3 Human Readability

   Type: basic

   From: WG

   Description: The syntax must make it easy for humans to directly read
      and write SMIng modules.  It must be possible for SMIng module
      authors to produce SMIng modules with text editing tools.

   Motivation: The syntax must make it easy for humans to read and write
      SMIng modules.

4.1.4 Rigorously Defined Syntax

   Type: new

   From: NMRG

   Description: There must be a rigorously defined syntax for the SMIng
      language.






Elliott, et al.              Informational                      [Page 6]

RFC 3216                    SMIng Objectives               December 2001


   Motivation: An unambiguous language promotes consistency across
      vendors so that different parsers produce the same results.  It
      also provides authoritative rules to SMIng modules designers.

4.1.5 Accessibility

   Type: align

   From: SMI, SPPI

   Description: Attribute definitions must indicate whether attributes
      can be read, written, created, deleted, and whether they are
      accessible for notifications, or are not accessible.  Align PIB-
      ACCESS and MAX-ACCESS, and PIB-MIN-ACCESS and MIN-ACCESS.

   Motivation: Alignment of SMIv2 and SPPI.

4.1.6 Language Extensibility

   Type: new

   From: NMRG

   Description: The language must have characteristics, so that future
      modules can contain information of future syntax without breaking
      original SMIng parsers.

      E.g., when SMIv2 introduced REFERENCEs it would have been nice if
      it would not have broken SMIv1 parsers.

   Motivation: Achieve language extensibility without breaking core
      compatibility.

4.1.7 Special Characters in Text

   Type: new

   From: WG

   Description: Allow an escaping mechanism to encode special
      characters, e.g. double quotes and new-line characters, in text
      such as DESCRIPTIONs or REFERENCEs.

   Motivation: ABNF can contain literal characters enclosed in double
      quotes; to provide the ABNF grammar, there must be the ability to
      escape special characters.





Elliott, et al.              Informational                      [Page 7]

RFC 3216                    SMIng Objectives               December 2001


4.1.8 Naming

   Type: basic

   From: SMI, SPPI

   Description: SMIng must provide mechanisms to uniquely identify
      attributes, groups of attributes, and events.  It is necessary to
      specify how name collisions are handled.

   Motivation: Already in SMIv2 and SPPI.

4.1.9 Namespace Control

   Type: basic

   From: SMI, SPPI

   Description: There must be a hierarchical, centrally-controlled
      namespace for standard named items, and a distributed namespace
      must be supported to allow vendor-specific naming and to assure
      unique module names across vendors and organizations.

   Motivation: Need to unambiguously identify definitions of various
      kinds.  Some SMI implementations have problems with different
      objects from multiple modules but with the same name.
      Furthermore, the probability of module name clashes rises over
      time (for example, different vendors defining their own SYSTEM-
      MIB).

   Notes: An example naming scheme is the one employed by the Java
      programming language with a central naming authority assigning the
      top-level names.

4.1.10 Modules

   Type: basic

   From: SMI, SPPI

   Description: SMIng must provide a mechanism for uniquely identifying
      a module, and specifying the status, contact person, revision
      information, and the purpose of a module.

      SMIng must provide mechanisms to group definitions into modules
      and it must provide rules for referencing definitions from other
      modules.




Elliott, et al.              Informational                      [Page 8]

RFC 3216                    SMIng Objectives               December 2001


   Motivation: Modularity and independent advancement of documents.

   Notes: Text about module conformance has been moved to Section
      4.1.11.

4.1.11 Module Conformance

   Type: basic

   From: SMI, SPPI

   Description: SMIng must provide mechanisms to detail the minimum
      requirements implementers must meet to claim conformance to a
      standard based on the module.

   Motivation: Ability to convey conformance requirements.

4.1.12 Arbitrary Unambiguous Identities

   Type: basic

   From: SMI

   Description: SMI allows the use of OBJECT-IDENTITIES to define
      unambiguous identities without the need of a central registry.
      SMI uses OIDs to represent values that represent references to
      such identities.  SMIng needs a similar mechanism (a statement to
      register identities, and a base type to represent values).

   Motivation: SMI Compatibility.

   Notes: This is an obvious objective.  Additionally, everything not on
      the wire, such as modules, will still be assigned OIDs.

      It is yet to be determined whether the assignment of the OID
      occurs within the core or within a protocol-specific mapping.

4.1.13 Protocol Independence

   Type: basic

   From: Charter

   Description: SMIng must define data definitions in support of the
      SNMP and COPS-PR protocols.  SMIng may define data definitions in
      support of other protocols.





Elliott, et al.              Informational                      [Page 9]

RFC 3216                    SMIng Objectives               December 2001


   Motivation: So data definitions may be used with multiple protocols
      and multiple versions of those protocols.

4.1.14 Protocol Mapping

   Type: basic

   From: Charter

   Description: The SMIng working group, in accordance with the working
      group charter, will define mappings of protocol independent data
      definitions to protocols based upon installed implementations.
      The SMIng working group can define mappings to other protocols as
      long as this does not impede the progress on other objectives.

   Motivation: SMIng working group charter.

4.1.15 Translation to Other Data Definition Languages

   Type: basic

   From: Charter

   Description: SMIng language constructs must, wherever possible, be
      translatable to SMIv2 and SPPI.  At the time of standardization of
      a SMIng language, existing SMIv2 MIBs and SPPI PIBs on the
      standards track will not be required to be translated to the SMIng
      language.  New MIBs/PIBs will be defined using the SMIng language.

   Motivation: Provide best-effort backwards compatibility for existing
      tools while not placing an unnecessary burden on MIBs/PIBs that
      are already on the standards track.

4.1.16 Base Data Types

   Type: basic

   From: SMI, SPPI

   Description: SMIng must support the base data types Integer32,
      Unsigned32, Integer64, Unsigned64, Enumeration, Bits, OctetString,
      and OID.

   Motivation: Most are already common.  Unsigned64 and Integer64 are in
      SPPI, must fix in SMI.  Note that Counter and Gauge types can be
      regarded as derived types instead of base types.





Elliott, et al.              Informational                     [Page 10]

RFC 3216                    SMIng Objectives               December 2001


4.1.17 Enumerations

   Type: basic

   From: SMI, SPPI

   Description: SMIng must provide support for enumerations.  Enumerated
      values must be a part of the enumeration definition.

   Motivation: SMIv2 already has enumerated numbers.

   Notes: Enumerations have the implicit constraint that the attribute
      is constrained to the values for the enumeration.

4.1.18 Discriminated Unions

   Type: new

   From: WG

   Description: SMIng must support discriminated unions.

   Motivation: Allows to group related attributes together, such as
      InetAddressType (discriminator) and InetAddress, InetAddressIPv4,
      InetAddressIPv6 (union).  The lack of discriminated unions has
      also lead to relatively complex sparse table work-around in some
      DISMAN mid-level manager MIBs.

   Notes: Discriminated unions have the property that the union
      attribute type is constrained by the value of the discriminator
      attribute.

4.1.19 Instance Pointers

   Type: basic

   From: SMI, SPPI

   Description: SMIng must allow specifying pointers to instances (i.e.,
      a pointer to a particular attribute in a row).

   Motivation: It is common practice in MIBs and PIBs to point to other
      instances.








Elliott, et al.              Informational                     [Page 11]

RFC 3216                    SMIng Objectives               December 2001


4.1.20 Row Pointers

   Type: align

   From: SMI, SPPI

   Description: SMIng must allow specifying pointers to rows.

   Motivation: It is common practice in MIBs and PIBs to point to other
      rows (see RowPointer, PIB-REFERENCES).

4.1.21 Constraints on Pointers

   Type: align

   From: SPPI

   Description: SMIng must allow specifying the types of objects to
      which a pointer may point.

   Motivation: Allows code generators to detect and reject illegal
      pointers automatically.  Can also be used to automatically
      generate more reasonable implementation-specific data structures.

   Notes: Pointer constraints are a special case of attribute value
      constraints (Section 4.3.2) in which the prefix of the OID (row or
      instance pointer) value is limited to be only from a particular
      table.

4.1.22 Base Type Set

   Type: basic

   From: SMI, SPPI

   Description: SMIng must support a fixed set of base types of fixed
      size and precision.  The list of base types must not be extensible
      unless the SMI itself changes.

   Motivation: Interoperability.

4.1.23 Extended Data Types

   Type: align

   From: SMI, SPPI





Elliott, et al.              Informational                     [Page 12]

RFC 3216                    SMIng Objectives               December 2001


   Description: SMIng must support a mechanism to derive new types,
      which provide additional semantics (e.g., Counters, Gauges,
      Strings, etc.), from base types.  It may be desirable to also
      allow the derivation of new types from derived types.  New types
      must be as restrictive or more restrictive than the types that
      they are specializing.

   Motivation: SMI uses application types and textual conventions.  SPPI
      uses derived types.

4.1.24 Units, Formats, and Default Values of Defined Types and
       Attributes

   Type: fix

   From: NMRG

   Description: In SMIv2 OBJECT-TYPE definitions may contain UNITS and
      DEFVAL clauses and TEXTUAL-CONVENTIONs may contain DISPLAY-HINTs.
      In a similar fashion units and default values must be applicable
      to defined types and format information must be applicable to
      attributes.

   Motivation: Some MIBs introduce TCs such as KBytes and every usage of
      the TC then specifies the UNITS "KBytes".  It would simplify
      things if the UNITS were attached to the type definition itself.

   Notes: The SMIng WG must clarify the behavior if an attribute uses a
      defined type and both, the attribute and the defined type, have
      units/default/format information.

4.1.25 Table Existence Relationships

   Type: align

   From: SMI, SPPI

   Description: SMIng must support INDEX, AUGMENTS, and EXTENDS in the
      SNMP/COPS-PR protocol mappings.

   Motivation: These three table existence relationships exist either in
      the SMIv2 or the SPPI.









Elliott, et al.              Informational                     [Page 13]

RFC 3216                    SMIng Objectives               December 2001


4.1.26 Table Existence Relationships (2)

   Type: new

   From: NMRG

   Description: SMIng must support EXPANDS and REORDERS relationships in
      the SNMP/COPS-PR protocol mappings.

   Motivation: A REORDERS statement allows indexing orders to be
      swapped.  An EXPANDS statement formally states that there is a 1:n
      existence relationship between table rows.

4.1.27 Attribute Groups

   Type: new

   From: NMRG

   Description: An attribute group is a named, reusable set of
      attributes that are meaningful together.  It can be reused as the
      type of attributes in other attribute groups (see also Section
      4.1.28).  This is similar to `structs' in C.

   Motivation: Required to map the same grouping of attributes into SNMP
      and COPS-PR tables.  Allows to do index reordering without having
      to redefine the attribute group.  Allows to group related
      attributes together (e.g. InetAddressType, InetAddress).

      The ability to group attributes provides an indication that the
      attributes are meaningful together.

4.1.28 Containment

   Type: new

   From: NMRG

   Description: SMIng must provide support for the creation of new
      attribute groups from attributes of more basic types and
      potentially other attribute groups.

   Motivation: Simplifies the reuse of attribute groups such as
      InetAddressType and InetAddress pairs.







Elliott, et al.              Informational                     [Page 14]

RFC 3216                    SMIng Objectives               December 2001


   Notes: Containment has the implicit existence constraint that if an
      instance of a contained attribute group exists, then the
      corresponding instance of the containing attribute group must also
      exist.

4.1.29 Single Inheritance

   Type: new

   From: NMRG

   Description: SMIng must provide support for mechanisms to extend
      attribute groups through single inheritance.

   Motivation: Allows to extend attribute groups, like a generic
      DiffServ scheduler, with attributes for a specific scheduler,
      without cut&paste.

   Notes: Single inheritance with multiple levels (e.g., C derives from
      B, and B derives from A) must be allowed.

      Inheritance has the implicit existence constraint that if an
      instance of a derived attribute group exists, then the
      corresponding instance of the base attribute group must also
      exist.

      Inheritance could help to add attributes to an attribute group
      that are specific to a certain protocol mapping and do not appear
      in the protocol-neutral attribute group.

4.1.30 Reusable vs. Final Attribute Groups

   Type: new

   From: NMRG, WG

   Description: SMIng must differentiate between "final" and reusable
      attribute groups, where the reuse of attribute groups covers
      inheritance and containment.

   Motivation: This information gives people more information how
      attribute groups can and should be used.  It hinders them from
      misusing them.

   Notes: This objective attempts to convey the idea that some attribute
      groups are not meant to stand on their own and instead only make
      sense if contained within another attribute group.




Elliott, et al.              Informational                     [Page 15]

RFC 3216                    SMIng Objectives               December 2001


4.1.31 Events

   Type: basic

   From: SMI, SPPI

   Description: SMIng must provide mechanisms to define events which
      identify significant state changes.

   Motivation: These represent the protocol-independent events that lead
      to SMI notifications or SPPI reports.

4.1.32 Creation/Deletion

   Type: align

   From: SMI, SPPI

   Description: SMIng must support a mechanism to define
      creation/deletion operations for instances.  Specific
      creation/deletion errors, such as INSTALL-ERRORS, must be
      supported.

   Motivation: Available for row creation in SMI, and available in SPPI.

4.1.33 Range and Size Constraints

   Type: basic

   From: SMI, SPPI

   Description: SMIng must allow specifying range and size constraints
      where applicable.

   Motivation: The SMI and SPPI both support range and size constraints.

4.1.34 Uniqueness

   Type: basic

   From: SPPI

   Description: SMIng must allow the specification of uniqueness
      constraints on attributes.  SMIng must allow the specification of
      multiple independent uniqueness constraints.






Elliott, et al.              Informational                     [Page 16]

RFC 3216                    SMIng Objectives               December 2001


   Motivation: Knowledge of the uniqueness constraints on attributes
      allows to verify protocol specific mappings (e.g. INDEX clauses).
      The knowledge can also be used by code generators to improve
      generated implementation-specific data structures.

4.1.35 Extension Rules

   Type: basic

   From: SMI, SPPI

   Description: SMIng must provide clear rules how one can extend SMIng
      modules without causing interoperability problems "over the wire".

   Motivation: SMIv2 and SPPI have extension rules.

4.1.36 Deprecate Use of IMPLIED Keyword

   Type: fix

   From: WG

   Description: The SMIng SNMP mapping must deprecate the use of the
      IMPLIED indexing schema.

   Motivation: IMPLIED is confusing and most people don't understand it.
      The solution (IMPLIED) is worse than the problem it is trying to
      solve and therefore for the sake of simplicity, the use of IMPLIED
      should be deprecated.

4.1.37 No Redundancy

   Type: fix

   From: NMRG

   Description: The SMIng language must avoid redundancy.

   Motivation: Remove any textual redundancy for things like table
      entries and SEQUENCE definitions, which only increase
      specifications without providing any value.

4.1.38 Compliance and Conformance

   Type: basic

   From: SMI, SPPI




Elliott, et al.              Informational                     [Page 17]

RFC 3216                    SMIng Objectives               December 2001


   Description: SMIng must provide a mechanism for compliance and
      conformance specifications for protocol-independent definitions as
      well as for protocol mappings.

   Motivation: This capability exists in SMIv2 and SPPI.  The NMRG
      proposal has the ability to express much of this information at
      the protocol-dependent layer.  Some compliance or conformance
      information may be protocol-independent, therefore there is also a
      need to be able to express this information protocol-independent
      part.

4.1.39 Allow Refinement of All Definitions in Conformance Statements

   Type: fix

   From: WG

   Description: SMIv2, RFC 2580, Section 3.1 says:

         The OBJECTS clause, which must be present, is used to specify
         each object contained in the conformance group.  Each of the
         specified objects must be defined in the same information
         module as the OBJECT-GROUP macro appears, and must have a MAX-
         ACCESS clause value of "accessible-for-notify", "read-only",
         "read-write", or "read-create".

      The last sentence forbids to put a not-accessible INDEX object
      into an OBJECT-GROUP.  Hence, you can not refine its syntax in a
      compliance definition.  For more details, see
      http://www.ibr.cs.tu-bs.de/ietf/smi-errata/

   Motivation: This error should not be repeated in SMIng.

4.1.40 Categories

   Type: basic

   From: SPPI

   Description: SMIng must provide a mechanism to group definitions into
      subject categories.  Concrete instances may only exist in the
      scope of a given subject category or context.

   Motivation: To scope the categories to which a module applies.  In
      SPPI this is used to allow a division of labor between multiple
      client types.





Elliott, et al.              Informational                     [Page 18]

RFC 3216                    SMIng Objectives               December 2001


4.1.41 Core Language Keywords vs. Defined Identifiers

   Type: fix

   From: NMRG

   Description: In SMI and SPPI modules some language keywords (macros
      and a number of basetypes) have to be imported from different SMI
      language defining modules, e.g. OBJECT-TYPE, MODULE-IDENTITY,
      Integer32 must to be imported from SNMPv2-SMI and TEXTUAL-
      CONVENTION must be imported from SNMPv2-TC, if used.  MIB authors
      are continuously confused about these import rules.  In SMIng only
      defined identifiers must be imported.  All SMIng language keywords
      must be implicitly known and there must not be a need to import
      them from any module.

   Motivation: Reduce confusion.  Clarify the set of language keywords.

4.1.42 Instance Naming

   Type: align

   From: SMI, SPPI

   Description: Instance naming in SMIv2 and SPPI is different.  SMIng
      must align the instance naming (either in the protocol neutral
      model or the protocol mappings).

   Motivation: COPS-PR and SNMP have different instance identification
      schemes that must be handled.

   Notes: A solution requires to investigate how close the naming
      schemes dictated by the protocols are.  Perhaps it is feasible to
      have a single instance naming scheme in both SNMP and COPS-PR,
      even though the current SPPI and SMIv2 are different.

4.1.43 Length of Identifiers

   Type: fix

   From: NMRG

   Description: The allowed length of the various kinds of identifiers
      must be extended from the current `should not exceed 32' (maybe
      even from the `must not exceed 64') rule.

   Motivation: Reflect current practice of definitions.




Elliott, et al.              Informational                     [Page 19]

RFC 3216                    SMIng Objectives               December 2001


   Notes: The 32-rule was added back in the days where compilers could
      not deal with long identifiers.  This rule is continuously
      violated these days and it does not make sense to keep it.

4.1.44 Assign OIDs in the Protocol Mappings

   Type: new

   From: NMRG

   Description: SMIng must not assign OIDs to reusable definition of
      attributes, attribute groups, events, etc.  Instead, SNMP and
      COPS-PR mappings must assign OIDs to the mapped items.

   Motivation: Assignment of OIDs in protocol neutral definitions can
      complicate reuse.  OIDs of synonymous attributes are not the same
      in SMI and SPPI definitions.  MIBs and PIBs are already registered
      in different parts of the OID namespace.

4.2 Nice-to-Have Objectives

   This section represents the list of recommended objectives that would
   be nice to have.  However, these are not automatically thought of as
   accepted objectives as, for example, they may entail a non-trivial
   amount of work in underlying protocols to support or they may be
   regarded as less important than other contradicting objectives that
   are accepted.

4.2.1 Methods

   Type: new

   From: WG

   Description: SMIng should support a mechanism to define method
      signatures (parameters, return values, exception) that are
      implemented on agents.

   Motivation: Methods are needed to support the definition of
      operational interfaces such as found in [RFC2925] (ping,
      traceroute and lookup operations).  Also, the ability to define
      constructor/destructor interfaces could address issues such as
      encountered with SNMP's RowStatus solution.

   Notes: Is it possible to do methods without changing the underlying
      protocol?  There is agreement that methods are useful, but
      disagreement upon the impact - one end of the spectrum sees this
      as a documentation tool for existing SNMP capabilities, while the



Elliott, et al.              Informational                     [Page 20]

RFC 3216                    SMIng Objectives               December 2001


      other end sees this as a protocol update, moving forward, to
      natively support methods.  The proposal is to wait and see if this
      is practical to implement as a syntax that is useful and can map
      to the protocol.

4.2.2 Unions

   Type: new

   From: WG

   Description: SMIng should support a standard format for unions.

   Motivation: Allows an attribute to contain one of many types of
      values.  The lack of unions has also lead to relatively complex
      sparse table work-around in some DISMAN mid-level managers.
      Despite from discriminated unions (see Section 4.1.18), this kind
      of union has no accompanied explicit discriminator attribute that
      selects the union's type of value.

   Notes: The thought is that SNMP and COPS-PR can already support
      unions because they do not care about what data type goes with a
      particular OID.

4.2.3 Float Data Types

   Type: new

   From: WG, NMRG

   Description: SMIng should support the base data types Float32,
      Float64, Float128.

   Motivation: Missing base types can hurt later on, because they cannot
      be added without changing the language, even as an SMIng
      extension.  Lesson learned from the SMIv1/v2 debate about
      Counter64/Integer64/...

   Notes: There is no mention as to whether or not the underlying
      protocols will have to natively support float data types.  This is
      left to the mapping.  However, it seems imperative that the float
      data type needs to be added to the set of intrinsic types in the
      SMIng language at the creation of the language as it will be
      impossible to add them later without changing the language.







Elliott, et al.              Informational                     [Page 21]

RFC 3216                    SMIng Objectives               December 2001


4.2.4 Comments

   Type: fix

   From: NMRG

   Description: The syntax of comments should be well defined,
      unambiguous and intuitive to most people, e.g., the C++/Java `//'
      syntax.

   Motivation: ASN.1 Comments (and thus SMI and SPPI comments) have been
      a constant source of confusion.  People use arbitrary lengthy
      strings of dashes (`-----------') in the wrong assumption that
      this is always treated as a comment.  Some implementations try to
      accept these syntactically wrong constructs which even raises
      confusion.  We should get rid of this problem.

   Notes: If the SMIng working group adopts a C-like syntax, then the
      C++/Java single-line comment should be adopted as well.

4.2.5 Referencing Tagged Rows

   Type: align

   From: SPPI

   Description: PIB and MIB row attributes reference a group of entries
      in another table.  SPPI formalizes this by introducing PIB-TAG and
      PIB-REFERENCES clauses.  This functionality should be retained in
      SMIng.

   Motivation: SPPI formalizes tag references.  Some MIBs also use tag
      references (see SNMP-TARGET-MIB in RFC2573) even though SMIv2 does
      not provide a formal notation.

4.2.6 Arrays

   Type: new

   From: WG

   Description: SMIng should allow the definition of a SEQUENCE OF
      attributes or attribute groups (Section 4.1.27).

   Motivation: The desire for the ability to have variable-length,
      multi-valued objects.





Elliott, et al.              Informational                     [Page 22]

RFC 3216                    SMIng Objectives               December 2001


   Notes: Some issues with arrays are still unclear.  As long as there
      are no concepts to solve the problems with access semantics (how
      to achieve atomic access to arbitrary-sized arrays) and their
      mappings to SNMP and COPS-PR protocol operations, arrays cannot be
      more than a nice to have objective.

4.2.7 Internationalization

   Type: new

   From: WG

   Description: Informational text (DESCRIPTION, REFERENCE, ...) should
      allow i18nized encoding, probably UTF-8.

   Motivation: There has been some demand for i18n in the past.  The BCP
      RFC 2277 demands for internationalization.

   Notes: Although English is the language of IETF documents, SMIng
      should allow other languages for private use.

4.2.8 Separate Data Modelling from Management Protocol Mapping

   Type: new

   From: NMRG

   Description: It should be possible to separate the domain specific
      data modelling work from the network management protocol specific
      work.

   Motivation: Today, working groups designing new protocols are forced
      to care about the design of SNMP MIBs and maybe COPR-PR PIBs to
      manage the new protocol.  This means that experts in a specific
      domain are faced with details of at least one foreign (network
      management) technology.  This leads to hard work and long revision
      processes.  It would be a win to separate the task of pure data
      modelling which can be done by the domain experts easily from the
      network management protocol specific mappings.  The mapping to
      SNMP and/or COPS-PR can be done (a) later separately and (b) by
      network management experts.  This required NM expertise no longer
      hinders the progress of the domain specific working groups.









Elliott, et al.              Informational                     [Page 23]

RFC 3216                    SMIng Objectives               December 2001


4.3 Rejected Objectives

   This section represents the list of objectives that were rejected
   during the discussion on the objectives.  Those objectives that have
   been rejected need not be addressed by SMIng.  This does not imply
   that they must not be addressed.

4.3.1 Incomplete Translations

   Type: basic

   From: WG

   Description: Reality sucks.  All information expressed in SMIng may
      not be directly translatable to a MIB or PIB construct, but all
      information should be able to be conveyed in documentation or via
      other mechanisms.

   Motivation: SMIng working group requires this to ease transition.

   Notes: The SMIng language itself cannot require what compilers do
      that translate SMIng into something else.  So this seems to fall
      out of the scope of the current working group charter.

4.3.2 Attribute Value Constraints

   Type: new

   From: WG

   Description: SMIng should provide mechanisms to formally specify
      constraints between values of multiple attributes.

   Motivation: Constraints on attribute values occur where one or more
      attributes may affect the value or range of values for another
      attribute.  One such relationship exists in IPsec, where the type
      of security algorithm determines the range of possible values for
      other attributes such as the corresponding key size.

   Notes: This objective as is has been rejected as too general, and
      therefore virtually impossible to implement.  However, constraints
      that are implicit with discriminated unions (Section 4.1.18),
      enumerated types (Section 4.1.17), pointer constraints (Section
      4.1.21)), etc., are accepted and these implicit constraints are
      mentioned in the respective objectives.






Elliott, et al.              Informational                     [Page 24]

RFC 3216                    SMIng Objectives               December 2001


4.3.3 Attribute Transaction Constraints

   Type: new

   From: WG

   Description: SMIng should provide a mechanism to formally express
      that certain sets of attributes can only be modified in
      combination.

   Motivation: COPS-PR always does operations on table rows in a single
      transaction.  There are SMIv2 attribute combinations that need to
      be modified together (such as InetAddressType, InetAddress).

   Notes: Alternative is to either use Methods (Section 4.2.1) or assume
      that all attributes in an attribute group (Section 4.1.27) are to
      be considered atomic.

4.3.4 Method Constraints

   Type: new

   From: WG

   Description: Method definitions should provide constraints on
      parameters.

   Motivation: None.

   Notes: Unless methods (Section 4.2.1) are done, there is no use for
      this.  Furthermore, this objective has not been motivated by any
      proponent.

4.3.5 Agent Capabilities

   Type: basic

   From: SMI

   Description: SMIng should provide mechanisms to describe agent
      implementations.

   Motivation: To permit manager to determine variations from the
      standard for an implementation.

   Notes: Agent capabilities should not be part of SMIng, but should
      instead be a separate capabilities table.




Elliott, et al.              Informational                     [Page 25]

RFC 3216                    SMIng Objectives               December 2001


4.3.6 Relationships

   Type: new

   From: NMRG, WG

   Description: Ability to formally depict existence dependency, value
      dependency, aggregation, containment, and other relationships
      between attributes or attribute groups.

   Motivation: Helps humans to understand the conceptual model of a
      module.  Helps implementers of MIB compilers to generate more
      `intelligent' code.

   Notes: This objective was deemed too general to be useful and instead
      the individual types of relationship objectives (e.g., pointers,
      inheritance, containment, etc.)  are evaluated on a case-by-case
      basis with the specific relationships deemed useful being included
      as accepted objectives.

4.3.7 Procedures

   Type: new

   From: WG

   Description: SMIng should support a mechanism to formally define
      procedures that are used by managers when interacting with an
      agent.

   Motivation: None.

   Notes: This objective has not been motivated by any proponent.

4.3.8 Associations

   Type: new

   From: WG

   Description: SMIng should provide mechanisms to explicitly specify
      associations.

   Motivation: None.

   Notes: This objective has not been motivated by any proponent.





Elliott, et al.              Informational                     [Page 26]

RFC 3216                    SMIng Objectives               December 2001


4.3.9 Association Cardinalities

   Type: new

   From: WG

   Description: Cardinalities between associations should be formally
      defined.

   Motivation: If you have an association between attribute groups A and
      B, the cardinality of A indicates how many instances of A may be
      associated with a single instance of B.  Our discussions in
      Minneapolis indicated that we want to convey "how many" instances
      are associated in order to define the best mapping algorithm -
      whether a new table, a single pointer, etc.  For example, do we
      use RowPointer or an integer index into another table? Do we map
      to a table that holds instances of the association/relationship
      itself?

   Notes: Without associations (Section 4.3.8), this has no use.

4.3.10 Categories of Modules

   Type: new

   From: WG

   Description: The SMIng documents should give clear guidance on which
      kind of information (with respect to generality, type/attribute
      group/extension/..) should be put in which kind of a module.

      E.g., in SMIv2 we don't like to import Utf8String from SYSAPPL-
      MIB, but we also do not like to introduce a redundant definition.

      A module review process should probably be described that ensures
      that generally useful definitions do not go into device or service
      specific modules.

   Motivation: Bad experience with SMIv2.

   Notes: It is not clear how this can be done with the language to be
      created by SMIng WG.

4.3.11 Mapping Modules to Files

   Type: new

   From: NMRG



Elliott, et al.              Informational                     [Page 27]

RFC 3216                    SMIng Objectives               December 2001


   Description: There should be a clear statement how SMIng modules are
      mapped to files (1:1, n:1?) and how files should be named (by
      module name in case of 1:1 mapping?).

   Motivation: SMI implementations show up a variety of filename
      extensions (.txt, .smi, .my, none).  Some expect all modules in a
      single file, others don't.  This makes it more difficult to
      exchange modules.

   Notes: This is just an implementation detail and is best left to a
      BCP and not made a part of the language definition.

4.3.12 Simple Grammar

   Type: new

   From: NMRG

   Description: The grammar of the language should be as simple as
      possible.  It should be free of exception rules.  A measurement of
      simplicity is shortness of the ABNF grammar.

   Motivation: Ease of implementation.  Ease of learning/understanding.

   Notes: This seems like an obvious objective, however shortness of the
      ABNF grammar is not necessarily a reflection of the simplicity of
      the grammar.

4.3.13 Place of Module Information

   Type: fix

   From: NMRG

   Description: Module specific information (organization, contact,
      description, revision information) should be bound to the module
      itself and not to an artificial node (like SMIv2 MODULE-IDENTITY).

   Motivation: Simplicity and design cleanup.

   Notes: This does not seem to be a problem with the current SMI.
      Although simplification is a good thing, this detail is not
      considered an objective.








Elliott, et al.              Informational                     [Page 28]

RFC 3216                    SMIng Objectives               December 2001


4.3.14 Module Namespace

   Type: new

   From: WG

   Description: Currently the namespace of modules is flat and there is
      no structure in module naming causing the potential risk of name
      clashes.  Possible solutions:

      *  Assume module names are globally unique (just as SMIv1/v2),
         just give some recommendations on module names.

      *  Force all organizations, WGs and vendors to apply a name prefix
         (e.g. CISCO-GAGA-MIB, IETF-DISMAN-SCRIPT-MIB?).

      *  Force enterprises to apply a prefix based on the enterprise
         number (e.g. ENT2021-SOME-MIB).

      *  Put module names in a hierarchical domain based namespace (e.g.
         DISMAN-SCRIPT-MIB.ietf.org).

   Motivation: Reduce risk of module name clashes.

   Notes: Some aspects of this objective overlap with other objectives
      (namespace control (Section 4.1.9)) and other aspects were thought
      best left to a BCP.

4.3.15 Hyphens in Identifiers

   Type: fix

   From: NMRG

   Description: There has been some confusion whether hyphens are
      allowed in SMIv2 identifiers: Module names are allowed to contain
      hyphens.  Node identifiers usually are not.  But for example
      `mib-2' is a frequently used identifier that contains a hyphen due
      to its SMIv1 origin, when hyphen were not disallowed.  Similarly,
      a number of named numbers of enumeration types contain hyphens
      violating an SMIv2 rule.

      SMIng should simply allow hyphens in all kinds of identifiers.  No
      exceptions.

   Motivation: Reduce confusion and exceptions.  Requires, however, that
      implementation mappings properly quote hyphens where appropriate.




Elliott, et al.              Informational                     [Page 29]

RFC 3216                    SMIng Objectives               December 2001


   Notes: This nit-picking is not worth to be subject to the discussion
      on objectives.  However, SMIng should care about the fact that
      compilers have to map SMIng to programming languages where a
      hyphen is a minus and thus not allowed in identifiers.

5. Security Considerations

   This document defines objectives for a language with which to write
   and read descriptions of management information.  The language itself
   has no security impact on the Internet.

6. Acknowledgements

   Thanks to Dave Durham, whose work on the original NIM (Network
   Information Model) draft was used in generating this document.

   Thanks to Andrea Westerinen for her contributions on the original NIM
   requirements and SMIng objectives drafts.

7. References

   [1] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple
       Network Management Protocol (SNMP)", STD 15, RFC 1157, May 1990.

   [2] McCloghrie, K., Case, J., Rose, M. and S. Waldbusser, "Protocol
       Operations for Version 2 of the Simple Network Management
       Protocol (SNMPv2)", RFC 1905, January 1996.

   [3] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, K.,
       Herzog, S., Reichmeyer, F., Yavatkar, R. and A. Smith, "COPS
       Usage for Policy Provisioning (COPS-PR)", RFC 3084, March 2001.

   [4] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
       M. and S. Waldbusser, "Structure of Management Information
       Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.

   [5] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
       M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58,
       RFC 2579, April 1999.

   [6] McCloghrie, K., Perkins, D. and J. Schoenwaelder, "Conformance
       Statements for SMIv2", STD 58, RFC 2580, April 1999.

   [7] McCloghrie, K., Fine, M., Seligson, J., Chan, K., Hahn, S.,
       Sahita, R., Smith, A. and F. Reichmeyer, "Structure of Policy
       Provisioning Information (SPPI)", RFC 3159, August 2001.





Elliott, et al.              Informational                     [Page 30]

RFC 3216                    SMIng Objectives               December 2001


8. Authors' Addresses

   Chris Elliott
   Cisco Systems
   7025 Kit Creek Road
   Research Triangle Park, NC 27709
   USA

   EMail: chelliot@cisco.com


   David Harrington
   Enterasys Networks
   35 Industrial Way
   P.O. Box 5005
   Rochester, NH 03866-5005
   USA

   EMail: dbh@enterasys.com


   Jamie Jason
   Intel Corporation
   MS JF3-206
   2111 NE 25th Ave.
   Hillsboro, OR 97124
   USA

   EMail: jamie.jason@intel.com


   Juergen Schoenwaelder
   TU Braunschweig
   Muehlenpfordtstr. 23
   38106 Braunschweig
   Germany

   EMail: schoenw@ibr.cs.tu-bs.de
   URI:   http://www.ibr.cs.tu-bs.de/












Elliott, et al.              Informational                     [Page 31]

RFC 3216                    SMIng Objectives               December 2001


   Frank Strauss
   TU Braunschweig
   Muehlenpfordtstr. 23
   38106 Braunschweig
   Germany

   EMail: strauss@ibr.cs.tu-bs.de
   URI:   http://www.ibr.cs.tu-bs.de/


   Walter Weiss
   Ellacoya Networks
   7 Henry Clay Dr.
   Merrimack, NH. 03054
   USA

   EMail: wweiss@ellacoya.com


































Elliott, et al.              Informational                     [Page 32]

RFC 3216                    SMIng Objectives               December 2001


9. Full Copyright Statement

   Copyright (C) The Internet Society (2001).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Elliott, et al.              Informational                     [Page 33]