File: rfc2275.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 (2019 lines) | stat: -rw-r--r-- 77,998 bytes parent folder | download | duplicates (8)
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
1852
1853
1854
1855
1856
1857
1858
1859
1860
1861
1862
1863
1864
1865
1866
1867
1868
1869
1870
1871
1872
1873
1874
1875
1876
1877
1878
1879
1880
1881
1882
1883
1884
1885
1886
1887
1888
1889
1890
1891
1892
1893
1894
1895
1896
1897
1898
1899
1900
1901
1902
1903
1904
1905
1906
1907
1908
1909
1910
1911
1912
1913
1914
1915
1916
1917
1918
1919
1920
1921
1922
1923
1924
1925
1926
1927
1928
1929
1930
1931
1932
1933
1934
1935
1936
1937
1938
1939
1940
1941
1942
1943
1944
1945
1946
1947
1948
1949
1950
1951
1952
1953
1954
1955
1956
1957
1958
1959
1960
1961
1962
1963
1964
1965
1966
1967
1968
1969
1970
1971
1972
1973
1974
1975
1976
1977
1978
1979
1980
1981
1982
1983
1984
1985
1986
1987
1988
1989
1990
1991
1992
1993
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019






Network Working Group                                          B. Wijnen
Request for Comments: 2275                     IBM T. J. Watson Research
Obsoletes: 2265                                               R. Presuhn
Category: Standards Track                             BMC Software, Inc.
                                                           K. McCloghrie
                                                     Cisco Systems, Inc.
                                                            January 1998

             View-based Access Control Model (VACM) for the
               Simple Network Management Protocol (SNMP)

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

IANA Note

   Due to a clerical error in the assignment of the snmpModules in this
   memo, this RFC provides the corrected number assignment for this
   protocol.  This memo obsoletes RFC 2265.

Abstract

   This document describes the View-based Access Control Model for use
   in the SNMP architecture [RFC2271].  It defines the Elements of
   Procedure for controlling access to management information.  This
   document also includes a MIB for remotely managing the configuration
   parameters for the View-based Access Control Model.

Table of Contents

   1.  Introduction                                             2
   1.2.  Access Control                                         3
   1.3.  Local Configuration Datastore                          3
   2.  Elements of the Model                                    3
   2.1.  Groups                                                 3
   2.2.  securityLevel                                          4
   2.3.  Contexts                                               4
   2.4.  MIB Views and View Families                            4
   2.4.1.  View Subtree                                         5



Wijnen, et. al.             Standards Track                     [Page 1]

RFC 2275                    VACM for SNMPv3                 January 1998


   2.4.2.  ViewTreeFamily                                       5
   2.5.  Access Policy                                          6
   3.  Elements of Procedure                                    6
   3.1.  Overview  of isAccessAllowed Process                   8
   3.2.  Processing the isAccessAllowed Service Request         9
   4.  Definitions                                             10
   5.  Intellectual Property                                   26
   6.  Acknowledgements                                        27
   7.  Security Considerations                                 28
   7.1.  Recommended Practices                                 28
   7.2.  Defining Groups                                       29
   7.3.  Conformance                                           29
   8.  References                                              29
   9.  Editors' Addresses                                      30
   A.1.  Installation Parameters                               31
   B.  Full Copyright Statement                                36

1.  Introduction

   The Architecture for describing Internet Management Frameworks
   [RFC2271] describes that an SNMP engine is composed of:

     1) a Dispatcher
     2) a Message Processing Subsystem,
     3) a Security Subsystem, and
     4) an Access Control Subsystem.

   Applications make use of the services of these subsystems.

   It is important to understand the SNMP architecture and its
   terminology to understand where the View-based Access Control Model
   described in this document fits into the architecture and interacts
   with other subsystems within the architecture.  The reader is
   expected to have read and understood the description and terminology
   of the SNMP architecture, as defined in [RFC2271].

   The Access Control Subsystem of an SNMP engine has the responsibility
   for checking whether a specific type of access (read, write, notify)
   to a particular object (instance) is allowed.

   It is the purpose of this document to define a specific model of the
   Access Control Subsystem, designated the View-based Access Control
   Model. Note that this is not necessarily the only Access Control
   Model.

   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 [RFC2119].



Wijnen, et. al.             Standards Track                     [Page 2]

RFC 2275                    VACM for SNMPv3                 January 1998


1.2.  Access Control

   Access Control occurs (either implicitly or explicitly) in an SNMP
   entity when processing SNMP retrieval or modification request
   messages from an SNMP entity.  For example a Command Responder
   application applies Access Control when processing requests that it
   received from a Command Generator application.  These requests
   include these types of operations: GetRequest, GetNextRequest,
   GetBulkRequest, and SetRequest operations.

   Access Control also occurs in an SNMP entity when an SNMP
   notification message is generated (by a Notification Originator
   application).  These notification messages include these types of
   operations: InformRequest and SNMPv2-Trap operations.

   The View-based Access Control Model defines a set of services that an
   application (such as a Command Responder or a Notification Originator
   application) can use for checking access rights.  It is the
   responsibility of the application to make the proper service calls
   for access checking.

1.3.  Local Configuration Datastore

   To implement the model described in this document, an SNMP entity
   needs to retain information about access rights and policies.  This
   information is part of the SNMP engine's Local Configuration
   Datastore (LCD). See [RFC2271] for the definition of LCD.

   In order to allow an SNMP entity's LCD to be remotely configured,
   portions of the LCD need to be accessible as managed objects.  A MIB
   module, the View-based Access Control Model Configuration MIB, which
   defines these managed object types is included in this document.

2.  Elements of the Model

   This section contains definitions to realize the access control
   service provided by the View-based Access Control Model.

2.1.  Groups

   A group is a set of zero or more <securityModel, securityName> tuples
   on whose behalf SNMP management objects can be accessed.  A group
   defines the access rights afforded to all securityNames which belong
   to that group. The combination of a securityModel and a securityName
   maps to at most one group.  A group is identified by a groupName.

   The Access Control module assumes that the securityName has already
   been authenticated as needed and provides no further authentication



Wijnen, et. al.             Standards Track                     [Page 3]

RFC 2275                    VACM for SNMPv3                 January 1998


   of its own.

   The View-based Access Control Model uses the securityModel and the
   securityName as inputs to the Access Control module when called to
   check for access rights.  It determines the groupName as a function
   of securityModel and securityName.

2.2.  securityLevel

   Different access rights for members of a group can be defined for
   different levels of security, i.e., noAuthNoPriv, authNoPriv, and
   authPriv. The securityLevel identifies the level of security that
   will be assumed when checking for access rights.  See the SNMP
   Architecture document [RFC2271] for a definition of securityLevel.

   The View-based Access Control Model requires that the securityLevel
   is passed as input to the Access Control module when called to check
   for access rights.

2.3.  Contexts

   An SNMP context is a collection of management information accessible
   by an SNMP entity.  An item of management information may exist in
   more than one context.  An SNMP entity potentially has access to many
   contexts.  Details about the naming of management information can be
   found in the SNMP Architecture document [RFC2271].

   The View-based Access Control Model defines a vacmContextTable that
   lists the locally available contexts by contextName.

2.4.  MIB Views and View Families

   For security reasons, it is often valuable to be able to restrict the
   access rights of some groups to only a subset of the management
   information in the management domain.  To provide this capability,
   access to a context is via a "MIB view" which details a specific set
   of managed object types (and optionally, the specific instances of
   object types) within that context.  For example, for a given context,
   there will typically always be one MIB view which provides access to
   all management information in that context, and often there will be
   other MIB views each of which contains some subset of the
   information.  So, the access allowed for a group can be restricted in
   the desired manner by specifying its rights in terms of the
   particular (subset) MIB view it can access within each appropriate
   context.

   Since managed object types (and their instances) are identified via
   the tree-like naming structure of ISO's OBJECT IDENTIFIERs [ISO-



Wijnen, et. al.             Standards Track                     [Page 4]

RFC 2275                    VACM for SNMPv3                 January 1998


   ASN.1, RFC1902],  it is convenient to define a MIB view as the
   combination of a set of "view subtrees", where each view subtree is a
   subtree within the managed object naming tree.  Thus, a simple MIB
   view (e.g., all managed objects within the Internet Network
   Management Framework) can be defined as a single view subtree, while
   more complicated MIB views (e.g., all information relevant to a
   particular network interface) can be represented by the union of
   multiple view subtrees.

   While any set of managed objects can be described by the union of
   some number of view subtrees, situations can arise that would require
   a very large number of view subtrees.  This could happen, for
   example, when specifying all columns in one conceptual row of a MIB
   table because they would appear in separate subtrees, one per column,
   each with a very similar format.  Because the formats are similar,
   the required set of subtrees can easily be aggregated into one
   structure.  This structure is named a family of view subtrees after
   the set of subtrees that it conceptually represents.  A family of
   view subtrees can either be included or excluded from a MIB view.

2.4.1.  View Subtree

   A view subtree is the set of all MIB object instances which have a
   common ASN.1 OBJECT IDENTIFIER prefix to their names.  A view subtree
   is identified by the OBJECT IDENTIFIER value which is the longest
   OBJECT IDENTIFIER prefix common to all (potential) MIB object
   instances in that subtree.

2.4.2.  ViewTreeFamily

   A family of view subtrees is a pairing of an OBJECT IDENTIFIER value
   (called the family name) together with a bit string value (called the
   family mask).  The family mask indicates which sub-identifiers of the
   associated family name are significant to the family's definition.

   For each possible managed object instance, that instance belongs to a
   particular ViewTreeFamily if both of the following conditions are
   true:

   - the OBJECT IDENTIFIER name of the managed object instance
     contains at least as many sub-identifiers as does the family name,
     and

   - each sub-identifier in the OBJECT IDENTIFIER name of the managed
     object instance matches the corresponding sub-identifier of the
     family name whenever the corresponding bit of the associated family
     mask is non-zero.




Wijnen, et. al.             Standards Track                     [Page 5]

RFC 2275                    VACM for SNMPv3                 January 1998


   When the configured value of the family mask is all ones, the view
   subtree family is identical to the single view subtree identified by
   the family name.

   When the configured value of the family mask is shorter than required
   to perform the above test, its value is implicitly extended with
   ones.  Consequently, a view subtree family having a family mask of
   zero length always corresponds to a single view subtree.

2.5.  Access Policy

   The View-based Access Control Model determines the access rights of a
   group, representing zero or more securityNames which have the same
   access rights.  For a particular context, identified by contextName,
   to which a group, identified by groupName, has access using a
   particular securityModel and securityLevel, that group's access
   rights are given by a read-view, a write-view and a notify-view.

   The read-view represents the set of object instances authorized for
   the group when reading objects.  Reading objects occurs when
   processing a retrieval (for example a GetRequest, GetNextRequest,
   GetBulkRequest) operation.

   The write-view represents the set of object instances authorized for
   the group when writing objects.  Writing objects occurs when
   processing a write (for example a Set) operation.

   The notify-view represents the set of object instances authorized for
   the group when sending objects in a notification, such as when
   sending a notification (for example an Inform or SNMPv2-Trap).

3.  Elements of Procedure

   This section describes the procedures followed by an Access Control
   module that implements the View-based Access Control Model when
   checking access rights as requested by an application (for example a
   Command Responder or a Notification Originator application).  The
   abstract service primitive is:

     statusInformation =          -- success or errorIndication
         isAccessAllowed(
             securityModel        -- Security Model in use
             securityName         -- principal who wants access
             securityLevel        -- Level of Security
             viewType             -- read, write, or notify view
             contextName          -- context containing variableName
             variableName         -- OID for the managed object
             )



Wijnen, et. al.             Standards Track                     [Page 6]

RFC 2275                    VACM for SNMPv3                 January 1998


   The abstract data elements are:

     statusInformation - one of the following:
        accessAllowed  - a MIB view was found and access is granted.
        notInView      - a MIB view was found but access is denied.
                         The variableName is not in the configured
                         MIB view for the specified viewType (e.g., in
                         the relevant entry in the vacmAccessTable).
        noSuchView     - no MIB view found because no view has been
                         configured for specified viewType (e.g., in
                         the relevant entry in the vacmAccessTable).
        noSuchContext  - no MIB view found because of no entry in the
                         vacmContextTable for specified contextName.
        noGroupName    - no MIB view found because no entry has been
                         configured in the vacmSecurityToGroupTable
                         for the specified combination of
                         securityModel and securityName.
        noAccessEntry  - no MIB view found because no entry has been
                         configured in the vacmAccessTable for the
                         specified combination of contextName,
                         groupName (from vacmSecurityToGroupTable),
                         securityModel and securityLevel.
        otherError     - failure, an undefined error occurred.
     securityModel - Security Model under which access is requested.
     securityName  - the principal on whose behalf access is requested.
     securityLevel - Level of Security under which access is requested.
     viewType      - view to be checked (read, write or notify).
     contextName   - context in which access is requested.
     variableName  - object instance to which access is requested.






















Wijnen, et. al.             Standards Track                     [Page 7]

RFC 2275                    VACM for SNMPv3                 January 1998


3.1.  Overview  of isAccessAllowed Process

 The following picture shows how the decision for access control is made
 by the View-based Access Control Model.

 +--------------------------------------------------------------------+
 |                                                                    |
 |      +-> securityModel -+                                          |
 |      |   (a)            |                                          |
 | who -+                  +-> groupName ----+                        |
 | (1)  |                  |   (x)           |                        |
 |      +-> securityName --+                 |                        |
 |          (b)                              |                        |
 |                                           |                        |
 | where -> contextName ---------------------+                        |
 | (2)      (e)                              |                        |
 |                                           |                        |
 |                                           |                        |
 |      +-> securityModel -------------------+                        |
 |      |   (a)                              |                        |
 | how -+                                    +-> viewName -+          |
 | (3)  |                                    |   (y)       |          |
 |      +-> securityLevel -------------------+             |          |
 |          (c)                              |             +-> yes/no |
 |                                           |             | decision |
 | why ---> viewType (read/write/notify) ----+             | (z)      |
 | (4)      (d)                                            |          |
 |                                                         |          |
 | what --> object-type ------+                            |          |
 | (5)      (m)               |                            |          |
 |                            +-> variableName (OID) ------+          |
 |                            |   (f)                                 |
 | which -> object-instance --+                                       |
 | (6)      (n)                                                       |
 |                                                                    |
 +--------------------------------------------------------------------+

 How the decision for isAccessAllowed is made.

 1) Inputs to the isAccessAllowed service are:

    (a)       securityModel    -- Security Model in use
    (b)       securityName     -- principal who wants to access
    (c)       securityLevel    -- Level of Security
    (d)       viewType         -- read, write, or notify view
    (e)       contextName      -- context containing variableName
    (f)       variableName     -- OID for the managed object
                               -- this is made up of:



Wijnen, et. al.             Standards Track                     [Page 8]

RFC 2275                    VACM for SNMPv3                 January 1998


                                  - object-type (m)
                                  - object-instance (n)

 2) The partial "who" (1), represented by the securityModel (a) and
    the securityName (b), are used as the indices (a,b) into the
    vacmSecurityToGroupTable to find a single entry that produces a
    group, represented by groupName (x).

 3) The "where" (2), represented by the contextName (e), the "who",
    represented by the groupName (x) from the previous step, and the
    "how" (3), represented by securityModel (a) and securityLevel (c),
    are used as indices (e,x,a,c) into the vacmAccessTable to find a
    single entry that contains three MIB views.

 4) The "why" (4), represented by the viewType (d), is used to select
    the proper MIB view, represented by a viewName (y), from the
    vacmAccessEntry selected in the previous step. This viewName (y) is
    an index into the vacmViewTreeFamilyTable and selects the set of
    entries that define the variableNames which are included in or
    excluded from the MIB view identified by the viewName (y).

 5) The "what" (5) type of management data and "which" (6) particular
    instance, represented by the variableName (f), is then checked to be
    in the MIB view or not, e.g., the yes/no decision (z).

3.2.  Processing the isAccessAllowed Service Request

   This section describes the procedure followed by an Access Control
   module that implements the View-based Access Control Model whenever
   it receives an isAccessAllowed request.

   1) The vacmContextTable is consulted for information about
      the SNMP context identified by the contextName.  If information
      about this SNMP context is absent from the table, then an
      errorIndication (noSuchContext) is returned to the calling module.

   2) The vacmSecurityToGroupTable is consulted for mapping the
      securityModel and securityName to a groupName.  If the information
      about this combination is absent from the table, then an
      errorIndication (noGroupName) is returned to the calling module.

   3) The vacmAccessTable is consulted for information about the
      groupName, contextName, securityModel and securityLevel.  If
      information about this combination is absent from the table, then
      an errorIndication (noAccessEntry) is returned to the calling
      module.





Wijnen, et. al.             Standards Track                     [Page 9]

RFC 2275                    VACM for SNMPv3                 January 1998


   4) a) If the viewType is "read", then the read view is used for
         checking access rights.

      b) If the viewType is "write", then the write view is used for
         checking access rights.

      c) If the viewType is "notify", then the notify view is used
         for checking access rights.

      If the view to be used is the empty view (zero length viewName)
      then an errorIndication (noSuchView) is returned to the calling
      module.

   5) a) If there is no view configured for the specified viewType,
         then an errorIndication (noSuchView) is returned to the calling
         module.

      b) If the specified variableName (object instance) is not in the
         MIB view (see DESCRIPTION clause for vacmViewTreeFamilyTable in
         section 4), then an errorIndication (notInView) is returned to
         the calling module.

         Otherwise,

      c) The specified variableName is in the MIB view.
         A statusInformation of success (accessAllowed) is returned to
         the calling module.

4.  Definitions

SNMP-VIEW-BASED-ACM-MIB DEFINITIONS ::= BEGIN

IMPORTS
    MODULE-COMPLIANCE, OBJECT-GROUP       FROM SNMPv2-CONF
    MODULE-IDENTITY, OBJECT-TYPE,
    snmpModules                           FROM SNMPv2-SMI
    TestAndIncr,
    RowStatus, StorageType                FROM SNMPv2-TC
    SnmpAdminString,
    SnmpSecurityLevel,
    SnmpSecurityModel                     FROM SNMP-FRAMEWORK-MIB;

snmpVacmMIB       MODULE-IDENTITY
    LAST-UPDATED "9711200000Z"            -- 20 Nov 1997, midnight
    ORGANIZATION "SNMPv3 Working Group"
    CONTACT-INFO "WG-email:   snmpv3@tis.com
                  Subscribe:  majordomo@tis.com
                              In message body:  subscribe snmpv3



Wijnen, et. al.             Standards Track                    [Page 10]

RFC 2275                    VACM for SNMPv3                 January 1998


                  Chair:      Russ Mundy
                              Trusted Information Systems
                  postal:     3060 Washington Rd
                              Glenwood MD 21738
                              USA
                  email:      mundy@tis.com
                  phone:      +1-301-854-6889

                  Co-editor:  Bert Wijnen
                              IBM T.J. Watson Research
                  postal:     Schagen 33
                              3461 GL Linschoten
                              Netherlands
                  email:      wijnen@vnet.ibm.com
                  phone:      +31-348-432-794

                  Co-editor:  Randy Presuhn
                              BMC Software, Inc
                  postal:     1190 Saratoga Avenue, Suite 130
                              San Jose, CA  95129-3433
                              USA
                  email:      rpresuhn@bmc.com
                  phone:      +1-408-556-0720

                  Co-editor:  Keith McCloghrie
                              Cisco Systems, Inc.
                  postal:     170 West Tasman Drive
                              San Jose, CA  95134-1706
                              USA
                  email:      kzm@cisco.com
                  phone:      +1-408-526-5260
                 "
    DESCRIPTION  "The management information definitions for the
                  View-based Access Control Model for SNMP.
                 "
    ::= { snmpModules 16 }

-- Administrative assignments ****************************************

vacmMIBObjects      OBJECT IDENTIFIER ::= { snmpVacmMIB 1 }
vacmMIBConformance  OBJECT IDENTIFIER ::= { snmpVacmMIB 2 }

-- Information about Local Contexts **********************************

vacmContextTable OBJECT-TYPE
    SYNTAX       SEQUENCE OF VacmContextEntry
    MAX-ACCESS   not-accessible
    STATUS       current



Wijnen, et. al.             Standards Track                    [Page 11]

RFC 2275                    VACM for SNMPv3                 January 1998


    DESCRIPTION "The table of locally available contexts.

                 This table provides information to SNMP Command
                 Generator applications so that they can properly
                 configure the vacmAccessTable to control access to
                 all contexts at the SNMP entity.

                 This table may change dynamically if the SNMP entity
                 allows that contexts are added/deleted dynamically
                 (for instance when its configuration changes). Such
                 changes would happen only if the management
                 instrumentation at that SNMP entity recognizes more
                 (or fewer) contexts.

                 The presence of entries in this table and of entries
                 in the vacmAccessTable are independent.  That is, a
                 context identified by an entry in this table is not
                 necessarily referenced by any entries in the
                 vacmAccessTable; and the context(s) referenced by an
                 entry in the vacmAccessTable does not necessarily
                 currently exist and thus need not be identified by an
                 entry in this table.

                 This table must be made accessible via the default
                 context so that Command Responder applications have
                 a standard way of retrieving the information.

                 This table is read-only. It cannot be configured via
                 SNMP.
                "
    ::= { vacmMIBObjects 1 }

vacmContextEntry OBJECT-TYPE
    SYNTAX       VacmContextEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "Information about a particular context."
    INDEX       {
                  vacmContextName
                }
    ::= { vacmContextTable 1 }

VacmContextEntry ::= SEQUENCE
    {
        vacmContextName SnmpAdminString
    }

vacmContextName  OBJECT-TYPE



Wijnen, et. al.             Standards Track                    [Page 12]

RFC 2275                    VACM for SNMPv3                 January 1998


    SYNTAX       SnmpAdminString (SIZE(0..32))
    MAX-ACCESS   read-only
    STATUS       current
    DESCRIPTION "A human readable name identifying a particular
                 context at a particular SNMP entity.

                 The empty contextName (zero length) represents the
                 default context.
                "
    ::= { vacmContextEntry 1 }

-- Information about Groups ******************************************

vacmSecurityToGroupTable OBJECT-TYPE
    SYNTAX       SEQUENCE OF VacmSecurityToGroupEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "This table maps a combination of securityModel and
                 securityName into a groupName which is used to define
                 an access control policy for a group of principals.
                "
    ::= { vacmMIBObjects 2 }

vacmSecurityToGroupEntry OBJECT-TYPE
    SYNTAX       VacmSecurityToGroupEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "An entry in this table maps the combination of a
                 securityModel and securityName into a groupName.
                "
    INDEX       {
                  vacmSecurityModel,
                  vacmSecurityName
                }
    ::= { vacmSecurityToGroupTable 1 }

VacmSecurityToGroupEntry ::= SEQUENCE
    {
        vacmSecurityModel               SnmpSecurityModel,
        vacmSecurityName                SnmpAdminString,
        vacmGroupName                   SnmpAdminString,
        vacmSecurityToGroupStorageType  StorageType,
        vacmSecurityToGroupStatus       RowStatus
    }

vacmSecurityModel OBJECT-TYPE
    SYNTAX       SnmpSecurityModel(1..2147483647)
    MAX-ACCESS   not-accessible



Wijnen, et. al.             Standards Track                    [Page 13]

RFC 2275                    VACM for SNMPv3                 January 1998


    STATUS       current
    DESCRIPTION "The Security Model, by which the vacmSecurityName
                 referenced by this entry is provided.

                 Note, this object may not take the 'any' (0) value.
                "
    ::= { vacmSecurityToGroupEntry 1 }

vacmSecurityName OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(1..32))
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The securityName for the principal, represented in a
                 Security Model independent format, which is mapped by
                 this entry to a groupName.

                 The securityName for a principal represented in a
                 Security Model independent format.
                "
    ::= { vacmSecurityToGroupEntry 2 }

vacmGroupName    OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(1..32))
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The name of the group to which this entry (e.g., the
                 combination of securityModel and securityName)
                 belongs.

                 This groupName is used as index into the
                 vacmAccessTable to select an access control policy.
                "
    ::= { vacmSecurityToGroupEntry 3 }

vacmSecurityToGroupStorageType OBJECT-TYPE
    SYNTAX       StorageType
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The storage type for this conceptual row.
                 Conceptual rows having the value 'permanent' need not
                 allow write-access to any columnar objects in the row.
                "
    DEFVAL      { nonVolatile }
    ::= { vacmSecurityToGroupEntry 4 }

vacmSecurityToGroupStatus OBJECT-TYPE
    SYNTAX       RowStatus
    MAX-ACCESS   read-create



Wijnen, et. al.             Standards Track                    [Page 14]

RFC 2275                    VACM for SNMPv3                 January 1998


    STATUS       current
    DESCRIPTION "The status of this conceptual row.

                 The  RowStatus TC [RFC1903] requires that this
                 DESCRIPTION clause states under which circumstances
                 other objects in this row can be modified:

                 The value of this object has no effect on whether
                 other objects in this conceptual row can be modified.
                "
    ::= { vacmSecurityToGroupEntry 5 }

-- Information about Access Rights ***********************************

vacmAccessTable  OBJECT-TYPE
    SYNTAX       SEQUENCE OF VacmAccessEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The table of access rights for groups.

                 Each entry is indexed by a contextPrefix, a groupName
                 a securityModel and a securityLevel.  To determine
                 whether access is allowed, one entry from this table
                 needs to be selected and the proper viewName from that
                 entry must be used for access control checking.

                 To select the proper entry, follow these steps:

                 1) the set of possible matches is formed by the
                    intersection of the following sets of entries:
                      the set of entries with identical vacmGroupName
                      the union of these two sets:
                       - the set with identical vacmAccessContextPrefix
                       - the set of entries with vacmAccessContextMatch
                         value of 'prefix' and matching
                         vacmAccessContextPrefix
                      intersected with the union of these two sets:
                       - the set of entries with identical
                         vacmSecurityModel
                       - the set of entries with vacmSecurityModel
                         value of 'any'
                      intersected with the set of entries with
                      vacmAccessSecurityLevel value less than or equal
                      to the requested securityLevel

                 2) if this set has only one member, we're done
                    otherwise, it comes down to deciding how to weight
                    the preferences between ContextPrefixes,



Wijnen, et. al.             Standards Track                    [Page 15]

RFC 2275                    VACM for SNMPv3                 January 1998


                    SecurityModels, and SecurityLevels as follows:
                    a) if the subset of entries with identical
                       securityModels is not empty, discard the rest.
                    b) if the subset of entries with identical
                       vacmAccessContextPrefix is not empty,
                       discard the rest
                    c) discard all entries with ContextPrefixes shorter
                       than the longest one remaining in the set
                    d) select the entry with the highest securityLevel

                 Please note that for securityLevel noAuthNoPriv, all
                 groups are really equivalent since the assumption that
                 the securityName has been authenticated does not hold.
                "
    ::= { vacmMIBObjects 4 }

vacmAccessEntry  OBJECT-TYPE
    SYNTAX       VacmAccessEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "An access right configured in the Local Configuration
                 Datastore (LCD) authorizing access to an SNMP context.
                "
    INDEX       { vacmGroupName,
                  vacmAccessContextPrefix,
                  vacmAccessSecurityModel,
                  vacmAccessSecurityLevel
                }
    ::= { vacmAccessTable 1 }

VacmAccessEntry ::= SEQUENCE
    {
        vacmAccessContextPrefix    SnmpAdminString,
        vacmAccessSecurityModel    SnmpSecurityModel,
        vacmAccessSecurityLevel    SnmpSecurityLevel,
        vacmAccessContextMatch     INTEGER,
        vacmAccessReadViewName     SnmpAdminString,
        vacmAccessWriteViewName    SnmpAdminString,
        vacmAccessNotifyViewName   SnmpAdminString,
        vacmAccessStorageType      StorageType,
        vacmAccessStatus           RowStatus
    }

vacmAccessContextPrefix OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(0..32))
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "In order to gain the access rights allowed by this



Wijnen, et. al.             Standards Track                    [Page 16]

RFC 2275                    VACM for SNMPv3                 January 1998


                 conceptual row, a contextName must match exactly
                 (if the value of vacmAccessContextMatch is 'exact')
                 or partially (if the value of vacmAccessContextMatch
                 is 'prefix') to the value of the instance of this
                 object.
                "
    ::= { vacmAccessEntry 1 }

vacmAccessSecurityModel OBJECT-TYPE
    SYNTAX       SnmpSecurityModel
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "In order to gain the access rights allowed by this
                 conceptual row, this securityModel must be in use.
                "
    ::= { vacmAccessEntry 2 }

vacmAccessSecurityLevel OBJECT-TYPE
    SYNTAX       SnmpSecurityLevel
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The minimum level of security required in order to
                 gain the access rights allowed by this conceptual
                 row.  A securityLevel of noAuthNoPriv is less than
                 authNoPriv which in turn is less than authPriv.

                 If multiple entries are equally indexed except for
                 this vacmAccessSecurityLevel index, then the entry
                 which has the highest value for
                 vacmAccessSecurityLevel wins.
                "
    ::= { vacmAccessEntry 3 }

vacmAccessContextMatch OBJECT-TYPE
    SYNTAX       INTEGER
                { exact (1), -- exact match of prefix and contextName
                  prefix (2) -- Only match to the prefix
                }
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "If the value of this object is exact(1), then all
                 rows where the contextName exactly matches
                 vacmAccessContextPrefix are selected.

                 If the value of this object is prefix(2), then all
                 rows where the contextName whose starting octets
                 exactly match vacmAccessContextPrefix are selected.
                 This allows for a simple form of wildcarding.



Wijnen, et. al.             Standards Track                    [Page 17]

RFC 2275                    VACM for SNMPv3                 January 1998


                 See also the example in the DESCRIPTION clause of
                 the vacmAccessTable above.
                "
    ::= { vacmAccessEntry 4 }

vacmAccessReadViewName OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(0..32))
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The value of an instance of this object identifies
                 the MIB view of the SNMP context to which this
                 conceptual row authorizes read access.

                 The identified MIB view is that one for which the
                 vacmViewTreeFamilyViewName has the same value as the
                 instance of this object; if the value is the empty
                 string or if there is no active MIB view having this
                 value of vacmViewTreeFamilyViewName, then no access
                 is granted.
                "
    DEFVAL      { ''H }   -- the empty string
    ::= { vacmAccessEntry 5 }

vacmAccessWriteViewName OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(0..32))
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The value of an instance of this object identifies
                 the MIB view of the SNMP context to which this
                 conceptual row authorizes write access.

                 The identified MIB view is that one for which the
                 vacmViewTreeFamilyViewName has the same value as the
                 instance of this object; if the value is the empty
                 string or if there is no active MIB view having this
                 value of vacmViewTreeFamilyViewName, then no access
                 is granted.
                "
    DEFVAL      { ''H }   -- the empty string
    ::= { vacmAccessEntry 6 }

vacmAccessNotifyViewName OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(0..32))
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The value of an instance of this object identifies
                 the MIB view of the SNMP context to which this
                 conceptual row authorizes access for notifications.



Wijnen, et. al.             Standards Track                    [Page 18]

RFC 2275                    VACM for SNMPv3                 January 1998


                 The identified MIB view is that one for which the
                 vacmViewTreeFamilyViewName has the same value as the
                 instance of this object; if the value is the empty
                 string or if there is no active MIB view having this
                 value of vacmViewTreeFamilyViewName, then no access
                 is granted.
                "
    DEFVAL      { ''H }   -- the empty string
    ::= { vacmAccessEntry 7 }

vacmAccessStorageType OBJECT-TYPE
    SYNTAX       StorageType
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The storage type for this conceptual row.

                 Conceptual rows having the value 'permanent' need not
                 allow write-access to any columnar objects in the row.
                "
    DEFVAL      { nonVolatile }
    ::= { vacmAccessEntry 8 }

vacmAccessStatus OBJECT-TYPE
    SYNTAX       RowStatus
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The status of this conceptual row.

                 The  RowStatus TC [RFC1903] requires that this
                 DESCRIPTION clause states under which circumstances
                 other objects in this row can be modified:

                 The value of this object has no effect on whether
                 other objects in this conceptual row can be modified.
                "
    ::= { vacmAccessEntry 9 }

-- Information about MIB views ***************************************

-- Support for instance-level granularity is optional.
--
-- In some implementations, instance-level access control
-- granularity may come at a high performance cost.  Managers
-- should avoid requesting such configurations unnecessarily.

vacmMIBViews     OBJECT IDENTIFIER ::= { vacmMIBObjects 5 }

vacmViewSpinLock OBJECT-TYPE



Wijnen, et. al.             Standards Track                    [Page 19]

RFC 2275                    VACM for SNMPv3                 January 1998


    SYNTAX       TestAndIncr
    MAX-ACCESS   read-write
    STATUS       current
    DESCRIPTION "An advisory lock used to allow cooperating SNMP
                 Command Generator applications to coordinate their
                 use of the Set operation in creating or modifying
                 views.

                 When creating a new view or altering an existing
                 view, it is important to understand the potential
                 interactions with other uses of the view.  The
                 vacmViewSpinLock should be retrieved.  The name of
                 the view to be created should be determined to be
                 unique by the SNMP Command Generator application by
                 consulting the vacmViewTreeFamilyTable.  Finally,
                 the named view may be created (Set), including the
                 advisory lock.
                 If another SNMP Command Generator application has
                 altered the views in the meantime, then the spin
                 lock's value will have changed, and so this creation
                 will fail because it will specify the wrong value for
                 the spin lock.

                 Since this is an advisory lock, the use of this lock
                 is not enforced.
                "
    ::= { vacmMIBViews 1 }

vacmViewTreeFamilyTable OBJECT-TYPE
    SYNTAX       SEQUENCE OF VacmViewTreeFamilyEntry
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "Locally held information about families of subtrees
                 within MIB views.

                 Each MIB view is defined by two sets of view subtrees:
                   - the included view subtrees, and
                   - the excluded view subtrees.
                 Every such view subtree, both the included and the
                 excluded ones, is defined in this table.

                 To determine if a particular object instance is in
                 a particular MIB view, compare the object instance's
                 OBJECT IDENTIFIER with each of the MIB view's active
                 entries in this table.  If none match, then the
                 object instance is not in the MIB view.  If one or
                 more match, then the object instance is included in,
                 or excluded from, the MIB view according to the



Wijnen, et. al.             Standards Track                    [Page 20]

RFC 2275                    VACM for SNMPv3                 January 1998


                 value of vacmViewTreeFamilyType in the entry whose
                 value of vacmViewTreeFamilySubtree has the most
                 sub-identifiers.  If multiple entries match and have
                 the same number of sub-identifiers, then the
                 lexicographically greatest instance of
                 vacmViewTreeFamilyType determines the inclusion or
                 exclusion.

                 An object instance's OBJECT IDENTIFIER X matches an
                 active entry in this table when the number of
                 sub-identifiers in X is at least as many as in the
                 value of vacmViewTreeFamilySubtree for the entry,
                 and each sub-identifier in the value of
                 vacmViewTreeFamilySubtree matches its corresponding
                 sub-identifier in X.  Two sub-identifiers match
                 either if the corresponding bit of the value of
                 vacmViewTreeFamilyMask for the entry is zero (the
                 'wild card' value), or if they are equal.

                 A 'family' of subtrees is the set of subtrees defined
                 by a particular combination of values of
                 vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask.
                 In the case where no 'wild card' is defined in the
                 vacmViewTreeFamilyMask, the family of subtrees reduces
                 to a single subtree.

                 When creating or changing MIB views, an SNMP Command
                 Generator application should utilize the
                 vacmViewSpinLock to try to avoid collisions. See
                 DESCRIPTION clause of vacmViewSpinLock.

                 When creating MIB views, it is strongly advised that
                 first the 'excluded' vacmViewTreeFamilyEntries are
                 created and then the 'included' entries.

                 When deleting MIB views, it is strongly advised that
                 first the 'included' vacmViewTreeFamilyEntries are
                 deleted and then the 'excluded' entries.

                 If a create for an entry for instance-level access
                 control is received and the implementation does not
                 support instance-level granularity, then an
                 inconsistentName error must be returned.
                "
    ::= { vacmMIBViews 2 }

vacmViewTreeFamilyEntry OBJECT-TYPE
    SYNTAX       VacmViewTreeFamilyEntry



Wijnen, et. al.             Standards Track                    [Page 21]

RFC 2275                    VACM for SNMPv3                 January 1998


    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "Information on a particular family of view subtrees
                 included in or excluded from a particular SNMP
                 context's MIB view.

                 Implementations must not restrict the number of
                 families of view subtrees for a given MIB view,
                 except as dictated by resource constraints on the
                 overall number of entries in the
                 vacmViewTreeFamilyTable.

                 If no conceptual rows exist in this table for a given
                 MIB view (viewName), that view may be thought of as
                 consisting of the empty set of view subtrees.
                "
    INDEX       { vacmViewTreeFamilyViewName,
                  vacmViewTreeFamilySubtree
                }
    ::= { vacmViewTreeFamilyTable 1 }

VacmViewTreeFamilyEntry ::= SEQUENCE
    {
        vacmViewTreeFamilyViewName     SnmpAdminString,
        vacmViewTreeFamilySubtree      OBJECT IDENTIFIER,
        vacmViewTreeFamilyMask         OCTET STRING,
        vacmViewTreeFamilyType         INTEGER,
        vacmViewTreeFamilyStorageType  StorageType,
        vacmViewTreeFamilyStatus       RowStatus
    }

vacmViewTreeFamilyViewName OBJECT-TYPE
    SYNTAX       SnmpAdminString (SIZE(1..32))
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The human readable name for a family of view subtrees.
                "
    ::= { vacmViewTreeFamilyEntry 1 }

vacmViewTreeFamilySubtree OBJECT-TYPE
    SYNTAX       OBJECT IDENTIFIER
    MAX-ACCESS   not-accessible
    STATUS       current
    DESCRIPTION "The MIB subtree which when combined with the
                 corresponding instance of vacmViewTreeFamilyMask
                 defines a family of view subtrees.
                "
    ::= { vacmViewTreeFamilyEntry 2 }



Wijnen, et. al.             Standards Track                    [Page 22]

RFC 2275                    VACM for SNMPv3                 January 1998


vacmViewTreeFamilyMask OBJECT-TYPE
    SYNTAX       OCTET STRING (SIZE (0..16))
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The bit mask which, in combination with the
                 corresponding instance of vacmViewTreeFamilySubtree,
                 defines a family of view subtrees.

                 Each bit of this bit mask corresponds to a
                 sub-identifier of vacmViewTreeFamilySubtree, with the
                 most significant bit of the i-th octet of this octet
                 string value (extended if necessary, see below)
                 corresponding to the (8*i - 7)-th sub-identifier, and
                 the least significant bit of the i-th octet of this
                 octet string corresponding to the (8*i)-th
                 sub-identifier, where i is in the range 1 through 16.

                 Each bit of this bit mask specifies whether or not
                 the corresponding sub-identifiers must match when
                 determining if an OBJECT IDENTIFIER is in this
                 family of view subtrees; a '1' indicates that an
                 exact match must occur; a '0' indicates 'wild card',
                 i.e., any sub-identifier value matches.

                 Thus, the OBJECT IDENTIFIER X of an object instance
                 is contained in a family of view subtrees if, for
                 each sub-identifier of the value of
                 vacmViewTreeFamilySubtree, either:

                   the i-th bit of vacmViewTreeFamilyMask is 0, or

                   the i-th sub-identifier of X is equal to the i-th
                   sub-identifier of the value of
                   vacmViewTreeFamilySubtree.

                 If the value of this bit mask is M bits long and
                 there are more than M sub-identifiers in the
                 corresponding instance of vacmViewTreeFamilySubtree,
                 then the bit mask is extended with 1's to be the
                 required length.

                 Note that when the value of this object is the
                 zero-length string, this extension rule results in
                 a mask of all-1's being used (i.e., no 'wild card'),
                 and the family of view subtrees is the one view
                 subtree uniquely identified by the corresponding
                 instance of vacmViewTreeFamilySubtree.




Wijnen, et. al.             Standards Track                    [Page 23]

RFC 2275                    VACM for SNMPv3                 January 1998


                 Note that masks of length greater than zero length
                 do not need to be supported. In this case this
                 object is made read-only.
                "
    DEFVAL      { ''H }
    ::= { vacmViewTreeFamilyEntry 3 }

vacmViewTreeFamilyType OBJECT-TYPE
    SYNTAX       INTEGER  { included(1), excluded(2) }
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "Indicates whether the corresponding instances of
                 vacmViewTreeFamilySubtree and vacmViewTreeFamilyMask
                 define a family of view subtrees which is included in
                 or excluded from the MIB view.
                "
    DEFVAL      { included }
    ::= { vacmViewTreeFamilyEntry 4 }

vacmViewTreeFamilyStorageType OBJECT-TYPE
    SYNTAX       StorageType
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The storage type for this conceptual row.

                 Conceptual rows having the value 'permanent' need not
                 allow write-access to any columnar objects in the row.
                "
    DEFVAL      { nonVolatile }
    ::= { vacmViewTreeFamilyEntry 5 }

vacmViewTreeFamilyStatus OBJECT-TYPE
    SYNTAX       RowStatus
    MAX-ACCESS   read-create
    STATUS       current
    DESCRIPTION "The status of this conceptual row.

                 The  RowStatus TC [RFC1903] requires that this
                 DESCRIPTION clause states under which circumstances
                 other objects in this row can be modified:

                 The value of this object has no effect on whether
                 other objects in this conceptual row can be modified.
                "
    ::= { vacmViewTreeFamilyEntry 6 }

-- Conformance information *******************************************




Wijnen, et. al.             Standards Track                    [Page 24]

RFC 2275                    VACM for SNMPv3                 January 1998


vacmMIBCompliances  OBJECT IDENTIFIER ::= { vacmMIBConformance 1 }
vacmMIBGroups       OBJECT IDENTIFIER ::= { vacmMIBConformance 2 }

-- Compliance statements *********************************************

vacmMIBCompliance MODULE-COMPLIANCE
    STATUS       current
    DESCRIPTION "The compliance statement for SNMP engines which
                 implement the SNMP View-based Access Control Model
                 configuration MIB.
                "
    MODULE -- this module
        MANDATORY-GROUPS { vacmBasicGroup }

        OBJECT        vacmAccessContextMatch
        MIN-ACCESS    read-only
        DESCRIPTION  "Write access is not required."
        OBJECT        vacmAccessReadViewName
        MIN-ACCESS    read-only
        DESCRIPTION  "Write access is not required."

        OBJECT        vacmAccessWriteViewName
        MIN-ACCESS    read-only
        DESCRIPTION  "Write access is not required."

        OBJECT        vacmAccessNotifyViewName
        MIN-ACCESS    read-only
        DESCRIPTION  "Write access is not required."

        OBJECT        vacmAccessStorageType
        MIN-ACCESS    read-only
        DESCRIPTION  "Write access is not required."

        OBJECT        vacmAccessStatus
        MIN-ACCESS    read-only
        DESCRIPTION  "Create/delete/modify access to the
                      vacmAccessTable is not required.
                     "

        OBJECT        vacmViewTreeFamilyMask
        WRITE-SYNTAX  OCTET STRING (SIZE (0))
        MIN-ACCESS    read-only
        DESCRIPTION  "Support for configuration via SNMP of subtree
                      families using wild-cards is not required.
                     "

        OBJECT        vacmViewTreeFamilyType
        MIN-ACCESS    read-only



Wijnen, et. al.             Standards Track                    [Page 25]

RFC 2275                    VACM for SNMPv3                 January 1998


        DESCRIPTION  "Write access is not required."

        OBJECT        vacmViewTreeFamilyStorageType
        MIN-ACCESS    read-only
        DESCRIPTION  "Write access is not required."

        OBJECT        vacmViewTreeFamilyStatus
        MIN-ACCESS    read-only
        DESCRIPTION  "Create/delete/modify access to the
                      vacmViewTreeFamilyTable is not required.
                     "
    ::= { vacmMIBCompliances 1 }

-- Units of conformance **********************************************

vacmBasicGroup OBJECT-GROUP
    OBJECTS {
              vacmContextName,
              vacmGroupName,
              vacmSecurityToGroupStorageType,
              vacmSecurityToGroupStatus,
              vacmAccessContextMatch,
              vacmAccessReadViewName,
              vacmAccessWriteViewName,
              vacmAccessNotifyViewName,
              vacmAccessStorageType,
              vacmAccessStatus,
              vacmViewSpinLock,
              vacmViewTreeFamilyMask,
              vacmViewTreeFamilyType,
              vacmViewTreeFamilyStorageType,
              vacmViewTreeFamilyStatus
            }
    STATUS       current
    DESCRIPTION "A collection of objects providing for remote
                 configuration of an SNMP engine which implements
                 the SNMP View-based Access Control Model.
                "
    ::= { vacmMIBGroups 1 }

END

5.  Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights



Wijnen, et. al.             Standards Track                    [Page 26]

RFC 2275                    VACM for SNMPv3                 January 1998


   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.  Copies of
   claims of rights made available for publication and any assurances of
   licenses to be made available, or the result of an attempt made to
   obtain a general license or permission for the use of such
   proprietary rights by implementors or users of this specification can
   be obtained from the IETF Secretariat.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights which may cover technology that may be required to practice
   this standard.  Please address the information to the IETF Executive
   Director.

6.  Acknowledgements

   This document is the result of the efforts of the SNMPv3 Working
   Group.  Some special thanks are in order to the following SNMPv3 WG
   members:

   Dave Battle (SNMP Research, Inc.)
   Uri Blumenthal (IBM T.J. Watson Research Center)
   Jeff Case (SNMP Research, Inc.)
   John Curran (BBN)
   T. Max Devlin (Hi-TECH Connections)
   John Flick (Hewlett Packard)
   David Harrington (Cabletron Systems Inc.)
   N.C. Hien (IBM T.J. Watson Research Center)
   Dave Levi (SNMP Research, Inc.)
   Louis A Mamakos (UUNET Technologies Inc.)
   Paul Meyer (Secure Computing Corporation)
   Keith McCloghrie (Cisco Systems)
   Russ Mundy (Trusted Information Systems, Inc.)
   Bob Natale (ACE*COMM Corporation)
   Mike O'Dell (UUNET Technologies Inc.)
   Dave Perkins (DeskTalk)
   Peter Polkinghorne (Brunel University)
   Randy Presuhn (BMC Software, Inc.)
   David Reid (SNMP Research, Inc.)
   Shawn Routhier (Epilogue)
   Juergen Schoenwaelder (TU Braunschweig)
   Bob Stewart (Cisco Systems)
   Bert Wijnen (IBM T.J. Watson Research Center)






Wijnen, et. al.             Standards Track                    [Page 27]

RFC 2275                    VACM for SNMPv3                 January 1998


   The document is based on recommendations of the IETF Security and
   Administrative Framework Evolution for SNMP Advisory Team.  Members
   of that Advisory Team were:

   David Harrington (Cabletron Systems Inc.)
   Jeff Johnson (Cisco Systems)
   David Levi (SNMP Research Inc.)
   John Linn (Openvision)
   Russ Mundy (Trusted Information Systems) chair
   Shawn Routhier (Epilogue)
   Glenn Waters (Nortel)
   Bert Wijnen (IBM T. J. Watson Research Center)

   As recommended by the Advisory Team and the SNMPv3 Working Group
   Charter, the design incorporates as much as practical from previous
   RFCs and drafts. As a result, special thanks are due to the authors
   of previous designs known as SNMPv2u and SNMPv2*:

   Jeff Case (SNMP Research, Inc.)
   David Harrington (Cabletron Systems Inc.)
   David Levi (SNMP Research, Inc.)
   Keith McCloghrie (Cisco Systems)
   Brian O'Keefe (Hewlett Packard)
   Marshall T. Rose (Dover Beach Consulting)
   Jon Saperia (BGS Systems Inc.)
   Steve Waldbusser (International Network Services)
   Glenn W. Waters (Bell-Northern Research Ltd.)

7.  Security Considerations

7.1.  Recommended Practices

   This document is meant for use in the SNMP architecture.  The View-
   based Access Control Model described in this document checks access
   rights to management information based on:

   - contextName, representing a set of management information at the
     managed system where the Access Control module is running.
   - groupName, representing a set of zero or more securityNames.
     The combination of a securityModel and a securityName is mapped
     into a group in the View-based Access Control Model.
   - securityModel under which access is requested.
   - securityLevel under which access is requested.
   - operation performed on the management information.
   - MIB views for read, write or notify access.






Wijnen, et. al.             Standards Track                    [Page 28]

RFC 2275                    VACM for SNMPv3                 January 1998


   When the User-based Access Control module is called for checking
   access rights, it is assumed that the calling module has ensured the
   authentication and privacy aspects as specified by the securityLevel
   that is being passed.

   When creating entries in or deleting entries from the
   vacmViewFamiliyTreeTable it is important to do such in the sequence
   as recommended in the DESCRIPTION clause of the vacmViewFamilityTable
   definition. Otherwise unwanted access may be granted while changing
   the entries in the table.

7.2.  Defining Groups

   The groupNames are used to give access to a group of zero or more
   securityNames.  Within the View-Based Access Control Model, a
   groupName is considered to exist if that groupName is listed in the
   vacmSecurityToGroupTable.

   By mapping the combination of a securityModel and securityName into a
   groupName, an SNMP Command Generator application can add/delete
   securityNames to/from a group, if proper access is allowed.

   Further it is important to realize that the grouping of
   <securityModel, securityName> tuples in the vacmSecurityToGroupTable
   does not take securityLevel into account. It is therefore important
   that the security administrator uses the securityLevel index in the
   vacmAccessTable to separate noAuthNoPriv from authPriv and/or
   authNoPriv access.

7.3.  Conformance

   For an implementation of the View-based Access Control Model to be
   conformant, it MUST implement the SNMP-VIEW-BASED-ACM-MIB.  It also
   SHOULD implement the initial configuration, described in appendix A.

8.  References

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

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

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
        Requirement Levels", BCP 14, RFC 2119, March 1997.



Wijnen, et. al.             Standards Track                    [Page 29]

RFC 2275                    VACM for SNMPv3                 January 1998


   [RFC2271] Harrington, D., Presuhn, R., and B. Wijnen,
        "An Architecture for describing SNMP Management Frameworks", RFC
        2271, January 1998.

   [RFC2272] Case, J., Harrington, D., Presuhn, R., and B. Wijnen,
        "Message Processing and Dispatching for the Simple Network
        Management Protocol (SNMP)", RFC 2272, January 1998.

   [RFC2274] Blumenthal, U., and B. Wijnen, "User-based
        Security Model (USM) for version 3 of the Simple Network
        Management Protocol (SNMPv3)", RFC 2274, January 1998.

   [ISO-ASN.1] Information processing systems - Open Systems
        Interconnection - Specification of Abstract Syntax Notation One
        (ASN.1), International Organization for Standardization.
        International Standard 8824, (December, 1987).

9.  Editors' Addresses

   Bert Wijnen
   IBM T. J. Watson Research
   Schagen 33
   3461 GL Linschoten
   Netherlands

   EMail:      wijnen@vnet.ibm.com
   Phone:      +31-348-432-794


   Randy Presuhn
   BMC Software, Inc
   1190 Saratoga Avenue, Suite 130
   San Jose, CA  95129-3433
   USA

   EMail:      rpresuhn@bmc.com
   Phone:      +1-408-556-0720


   Keith McCloghrie
   Cisco Systems, Inc.
   170 West Tasman Drive
   San Jose, CA  95134-1706
   USA

   EMail:      kzm@cisco.com
   Phone:      +1-408-526-5260




Wijnen, et. al.             Standards Track                    [Page 30]

RFC 2275                    VACM for SNMPv3                 January 1998


APPENDIX A - Installation

A.1.  Installation Parameters

   During installation, an authoritative SNMP engine which supports this
   View-based Access Control Model SHOULD be configured with several
   initial parameters.  These include for the View-based Access Control
   Model:

1) A security configuration

   The choice of security configuration determines if initial
   configuration is implemented and if so how.  One of three possible
   choices is selected:

        - initial-minimum-security-configuration
        - initial-semi-security-configuration
        - initial-no-access-configuration

   In the case of a initial-no-access-configuration, there is no initial
   configuration, and so the following steps are irrelevant.

2) A default context

   One entry in the vacmContextTable with a contextName of "" (the empty
   string), representing the default context.  Note that this table gets
   created automatically if a default context exists.

                                 no privacy support  privacy support
                                 ------------------  ---------------
    vacmContextName              ""                  ""

3) An initial group

   One entry in the vacmSecurityToGroupTable to allow access to group
   "initial".

                                 no privacy support  privacy support
                                 ------------------  ---------------
  vacmSecurityModel              3 (USM)             3 (USM)
  vacmSecurityName               "initial"           "initial"
  vacmGroupName                  "initial"           "initial"
  vacmSecurityToGroupStorageType anyValidStorageType anyValidStorageType
  vacmSecurityToGroupStatus      active              active







Wijnen, et. al.             Standards Track                    [Page 31]

RFC 2275                    VACM for SNMPv3                 January 1998


4) Initial access rights

   Three entries in the vacmAccessTable as follows:

   - read-notify access for securityModel USM, securityLevel
     "noAuthNoPriv" on behalf of securityNames that belong to the group
     "initial" to the <restricted> MIB view in the default context with
     contextName "".

   - read-write-notify access for securityModel USM, securityLevel
     "authNoPriv" on behalf of securityNames that belong to the group
     "initial" to the <internet> MIB view in the default context with
     contextName "".

   - if privacy is supported,
     read-write-notify access for securityModel USM, securityLevel
     "authPriv" on behalf of securityNames that belong to the group
     "initial" to the <internet> MIB view in the default context with
     contextName "".

   That translates into the following entries in the vacmAccessTable.
   Those columns marked with (index) are index-only objects and are not
   really present in this table.

   - One entry to be used for unauthenticated access (noAuthNoPriv):


                               no privacy support  privacy support
                               ------------------  ---------------
    vacmAccessContextPrefix    ""                  ""
    vacmGroupName     (index)  "initial"           "initial"
    vacmSecurityModel (index)  3 (USM)             3 (USM)
    vacmAccessSecurityLevel    noAuthNoPriv        noAuthNoPriv
    vacmAccessReadViewName     "restricted"        "restricted"
    vacmAccessWriteViewName    ""                  ""
    vacmAccessNotifyViewName   "restricted"        "restricted"
    vacmAccessStorageType      anyValidStorageType anyValidStorageType
    vacmAccessStatus           active              active

   - One entry to be used for authenticated access but without
     privacy (authNoPriv):
                               no privacy support  privacy support
                               ------------------  ---------------
    vacmAccessContextPrefix    ""                  ""
    vacmGroupName     (index)  "initial"           "initial"
    vacmSecurityModel (index)  3 (USM)             3 (USM)
    vacmAccessSecurityLevel    authNoPriv          authNoPriv
    vacmAccessReadViewName     "internet"          "internet"



Wijnen, et. al.             Standards Track                    [Page 32]

RFC 2275                    VACM for SNMPv3                 January 1998


    vacmAccessWriteViewName    "internet"          "internet"
    vacmAccessNotifyViewName   "internet"          "internet"
    vacmAccessStorageType      anyValidStorageType anyValidStorageType
    vacmAccessStatus           active              active

   - One entry to be used for authenticated access with privacy
     (authPriv):

                               no privacy support  privacy support
                               ------------------  ---------------
    vacmAccessContextPrefix                        ""
    vacmGroupName     (index)                      "initial"
    vacmSecurityModel (index)                      3 (USM)
    vacmAccessSecurityLevel                        authPriv
    vacmAccessReadViewName                         "internet"
    vacmAccessWriteViewName                        "internet"
    vacmAccessNotifyViewName                       "internet"
    vacmAccessStorageType                          anyValidStorageType
    vacmAccessStatus                               active

5) Two MIB views, of which the second one depends on the security
   configuration.

   -  One view, the <internet> view, for authenticated access:

      -  the <internet> MIB view is the following subtree:
             "internet"  (subtree 1.3.6.1)

   -  A second view, the <restricted> view, for unauthenticated
      access.  This view is configured according to the selected
      security configuration:

      -  For the initial-no-access-configuration there is no default
         initial configuration, so no MIB views are pre-scribed.

      -  For the initial-semi-secure-configuration:

         the <restricted> MIB view is the union of these subtrees:
         (a) "system"       (subtree 1.3.6.1.2.1.1)     [RFC1907]
         (b) "snmp"         (subtree 1.3.6.1.2.1.11)    [RFC1907]
         (c) "snmpEngine"   (subtree 1.3.6.1.6.3.7.2.1) [RFC2271]
         (d) "snmpMPDStats" (subtree 1.3.6.1.6.3.8.2.1) [RFC2272]
         (e) "usmStats"     (subtree 1.3.6.1.6.3.9.2.1) [RFC2274]

      -  For the initial-minimum-secure-configuration:

         the <restricted> MIB view is the following subtree.
             "internet"  (subtree 1.3.6.1)



Wijnen, et. al.             Standards Track                    [Page 33]

RFC 2275                    VACM for SNMPv3                 January 1998


   This translates into the following "internet" entry in the
   vacmViewTreeFamilyTable:

                                minimum-secure      semi-secure
                                ----------------    ---------------
  vacmViewTreeFamilyViewName    "internet"          "internet"
  vacmViewTreeFamilySubtree     1.3.6.1             1.3.6.1
  vacmViewTreeFamilyMask        ""                  ""
  vacmViewTreeFamilyType        1 (included)        1 (included)
  vacmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType
  vacmViewTreeFamilyStatus      active              active

   In addition it translates into the following "restricted" entries
   in the vacmViewTreeFamilyTable:

                                minimum-secure      semi-secure
                                ----------------    ---------------
  vacmViewTreeFamilyViewName    "restricted"        "restricted"
  vacmViewTreeFamilySubtree     1.3.6.1             1.3.6.1.2.1.1
  vacmViewTreeFamilyMask        ""                  ""
  vacmViewTreeFamilyType        1 (included)        1 (included)
  vacmViewTreeFamilyStorageType anyValidStorageType anyValidStorageType
  vacmViewTreeFamilyStatus      active              active

  vacmViewTreeFamilyViewName                        "restricted"
  vacmViewTreeFamilySubtree                         1.3.6.1.2.1.11
  vacmViewTreeFamilyMask                            ""
  vacmViewTreeFamilyType                            1 (included)
  vacmViewTreeFamilyStorageType                     anyValidStorageType
  vacmViewTreeFamilyStatus                          active

  vacmViewTreeFamilyViewName                        "restricted"
  vacmViewTreeFamilySubtree                         1.3.6.1.6.3.7.2.1
  vacmViewTreeFamilyMask                            ""
  vacmViewTreeFamilyType                            1 (included)
  vacmViewTreeFamilyStorageType                     anyValidStorageType
  vacmViewTreeFamilyStatus                          active

  vacmViewTreeFamilyViewName                        "restricted"
  vacmViewTreeFamilySubtree                         1.3.6.1.6.3.8.2.1
  vacmViewTreeFamilyMask                            ""
  vacmViewTreeFamilyType                            1 (included)
  vacmViewTreeFamilyStorageType                     anyValidStorageType
  vacmViewTreeFamilyStatus                          active

  vacmViewTreeFamilyViewName                        "restricted"
  vacmViewTreeFamilySubtree                         1.3.6.1.6.3.9.2.1
  vacmViewTreeFamilyMask                            ""



Wijnen, et. al.             Standards Track                    [Page 34]

RFC 2275                    VACM for SNMPv3                 January 1998


  vacmViewTreeFamilyType                            1 (included)
  vacmViewTreeFamilyStorageType                     anyValidStorageType
  vacmViewTreeFamilyStatus                          active
















































Wijnen, et. al.             Standards Track                    [Page 35]

RFC 2275                    VACM for SNMPv3                 January 1998


B.  Full Copyright Statement

   Copyright (C) The Internet Society (1998).  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.
























Wijnen, et. al.             Standards Track                    [Page 36]