File: rfc3318.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 (3923 lines) | stat: -rw-r--r-- 144,530 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
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
2020
2021
2022
2023
2024
2025
2026
2027
2028
2029
2030
2031
2032
2033
2034
2035
2036
2037
2038
2039
2040
2041
2042
2043
2044
2045
2046
2047
2048
2049
2050
2051
2052
2053
2054
2055
2056
2057
2058
2059
2060
2061
2062
2063
2064
2065
2066
2067
2068
2069
2070
2071
2072
2073
2074
2075
2076
2077
2078
2079
2080
2081
2082
2083
2084
2085
2086
2087
2088
2089
2090
2091
2092
2093
2094
2095
2096
2097
2098
2099
2100
2101
2102
2103
2104
2105
2106
2107
2108
2109
2110
2111
2112
2113
2114
2115
2116
2117
2118
2119
2120
2121
2122
2123
2124
2125
2126
2127
2128
2129
2130
2131
2132
2133
2134
2135
2136
2137
2138
2139
2140
2141
2142
2143
2144
2145
2146
2147
2148
2149
2150
2151
2152
2153
2154
2155
2156
2157
2158
2159
2160
2161
2162
2163
2164
2165
2166
2167
2168
2169
2170
2171
2172
2173
2174
2175
2176
2177
2178
2179
2180
2181
2182
2183
2184
2185
2186
2187
2188
2189
2190
2191
2192
2193
2194
2195
2196
2197
2198
2199
2200
2201
2202
2203
2204
2205
2206
2207
2208
2209
2210
2211
2212
2213
2214
2215
2216
2217
2218
2219
2220
2221
2222
2223
2224
2225
2226
2227
2228
2229
2230
2231
2232
2233
2234
2235
2236
2237
2238
2239
2240
2241
2242
2243
2244
2245
2246
2247
2248
2249
2250
2251
2252
2253
2254
2255
2256
2257
2258
2259
2260
2261
2262
2263
2264
2265
2266
2267
2268
2269
2270
2271
2272
2273
2274
2275
2276
2277
2278
2279
2280
2281
2282
2283
2284
2285
2286
2287
2288
2289
2290
2291
2292
2293
2294
2295
2296
2297
2298
2299
2300
2301
2302
2303
2304
2305
2306
2307
2308
2309
2310
2311
2312
2313
2314
2315
2316
2317
2318
2319
2320
2321
2322
2323
2324
2325
2326
2327
2328
2329
2330
2331
2332
2333
2334
2335
2336
2337
2338
2339
2340
2341
2342
2343
2344
2345
2346
2347
2348
2349
2350
2351
2352
2353
2354
2355
2356
2357
2358
2359
2360
2361
2362
2363
2364
2365
2366
2367
2368
2369
2370
2371
2372
2373
2374
2375
2376
2377
2378
2379
2380
2381
2382
2383
2384
2385
2386
2387
2388
2389
2390
2391
2392
2393
2394
2395
2396
2397
2398
2399
2400
2401
2402
2403
2404
2405
2406
2407
2408
2409
2410
2411
2412
2413
2414
2415
2416
2417
2418
2419
2420
2421
2422
2423
2424
2425
2426
2427
2428
2429
2430
2431
2432
2433
2434
2435
2436
2437
2438
2439
2440
2441
2442
2443
2444
2445
2446
2447
2448
2449
2450
2451
2452
2453
2454
2455
2456
2457
2458
2459
2460
2461
2462
2463
2464
2465
2466
2467
2468
2469
2470
2471
2472
2473
2474
2475
2476
2477
2478
2479
2480
2481
2482
2483
2484
2485
2486
2487
2488
2489
2490
2491
2492
2493
2494
2495
2496
2497
2498
2499
2500
2501
2502
2503
2504
2505
2506
2507
2508
2509
2510
2511
2512
2513
2514
2515
2516
2517
2518
2519
2520
2521
2522
2523
2524
2525
2526
2527
2528
2529
2530
2531
2532
2533
2534
2535
2536
2537
2538
2539
2540
2541
2542
2543
2544
2545
2546
2547
2548
2549
2550
2551
2552
2553
2554
2555
2556
2557
2558
2559
2560
2561
2562
2563
2564
2565
2566
2567
2568
2569
2570
2571
2572
2573
2574
2575
2576
2577
2578
2579
2580
2581
2582
2583
2584
2585
2586
2587
2588
2589
2590
2591
2592
2593
2594
2595
2596
2597
2598
2599
2600
2601
2602
2603
2604
2605
2606
2607
2608
2609
2610
2611
2612
2613
2614
2615
2616
2617
2618
2619
2620
2621
2622
2623
2624
2625
2626
2627
2628
2629
2630
2631
2632
2633
2634
2635
2636
2637
2638
2639
2640
2641
2642
2643
2644
2645
2646
2647
2648
2649
2650
2651
2652
2653
2654
2655
2656
2657
2658
2659
2660
2661
2662
2663
2664
2665
2666
2667
2668
2669
2670
2671
2672
2673
2674
2675
2676
2677
2678
2679
2680
2681
2682
2683
2684
2685
2686
2687
2688
2689
2690
2691
2692
2693
2694
2695
2696
2697
2698
2699
2700
2701
2702
2703
2704
2705
2706
2707
2708
2709
2710
2711
2712
2713
2714
2715
2716
2717
2718
2719
2720
2721
2722
2723
2724
2725
2726
2727
2728
2729
2730
2731
2732
2733
2734
2735
2736
2737
2738
2739
2740
2741
2742
2743
2744
2745
2746
2747
2748
2749
2750
2751
2752
2753
2754
2755
2756
2757
2758
2759
2760
2761
2762
2763
2764
2765
2766
2767
2768
2769
2770
2771
2772
2773
2774
2775
2776
2777
2778
2779
2780
2781
2782
2783
2784
2785
2786
2787
2788
2789
2790
2791
2792
2793
2794
2795
2796
2797
2798
2799
2800
2801
2802
2803
2804
2805
2806
2807
2808
2809
2810
2811
2812
2813
2814
2815
2816
2817
2818
2819
2820
2821
2822
2823
2824
2825
2826
2827
2828
2829
2830
2831
2832
2833
2834
2835
2836
2837
2838
2839
2840
2841
2842
2843
2844
2845
2846
2847
2848
2849
2850
2851
2852
2853
2854
2855
2856
2857
2858
2859
2860
2861
2862
2863
2864
2865
2866
2867
2868
2869
2870
2871
2872
2873
2874
2875
2876
2877
2878
2879
2880
2881
2882
2883
2884
2885
2886
2887
2888
2889
2890
2891
2892
2893
2894
2895
2896
2897
2898
2899
2900
2901
2902
2903
2904
2905
2906
2907
2908
2909
2910
2911
2912
2913
2914
2915
2916
2917
2918
2919
2920
2921
2922
2923
2924
2925
2926
2927
2928
2929
2930
2931
2932
2933
2934
2935
2936
2937
2938
2939
2940
2941
2942
2943
2944
2945
2946
2947
2948
2949
2950
2951
2952
2953
2954
2955
2956
2957
2958
2959
2960
2961
2962
2963
2964
2965
2966
2967
2968
2969
2970
2971
2972
2973
2974
2975
2976
2977
2978
2979
2980
2981
2982
2983
2984
2985
2986
2987
2988
2989
2990
2991
2992
2993
2994
2995
2996
2997
2998
2999
3000
3001
3002
3003
3004
3005
3006
3007
3008
3009
3010
3011
3012
3013
3014
3015
3016
3017
3018
3019
3020
3021
3022
3023
3024
3025
3026
3027
3028
3029
3030
3031
3032
3033
3034
3035
3036
3037
3038
3039
3040
3041
3042
3043
3044
3045
3046
3047
3048
3049
3050
3051
3052
3053
3054
3055
3056
3057
3058
3059
3060
3061
3062
3063
3064
3065
3066
3067
3068
3069
3070
3071
3072
3073
3074
3075
3076
3077
3078
3079
3080
3081
3082
3083
3084
3085
3086
3087
3088
3089
3090
3091
3092
3093
3094
3095
3096
3097
3098
3099
3100
3101
3102
3103
3104
3105
3106
3107
3108
3109
3110
3111
3112
3113
3114
3115
3116
3117
3118
3119
3120
3121
3122
3123
3124
3125
3126
3127
3128
3129
3130
3131
3132
3133
3134
3135
3136
3137
3138
3139
3140
3141
3142
3143
3144
3145
3146
3147
3148
3149
3150
3151
3152
3153
3154
3155
3156
3157
3158
3159
3160
3161
3162
3163
3164
3165
3166
3167
3168
3169
3170
3171
3172
3173
3174
3175
3176
3177
3178
3179
3180
3181
3182
3183
3184
3185
3186
3187
3188
3189
3190
3191
3192
3193
3194
3195
3196
3197
3198
3199
3200
3201
3202
3203
3204
3205
3206
3207
3208
3209
3210
3211
3212
3213
3214
3215
3216
3217
3218
3219
3220
3221
3222
3223
3224
3225
3226
3227
3228
3229
3230
3231
3232
3233
3234
3235
3236
3237
3238
3239
3240
3241
3242
3243
3244
3245
3246
3247
3248
3249
3250
3251
3252
3253
3254
3255
3256
3257
3258
3259
3260
3261
3262
3263
3264
3265
3266
3267
3268
3269
3270
3271
3272
3273
3274
3275
3276
3277
3278
3279
3280
3281
3282
3283
3284
3285
3286
3287
3288
3289
3290
3291
3292
3293
3294
3295
3296
3297
3298
3299
3300
3301
3302
3303
3304
3305
3306
3307
3308
3309
3310
3311
3312
3313
3314
3315
3316
3317
3318
3319
3320
3321
3322
3323
3324
3325
3326
3327
3328
3329
3330
3331
3332
3333
3334
3335
3336
3337
3338
3339
3340
3341
3342
3343
3344
3345
3346
3347
3348
3349
3350
3351
3352
3353
3354
3355
3356
3357
3358
3359
3360
3361
3362
3363
3364
3365
3366
3367
3368
3369
3370
3371
3372
3373
3374
3375
3376
3377
3378
3379
3380
3381
3382
3383
3384
3385
3386
3387
3388
3389
3390
3391
3392
3393
3394
3395
3396
3397
3398
3399
3400
3401
3402
3403
3404
3405
3406
3407
3408
3409
3410
3411
3412
3413
3414
3415
3416
3417
3418
3419
3420
3421
3422
3423
3424
3425
3426
3427
3428
3429
3430
3431
3432
3433
3434
3435
3436
3437
3438
3439
3440
3441
3442
3443
3444
3445
3446
3447
3448
3449
3450
3451
3452
3453
3454
3455
3456
3457
3458
3459
3460
3461
3462
3463
3464
3465
3466
3467
3468
3469
3470
3471
3472
3473
3474
3475
3476
3477
3478
3479
3480
3481
3482
3483
3484
3485
3486
3487
3488
3489
3490
3491
3492
3493
3494
3495
3496
3497
3498
3499
3500
3501
3502
3503
3504
3505
3506
3507
3508
3509
3510
3511
3512
3513
3514
3515
3516
3517
3518
3519
3520
3521
3522
3523
3524
3525
3526
3527
3528
3529
3530
3531
3532
3533
3534
3535
3536
3537
3538
3539
3540
3541
3542
3543
3544
3545
3546
3547
3548
3549
3550
3551
3552
3553
3554
3555
3556
3557
3558
3559
3560
3561
3562
3563
3564
3565
3566
3567
3568
3569
3570
3571
3572
3573
3574
3575
3576
3577
3578
3579
3580
3581
3582
3583
3584
3585
3586
3587
3588
3589
3590
3591
3592
3593
3594
3595
3596
3597
3598
3599
3600
3601
3602
3603
3604
3605
3606
3607
3608
3609
3610
3611
3612
3613
3614
3615
3616
3617
3618
3619
3620
3621
3622
3623
3624
3625
3626
3627
3628
3629
3630
3631
3632
3633
3634
3635
3636
3637
3638
3639
3640
3641
3642
3643
3644
3645
3646
3647
3648
3649
3650
3651
3652
3653
3654
3655
3656
3657
3658
3659
3660
3661
3662
3663
3664
3665
3666
3667
3668
3669
3670
3671
3672
3673
3674
3675
3676
3677
3678
3679
3680
3681
3682
3683
3684
3685
3686
3687
3688
3689
3690
3691
3692
3693
3694
3695
3696
3697
3698
3699
3700
3701
3702
3703
3704
3705
3706
3707
3708
3709
3710
3711
3712
3713
3714
3715
3716
3717
3718
3719
3720
3721
3722
3723
3724
3725
3726
3727
3728
3729
3730
3731
3732
3733
3734
3735
3736
3737
3738
3739
3740
3741
3742
3743
3744
3745
3746
3747
3748
3749
3750
3751
3752
3753
3754
3755
3756
3757
3758
3759
3760
3761
3762
3763
3764
3765
3766
3767
3768
3769
3770
3771
3772
3773
3774
3775
3776
3777
3778
3779
3780
3781
3782
3783
3784
3785
3786
3787
3788
3789
3790
3791
3792
3793
3794
3795
3796
3797
3798
3799
3800
3801
3802
3803
3804
3805
3806
3807
3808
3809
3810
3811
3812
3813
3814
3815
3816
3817
3818
3819
3820
3821
3822
3823
3824
3825
3826
3827
3828
3829
3830
3831
3832
3833
3834
3835
3836
3837
3838
3839
3840
3841
3842
3843
3844
3845
3846
3847
3848
3849
3850
3851
3852
3853
3854
3855
3856
3857
3858
3859
3860
3861
3862
3863
3864
3865
3866
3867
3868
3869
3870
3871
3872
3873
3874
3875
3876
3877
3878
3879
3880
3881
3882
3883
3884
3885
3886
3887
3888
3889
3890
3891
3892
3893
3894
3895
3896
3897
3898
3899
3900
3901
3902
3903
3904
3905
3906
3907
3908
3909
3910
3911
3912
3913
3914
3915
3916
3917
3918
3919
3920
3921
3922
3923






Network Working Group                                     R. Sahita, Ed.
Request for Comments: 3318                                       S. Hahn
Category: Informational                                       Intel Labs
                                                                 K. Chan
                                                         Nortel Networks
                                                           K. McCloghrie
                                                           Cisco Systems
                                                              March 2003


                   Framework Policy Information Base

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 (2003).  All Rights Reserved.

Abstract

   This document defines a set of PRovisioning Classes (PRCs) and
   textual conventions that are common to all clients that provision
   policy using Common Open Policy Service (COPS) protocol for
   Provisioning.

   Structure of Policy Provisioning Information (SPPI) describes a
   structure for specifying policy information that can then be
   transmitted to a network device for the purpose of configuring policy
   at that device.  The model underlying this structure is one of well-
   defined (PRCs) and instances of these classes (PRIs) residing in a
   virtual information store called the Policy Information Base (PIB).

   One way to provision policy is by means of the (COPS) protocol with
   the extensions for provisioning.  This protocol supports multiple
   clients, each of which may provision policy for a specific policy
   domain such as QoS, virtual private networks, or security.

   As described in COPS usage for Policy Provisioning (COPS-PR), each
   client supports a non-overlapping and independent set of PIB modules.
   However, some PRovisioning Classes are common to all subject-
   categories (client-types) and need to be present in each.






Sahita, et. al.              Informational                      [Page 1]

RFC 3318           Framework Policy Information Base          March 2003


Table of Contents

   Conventions used in this document.................................2
   1. Glossary.......................................................2
   2. General PIB Concepts...........................................3
     2.1. Roles......................................................3
       2.1.1. An Example.............................................5
     2.2. Management of Role-Combinations from the PDP...............6
     2.3. Updating a Request State...................................7
       2.3.1 Full Request State......................................8
       2.3.2 Installing PRIs in a Request............................8
       2.3.3 Updating PRIs in a Request..............................8
       2.3.4 Removing PRIs from a Request............................9
       2.3.5 Removing EXTENDED, AUGMENTED PRIs.......................9
       2.3.6 Error Handling in Request updates.......................9
     2.4. Multiple PIB Instances....................................10
     2.5. Reporting and Configuring of Device Capabilities..........11
     2.6. Reporting of Device Limitations...........................12
   3. The Framework TC PIB module...................................12
   4. Summary of the Framework PIB..................................17
     4.1. Base PIB classes Group....................................17
     4.2. Device Capabilities group.................................19
     4.3. Classifier group..........................................20
     4.4. Marker group..............................................20
   5. The Framework PIB Module......................................21
   6. Security Considerations.......................................66
   7. IANA Considerations...........................................67
   8. References....................................................67
     8.1 Normative References.......................................67
     8.2 Informative References.....................................68
   9. Acknowledgments...............................................68
   10. Authors' Addresses...........................................69
   11. Full Copyright Statement.....................................70

Conventions used in this document

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

1. Glossary

   PRC    PRovisioning Class.  A type of policy data.  See [POLTERM].
   PRI    PRovisioning Instance.  An instance of a PRC.  See [POLTERM].
   PIB    Policy Information Base.  The database of policy information.
          See [POLTERM]
   PDP    Policy Decision Point.  See [RAP-FRAMEWORK].
   PEP    Policy Enforcement Point.  See [RAP-FRAMEWORK].



Sahita, et. al.              Informational                      [Page 2]

RFC 3318           Framework Policy Information Base          March 2003



2. General PIB Concepts

2.1. Roles

   The policy to apply to an interface may depend on many factors, such
   as immutable characteristics of the interface (e.g., Ethernet or
   frame relay), the status of the interface (e.g., half or full
   duplex), or user configuration (e.g., branch office or headquarters
   interface).  Rather than specifying policies explicitly for each
   interface of all devices in the network, policies are specified in
   terms of interface functionality.

   To describe these functionalities of an interface, we use the concept
   of "Roles".  A Role is simply a string that is associated with an
   interface.  A given interface may have any number of roles
   simultaneously.  Provisioning classes have an attribute called a
   "RoleCombination" which is a lexicographically ordered set of roles.
   Instances of a given PRovisioning Class are applied to an interface
   if and only if the set of roles in the role combination matches the
   set of the roles of the interface.

   Thus, roles provide a way to bind policy to interfaces without having
   to explicitly identify interfaces in a consistent manner across all
   network devices.  That is, roles provide a level of indirection to
   the application of a set of policies to specific interfaces.  This
   separates the policy definition from device implementation specific
   interface identification.  Furthermore, if the same policy is being
   applied to several interfaces, that policy needs to be pushed to the
   device only once, rather than once per interface, as long as the
   interfaces are configured with the same role combination.

   We point out that, in the event that the administrator needs to have
   a unique policy for each interface, the administrator can configure
   each interface with a unique role.

   The PEP sends all its Capability Set Names, Role Combinations, Policy
   Controlled Interfaces, and their relationships to the PDP in the
   first COPS request (REQ) message for a handle, and whenever any
   updates or deletes occur.  The PDP can install new instances or
   change existing instances of these PRIs.  This operation can also
   occur in subsequent request messages generated in response to COPS
   state synchronization (SSQ) requests and local configuration changes.

   The comparing of roles (or role combinations) is case sensitive.






Sahita, et. al.              Informational                      [Page 3]

RFC 3318           Framework Policy Information Base          March 2003


   By convention, when formatting the role-combination for exchange
   within a protocol message, within a PIB object's value, or as a
   printed value, the set is formatted in lexicographical order of the
   role's ASCII values; that is, the role that is first is formatted
   first.  For example, "a+b" and "b+a" are NOT different role-
   combinations; rather, they are different formatting of the same
   role-combination, and hence for this example:

   - "a+b" is the valid formatting of that role-combination,
   - "b+a" is an invalid formatting of that role-combination.

   The role-combination of interfaces to which no roles have been
   assigned is known as the "null" role-combination.  (Note the
   deliberate use of lower-case letters for "null" so that it avoids
   confusion with the ASCII NULL character that has a value of zero but
   a length of one.)

   In an "install" or an "install-notify" class, the wildcard role-
   combination "*" can be used.  In addition to providing for
   interface-specific roles, it also allows for other optimizations in
   reducing the number of role-combinations for which a policy has to be
   specified.  For example:

   Suppose we have three interfaces:

      Roles A, B and R1 are assigned to interface I1
      Roles A, B and R2 are assigned to interface I2
      Roles A, B and R3 are assigned to interface I3

   Then, a PRI of a fictional IfDscpAssignTable that has the following
   values for its attributes:

      ifDscpAssignPrid    = 1
      ifDscpAssignRoles   = "*+A+B"
      ifDscpAssignName    = "4queues"
      ifDscpAssignDscpMap = 1

   will apply to all three interfaces, because "*" matches with R1, R2
   and R3.  The policies can be assigned to an interface due to more
   than one wild-carded role combo matching a given interface's role
   combo string.  The PDP should attempt to resolve conflicts between
   policies before sending policies to the PEP.  In the situation where
   the PDP sends multiple policies to a PEP and they do conflict, either
   because of an error by the PDP or because of a device specific
   conflict, the PEP MUST reject the installation of the conflicting
   policies and return an error.





Sahita, et. al.              Informational                      [Page 4]

RFC 3318           Framework Policy Information Base          March 2003


   Formally,
   - The wildcard Role is denoted by "*",
   - The "*" Role is not allowed to be defined as part of the role-
     combination of an interface as notified by the PEP to the PDP; it
     is only allowed in policies installed/deleted via COPS-PR from the
     PDP to the PEP.
   - For a policy to apply to an interface when the policy's role-
     combination is "*+a+b", the interface's role-combination:
      - Must include "a" and "b", and
      - Can include zero or more other roles.
   - The wildcard character "*" is listed before the other roles as "*"
     is lexicographically before "a"; however, the wildcard matches any
     zero or more roles, irrespective of lexicographical order.  For
     example: "*+b+e+g" would match "a+b+c+e+f+g".

     Note that the characters "+" and "*" MUST not be used in an
     interface Role.  The Framework Role PIB module in section 4 of this
     document contains the Role and RoleCombination Textual Conventions.

2.1.1. An Example

   The functioning of roles might be best understood by an example.
   Suppose I have a device with three interfaces, with roles as follows:

         IF1: "finance"
         IF2: "finance"
         IF3: "manager"

   Suppose, I also have a PDP with two policies:

         P1: Packets from finance department (role "finance") get DSCP 5
         P2: Packets from managers (role "manager") get DSCP 6

   To obtain policy, the PEP reports to the PDP that it has some
   interfaces with role combination "finance" and some with role
   combination "manager".  In response, the PDP downloads policy P1
   associated with role combination "finance" and downloads a second
   policy P2 associated with role combination "manager".

   Now suppose the finance person attached to IF2 is promoted to manager
   and so the system administrator adds the role "manager" to IF2.  The
   PEP now reports to the PDP that it has three role combinations: some
   interfaces with role combination "finance", some with role
   combination "manager" and some with role combination
   "finance+manager".  In response, the PDP downloads an additional
   third policy associated with the new role combination
   "finance+manager".




Sahita, et. al.              Informational                      [Page 5]

RFC 3318           Framework Policy Information Base          March 2003


   How the PDP determines the policy for this new role combination is
   entirely the responsibility of the PDP.  It could do so
   algorithmically or by rule.  For example, there might be a rule that
   specifies that manager policy takes preference over department
   policy.  Or there might be a third policy installed in the PDP as
   follows:

         P3: Packets from finance managers (role "finance" and role
             "manager") get DSCP 7

   The point here is that the PDP is required to determine what policy
   applies to this new role combination and to download a third policy
   to the PEP for the role combination "finance+manager", even if that
   policy is the same as one already downloaded.  The PEP is not
   required (or allowed) to construct policy for new role combinations
   from existing policy.

2.2. Management of Role-Combinations from the PDP

   The PEP notifies the PDP of the Role-Combination assigned to each
   interface and capability set name in a COPS configuration request
   (instances of the frwkIfRoleComboTable).  The first request sent to
   the PDP must be a 'full state' request.  A 'full state' request for a
   PEP includes notify and install-notify table PRIs for the PEP which
   must be interpreted as the complete state of the PEP and must not be
   interpreted as updates to any previous set of PRIs sent in a previous
   message.  Any previous PRIs from the PEP should be discarded when a
   'full state' request is received for the particular request handle.
   A request is specified as a 'full state' request by setting the
   frwkPibIncarnationFullState attribute in the frwkPibIncarnation PRI
   sent in the request.

   All existing frwkIfRoleCombo instances must be sent to the PDP in the
   first configuration request for a request handle.  If the Role-
   Combinations are not assigned specific values, default ('null')
   Role-Combinations must be sent to the PDP for all ifIndices active on
   the PEP and updates must be sent every time the IfIndices are
   updated.  The PEP may notify the PDP of the Capability sets (if any)
   via the frwkCapabilitySetTable.  If the PEP does not need to notify
   the PDP of capability sets, it must set the capability set name in
   the frwkIfRoleComboTable instances to a zero length string.

   In response to this configuration request, if applicable, the PDP may
   send policies for the PEP in a solicited decision or must send a null
   decision.  The PEP must then send a solicited report message for the
   decision.





Sahita, et. al.              Informational                      [Page 6]

RFC 3318           Framework Policy Information Base          March 2003


   At any later time, the PDP can update the Role-Combinations assigned
   to a specific interface, identified by IfIndex, or for an aggregate,
   identified by the capability set name, via an unsolicited decision to
   the PEP on any open request handle.  The PDP does this by sending
   updated PRIs for the frwkIfRoleComboTable.

   When the Interface Role Combination associations are updated by the
   PDP, the PEP SHOULD send updated 'full state' requests for all open
   contexts.  A context is an instantiation of the PIB module(s)
   namespace identified by a unique COPS handle for a particular COPS
   client type.  This is true even if the PEP's request state changes
   due to an internal event or if the state is changed by the PDP.  If
   the role-combination updates were sent by the PDP, the PEP SHOULD
   send these updated requests only if it can process the unsolicited
   decision containing the frwkIfRoleCombo PRIs successfully, and it
   MUST do so after sending the success report for the unsolicited
   decision.  If the PEP failed to process the decision (i.e., the
   frwkIfRoleCombo PRIs), it MUST only send a failure report to the PDP.

   On the other hand, the PDP must not expect to receive the updated
   requests with the revised role-combination information until after it
   receives a success report for these updates from the PEP.  If the PDP
   does not receive updated requests on some request handles, the PEP
   must not be sent decision updates for that frwkIfRoleCombo updates,
   i.e., the PDP must have the previous request state that it maintained
   for that request handle.

   Note that, any unsolicited decisions received by the PEP in the time
   period after it receives updates to its Role-Combination associations
   and before receiving solicited decisions for the updated requests it
   sent for all context handles, could possibly contain outdated
   policies corresponding to the old Role-Combination associations as
   notified by this PEP in a previous request state.

   The PDP must respond to the updated requests by solicited decisions,
   sending policies if applicable or null decisions.  The PEP must
   respond to these solicited decisions with solicited reports to
   complete the transaction.

2.3. Updating a Request State

   This section describes the messages exchanged between the PEP and PDP
   when the PEP is updating a previously sent request for a particular
   COPS handle.  Note that a PEP can incrementally update a request only
   if the frwkPibIncarnationFullState attribute is shown to be supported
   via the supported PRC table.  If this attribute is not supported, the
   PDP must treat all PEP requests as the full request state.




Sahita, et. al.              Informational                      [Page 7]

RFC 3318           Framework Policy Information Base          March 2003


2.3.1 Full Request State

   When the PEP wants to send the entire request state to the PDP (for
   example, in response to a Synchronize State Request from the PDP),
   the PEP MUST send the incarnation instance with the
   frwkPibIncarnationFullState attribute set to 'true'.

   A PDP that receives an incarnation instance in the request message
   with this attribute set to 'true', must clear the request information
   it maintains for this request handle and re-install the information
   received.

   If this attribute is set to 'false' or if the incarnation instance is
   missing in the request message, the request must be interpreted as an
   incremental update to the previous request message.

2.3.2 Installing PRIs in a Request

   If the PEP wants to install additional PRIs for a request handle, the
   PEP MUST ensure that the frwkPibIncarnationFullState attribute is set
   to 'false', and the PEP MUST use new (unused in this context)
   InstanceIds [SPPI] for these PRIs.

   When a PDP receives instances with new InstanceIds for a request with
   the frwkPibIncarnationFullState in the incarnation instance set to
   'false', or if the request has no incarnation information, it must
   interpret these PRIs as an incremental update to the request state
   and add them to the request state it maintains for this handle.

2.3.3 Updating PRIs in a Request

   If the PEP wants to update previously installed PRIs for a request
   handle, the PEP MUST ensure that the frwkPibIncarnationFullState
   attribute is set to 'false' for these PRIs.  Note that the PEP must
   send the same InstanceIds for the PRIs being updated.  If the PEP
   uses new InstanceIds, the PDP must interpret them as Install's for
   this request state.

   When a PDP receives a request with instances having InstanceIds that
   exist in its state for that handle with the
   frwkPibIncarnationFullState in the incarnation instance set to
   'false' or if the request has no incarnation information, it must
   interpret these PRIs as an update to the PRIs in the request state it
   maintains for this handle.







Sahita, et. al.              Informational                      [Page 8]

RFC 3318           Framework Policy Information Base          March 2003


2.3.4 Removing PRIs from a Request

   If the PEP wants to remove previously installed PRIs for a request
   handle, the PEP MUST ensure that the frwkPibIncarnationFullState
   attribute is set to 'false', and MUST send the PRI bindings with the
   PRID set to the InstanceId of the PRI to be removed, and the length
   field in the EPD object header set to the header length only,
   effectively setting the data length to zero.

   Note that the PEP must send the same InstanceIds for the PRIs being
   removed.  If the PEP sends new InstanceIds and the length field in
   the EPD object header is set to the header length only (implying the
   data length is zero), the PEP is attempting to remove an
   unknown/non-existent PRI.  This SHOULD result in the PDP sending
   error PRIs in the solicited decision (see section 2.3.6 for a
   description of the frwkErrorTable).

   If the PEP sends new InstanceIds, and the length field in the EPD
   object header is greater than the header length only (implying the
   EPD object has some attributes encoded in it), the PDP will interpret
   this as an install of the PRI if it can decode the EPD successfully.

   When a PDP receives a request with instances having InstanceIds that
   exist in its state for that handle with the
   frwkPibIncarnationFullState in the incarnation instance set to
   'false', or if the request has no incarnation information, and the
   length field in the EPD object header is set to the header length
   only (implying the data length is zero), it must remove these PRIs
   from the request state it maintains for this handle.

2.3.5 Removing EXTENDED, AUGMENTED PRIs

   The PEP should remove the extended/augmented PRIs when it removes the
   base PRIs in the same COPS message.  See [SPPI] for a description of
   EXTENDED/AUGMENTED PRCs.  A PDP that receives removes for a base PRI
   must implicitly remove the extensions.

2.3.6 Error Handling in Request updates

   If the PDP cannot process all the request installs/updates/removes in
   the COPS request message successfully, it MUST rollback to its
   previous request state and it MUST send a solicited decision to the
   PEP that contains frwkErrorTable instances.  These instances contain
   an error code and a sub-code as defined in the [COPS-PR] CPERR
   object.  For example, if the PEP tries to remove an instance that
   does not exist, the 'priInstanceInvalid' error code must be sent to
   the PEP in a frwkError PRI.  The frwkError PRIs also contain the PRC
   and the InstanceId of the error-causing PRI.  The PEP may then



Sahita, et. al.              Informational                      [Page 9]

RFC 3318           Framework Policy Information Base          March 2003


   examine these error PRIs and resend the modified request.  Note that,
   until the PEP resends the request updates/removes, it will have
   configuration information for the last successful request state it
   sent to the PDP.

2.4. Multiple PIB Instances

   [COPS-PR] supports multiple, disjoint, independent instances of the
   PIB to represent multiple instances of configured policy.  The intent
   is to allow for the pre-provisioning of policy that can then be made
   active by a single, short decision from the PDP.

   A COPS context can be defined as an independent COPS request state
   for a particular subject category (client-type).  A context may be an
   outsourcing context or a configuration context.  A configuration
   context is an instance of the PIB triggered and controlled by the
   PDP, which contains device setup information.  This device
   configuration information dictates the device behavior as specified
   by the PDP.  An outsourcing context on the other hand, is a PIB
   instance that is triggered from the PEP side and is a request to the
   PDP for action.  The action requested will be interpreted in the
   domain of the client-type.  Configuration contexts belong to a set of
   configuration contexts for a specific client type - out of which one
   configuration context may be active.  However, multiple outsourcing
   contexts can be active simultaneously.

   With the [COPS-PR] protocol, each of these states is identified by a
   unique client handle.  The creation and deletion of these PIB
   instances can be controlled by the PDP as described in [COPS-PR] or
   can be triggered by an event by the PEP.  A PEP must open at least
   one "request-state" for configuration for a given subject-category
   (client type).  Additional "request-states" at the PEP may be
   initiated by the PDP or asynchronously generated by the PEP for
   outsourcing due to local events, which will be fully specified by the
   PRID/EPD data carried in the request.

   The frwkPibIncarnationInCtxtSet flag defines a set of contexts out of
   which only one context can be active at any given time.  This set is
   called the 'configuration contexts' set.  At most, one context may be
   active from this 'configuration context' set at any given time.
   Contexts that have the frwkPibIncarnationInCtxtSet attribute set to
   'true' belong to this set.  Contexts that do not belong to this set
   have the frwkPibIncarnationInCtxtSet set to 'false' and belong to the
   set of 'outsourcing contexts'.  Note that a PEP can have these two
   sets of contexts only if the frwkPibIncarnationInCtxtSet attribute is
   shown to be supported via the supported PRC table.  If the





Sahita, et. al.              Informational                     [Page 10]

RFC 3318           Framework Policy Information Base          March 2003


   frwkPibIncarnationInCtxtSet is not supported, a PEP must treat all
   contexts as belonging to the set of 'configuration contexts' i.e., at
   the most one context can be active at any given time.

   Note that in the event that a PEP has a capability change such as a
   card hot swap or any other change in its notify information that may
   warrant a policy refresh, a subsequent complete or incremental
   request must be issued to the PDP containing the new/updated
   capabilities for all the configuration contexts.  A request for re-
   configuration is issued for all request state configuration contexts,
   both for the active configuration context as well as any inactive
   configuration contexts.  This is to ensure that when an inactive
   configuration context is activated, it has been pre-configured with
   policies compatible with the PEP's current capabilities.

   Although many PIB instances may be configured on a device (the
   maximum number of these instances being determined by the device
   itself), only one of the contexts from the 'configuration contexts'
   set can be active at any given time; the active one being selected by
   the PDP.  The Framework PIB supports the attribute
   frwkPibIncarnationActive in the frwkPibIncarnationTable to allow the
   PDP to denote the PIB instance as being active in a COPS decision
   message, and similarly, to report the active state (active or not) of
   the PIB instance to the PDP in a COPS request message.

   When the PEP installs an attribute frwkPibIncarnationActive that is
   'true' in one PIB instance which belongs to the 'configuration
   contexts' set, the PEP must ensure, re-setting the attribute if
   necessary, that the frwkPibIncarnationActive attribute is 'false' in
   all other installed contexts that belong to this set.  To switch
   contexts, the PDP should set the frwkPibIncarnationActive attribute
   to 'true' in the context it wants to make the active context.  The
   PDP should set this attribute in a context to 'false' only if it
   wants to send an inactive context to the PEP or deactivate the active
   context on the PEP.  If an active context is made inactive without
   activating another context, the PEP must not have any policies
   enforced from any configuration contexts installed.

2.5. Reporting and Configuring of Device Capabilities

   Each network device providing policy-based services has its own
   inherent capabilities.  These capabilities can be hardware specific,
   e.g., an Ethernet interface supporting input classification, or can
   be statically configured, e.g., supported queuing disciplines.  These
   capabilities are organized into Capability Sets, with each Capability
   Set given a unique name (frwkCapabilitySetName) and associated with a
   set of Role Combinations.  In that way, each Role Combination may be
   associated with a set of interfaces.  These capabilities are



Sahita, et. al.              Informational                     [Page 11]

RFC 3318           Framework Policy Information Base          March 2003


   communicated to the PDP when policy is requested by the PEP.  Knowing
   device capabilities, the PDP can send the PRIs relevant to the
   specific device, rather than sending the entire PIB.

   Specific capability PRCs may be defined in other PIBs.  These
   capability instances are grouped via the frwkCapabilitySetTable.  If
   the PEP wishes to send capability information to the PDP, the PIB
   must indicate which capabilities the PEP may send to the PDP by means
   of the 'notify' PIB-ACCESS clause as described in [SPPI].  If a PIB
   does not have any capabilities to communicate to the PDP, it must not
   send any instances for the frwkCapabilitySetTable.  If in this case
   the frwkIfRoleCombo table is used to communicate role combinations
   assigned to interfaces (via IfIndex), the frwkRoleComboCapSetName
   attribute in the frwkIfRoleComboTable instances must be set to a zero
   length string.

2.6. Reporting of Device Limitations

   To facilitate efficient policy installation, it is important to
   understand a device's limitations in relation to the advertised
   device capabilities.  Limitations may be class-based, e.g., an
   "install" class is supported as a "notify" or only a limited number
   of class instances may be created, or attribute-based.  Attribute
   limitations, such as supporting a restricted set of enumerations or
   requiring related attributes to have certain values, detail
   implementation limitations at a fine level of granularity.

   A PDP can avoid certain installation issues in a proactive fashion by
   taking into account a device's limitations prior to policy
   installation rather than in a reactive mode during installation.  As
   with device capabilities, device limitations are communicated to the
   PDP when policy is requested.

   Reported device limitations may be accompanied by guidance values
   that can be used by a PDP to determine acceptable values for the
   identified attributes.

3. The Framework TC PIB module

FRAMEWORK-TC-PIB  PIB-DEFINITIONS ::= BEGIN

IMPORTS  MODULE-IDENTITY, TEXTUAL-CONVENTION,
         Unsigned32, pib FROM COPS-PR-SPPI;

frwkTcPib  MODULE-IDENTITY
    SUBJECT-CATEGORIES   { all }
    LAST-UPDATED "200302130000Z"  -- 13 Feb 2003
    ORGANIZATION "IETF RAP WG"



Sahita, et. al.              Informational                     [Page 12]

RFC 3318           Framework Policy Information Base          March 2003


    CONTACT-INFO "Keith McCloghrie
                  Cisco Systems, Inc.
                  170 West Tasman Drive,
                  San Jose, CA 95134-1706 USA
                  Phone: +1 408 526 5260
                  Email: kzm@cisco.com

                  John Seligson
                  Nortel Networks, Inc.
                  4401 Great America Parkway
                  Santa Clara, CA 95054 USA
                  Phone: +1 408 495 2992
                  Email: jseligso@nortelnetworks.com

                  Ravi Sahita
                  Intel Labs.
                  2111 NE 25th Ave.
                  Hillsboro, OR 97124 USA
                  Phone: +1 503 712 1554
                  Email: ravi.sahita@intel.com

                  RAP WG Mailing list: rap@ops.ietf.org "
    DESCRIPTION
         "The PIB module containing the Role and RoleCombination
         Textual Conventions and other generic TCs.

         Copyright (C) The Internet Society (2003). This version of
         this PIB module is part of RFC 3318; see the RFC itself for
         full legal notices."

    REVISION     "200302130000Z"  -- 13 Feb 2003
    DESCRIPTION  "Initial version, published in RFC 3318."
      ::= { pib 3 }

Role ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
        "A role represents a functionality characteristic or
        capability of a resource to which policies are applied.
        Examples of roles include Backbone_interface,
        Frame_Relay_interface, BGP-capable-router, web-server,
        firewall, etc.
        The only valid character set is US-ASCII. Valid characters
        are a-z, A-Z, 0-9, period, hyphen and underscore. A role
        must always start with a letter (a-z or A-Z). A role must
        not contain the US-ASCII characters '*' or '+' since they
        have special meaning associated with them, explained in the
        RoleCombination TEXTUAL CONVENTION."



Sahita, et. al.              Informational                     [Page 13]

RFC 3318           Framework Policy Information Base          March 2003


    SYNTAX OCTET STRING (SIZE (1..31))

RoleCombination ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
        "An octet string containing concatenated Roles. For the
        format specification of roles, refer to the 'Role' TEXTUAL-
        CONVENTION. A valid Role Combination must be formed by a set
        of valid Roles, concatenated by the US-ASCII character '+',
        where the roles are in lexicographic order from minimum to
        maximum. For example, 'a+b' and 'b+a' are NOT different
        role-combinations; rather, they are different formatting of
        the same (one) role-combination.

        Notice the roles within a role-combination are in
        Lexicographic order from minimum to maximum, hence, we
        declare:
        'a+b' is the valid formatting of the role-combination,
        'b+a' is an invalid formatting of the role-combination.

        Notice the need of zero-length role-combination as the role-
        combination of interfaces to which no roles have been
        assigned. This role-combination is also known as the 'null'
        role-combination. (Note the deliberate use of lower case
        letters to avoid confusion with the US-ASCII NULL character
        which has a value of zero but length of one.)

        The US-ASCII character '*' is used to specify a wild carded
        Role Combination. '*' must not be used to wildcard Roles.
        Hence, we declare:
        '*+a+b' is a valid wild carded Role Combination.
        'eth*+a+b' is not a valid wild carded Role Combination.
        Note that since Roles are lexicographically listed in a Role
        Combination, the following is an invalid role combination,
        since '*' is lexicographically before 'a': 'a+b+*'."
    SYNTAX OCTET STRING  (SIZE (0..255))

PrcIdentifierOid ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
        "An OID that identifies a PRC. The value MUST be an OID
        assigned to a PRC's entry definition. The Entry definition
        of a PRC has an OID value XxxTable.1 where XxxTable is the
        OID assigned to the PRC table object.

        An attribute with this syntax MUST specify a PRC, which is
        defined in the PIB module(s) registered in the context of
        the client-type used.



Sahita, et. al.              Informational                     [Page 14]

RFC 3318           Framework Policy Information Base          March 2003



        An attribute with this syntax cannot have the value 0.0
        (zeroDotZero). If the attribute using this syntax can be set
        to 0.0 use the PrcIdentifierOidOrZero TEXTUAL-CONVENTION
        which makes such use explicit."
    SYNTAX    OBJECT IDENTIFIER

PrcIdentifierOidOrZero ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
        "An OID that identifies a PRC or zeroDotZero (0.0). The
        value MUST be an OID assigned to a PRC's entry definition or
        0.0  (zeroDotZero). The Entry definition of a PRC has an OID
        value XxxTable.1 where XxxTable is the OID assigned to the
        PRC table object.

        An attribute with this syntax can have the value 0.0
        (zeroDotZero) to indicate that it currently does not
        identify a PRC."
    SYNTAX    OBJECT IDENTIFIER

AttrIdentifier ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
        "A Unsigned32 value that identifies an attribute in a PRC by
        its sub-id. The sub-id is the OID assigned to this attribute
        in the PRC definition.

        A AttrIdentifier value is always interpreted within the
        context of an attribute of type PrcIdentifierOid or
        PrcIdentifierOidOrZero. The PrcIdentifierOid (or
           PrcIdentifierOidOrZero) object which defines the context
        must be registered immediately before the object which uses
        the AttrIdentifier textual convention. If the context
        defining attribute is of type PrcIdentifierOidOrZero and has
        the value 0.0, then in that case this attribute value has no
        meaning.

        An attribute with this syntax MUST specify a sub-id which
        MUST be defined in the PRC identified (if any) in the
        PrcIdentifierOid (or PrcIdentifierOidOrZero) attribute. The
        PrcIdentifierOid (orZero) and the AttrIdentifier attributes
        together identify a particular attribute in a particular
        PRC.







Sahita, et. al.              Informational                     [Page 15]

RFC 3318           Framework Policy Information Base          March 2003


        An attribute with this syntax cannot have the value 0
        (zero). If the attribute using this syntax can be set
        to 0 use the AttrIdentifierOrZero TEXTUAL-CONVENTION which
        makes that explicit."
    SYNTAX    Unsigned32 (1..4294967295)

AttrIdentifierOrZero ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
        "A Unsigned32 value that identifies an attribute in a PRC by
        its sub-id or has the value 0 (zero). The sub-id if non-
        zero, is the OID assigned to this attribute in the PRC
        definition.

        An AttrIdentifierOrZero value is always interpreted within
        the context of an attribute of type PrcIdentifierOid or
        PrcIdentifierOidOrZero. The PrcIdentifierOid (or
        PrcIdentifierOidOrZero) object that defines the context must
        be registered immediately before the object which uses the
        AttrIdentifierOrZero textual convention. If the context
        defining attribute is of type PrcIdentifierOidOrZero and has
        the value 0.0, then in that case this attribute value has no
        meaning.

        An attribute with this syntax can have the value 0 (zero) to
        indicate that it currently does not identify a PRC
        attribute. If it has a non-zero value, the
        PrcIdentifierOid (orZero) and the AttrIdentifierOrZero
        attributes together identify a particular attribute in a
        particular PRC."
    SYNTAX    Unsigned32

AttrIdentifierOid ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
        "An OID that identifies an attribute in a PRC. The value
        MUST be an OID assigned to a PRC's attribute definition. The
        last sub-id is the sub-id of the attribute as it is
        defined in the PRC entry definition. The prefix OID (after
        dropping the last sub-id) is the OID assigned to the Entry
        object of a defined PRC. The Entry definition of a PRC has
        an OID value XxxTable.1 where XxxTable is the OID assigned
        to the PRC Table object.

        An attribute with this syntax MUST not have the value 0.0
        (zeroDotZero). If 0.0 is a valid value, the TEXTUAL
        CONVENTION AttrIdentifierOidOrZero must be used which makes
        such use explicit."



Sahita, et. al.              Informational                     [Page 16]

RFC 3318           Framework Policy Information Base          March 2003


    SYNTAX    OBJECT IDENTIFIER

AttrIdentifierOidOrZero ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
        "An OID that identifies an attribute in a PRC or has a value
         0.0 (zeroDotZero). The value MUST be an OID assigned to a
         PRC's attribute definition or the value 0.0.

         If not 0.0, the last sub-id MUST be the sub-id of the
         attribute as it is defined in the PRC Entry object
         definition. The prefix OID (after dropping the last sub-id)
         is the OID assigned to the Entry object of a defined PRC.
         The Entry definition of a PRC has an OID value XxxTable.1
         Where, XxxTable is the OID assigned to the PRC Table
         object.

         An attribute with this syntax can have the value 0.0
         (zeroDotZero) to indicate that it currently does not
         identify a PRC's attribute."
    SYNTAX    OBJECT IDENTIFIER

ClientType ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
        "An Unsigned32 value that identifies a COPS Client-type. An
        attribute with this syntax must be set to zero if it does
        not specify a COPS client-type for the PRI."
    REFERENCE
        "The COPS (Common Open Policy Service) Protocol, RFC 2748."
    SYNTAX    Unsigned32 (0..65535)

ClientHandle ::= TEXTUAL-CONVENTION
    STATUS       current
    DESCRIPTION
        "An octet string that identifies a COPS Client handle. A
        zero length value implies the attribute does not specify a
        valid client handle."
    REFERENCE
        "The COPS (Common Open Policy Service) Protocol, RFC 2748."
    SYNTAX    OCTET STRING (SIZE(0..65535))

END








Sahita, et. al.              Informational                     [Page 17]

RFC 3318           Framework Policy Information Base          March 2003


4. Summary of the Framework PIB

   The Framework PIB defines four groups of PRCs:

4.1. Base PIB classes Group

   This contains PRCs intended to describe the PRCs supported by the
   PEP, PRC and/or attribute limitations and its current configuration.

      PRC Support Table

         As the technology evolves, we expect devices to be enhanced
         with new PIBs, existing PIBs to add new PRCs and existing PRCs
         to be augmented or extended with new attributes.  Also, it is
         likely that some existing PRCs or individual attributes of PRCs
         will be deprecated.  The PRC Support Table describes the PRCs
         that the device supports as well as the individual attributes
         of each PRC.  Using this information the PDP can potentially
         tailor the policy to more closely match the capabilities of the
         device.  The PRC Support Table instances are specific to the
         particular Subject Category (Client-Type).  That is, the PRC
         Support Table for Subject Category 'A' will not include
         instances for classes supported by the Subject Category 'B'.
         Note that the COPS client-type [COPS] used for Framework PIB
         PRIs sent/received over COPS-PR MUST be the unique SUBJECT-
         CATEGORY number assigned for the area of policy being managed
         (e.g., QoS, Security etc). The PEP MUST ignore the attributes
         that it reports as not Supported in the decision from the PDP.
         The PEP SHOULD not send duplicate PRC support instances in a
         COPS Request and the PDP MUST ignore duplicate instances and
         MUST use the first instance received for a supported PRC in a
         COPS Request.

      PIB Incarnation Table

         This PRC contains exactly one row (corresponding to one PRI)
         per context.  It identifies the PDP that was the last to
         download policy into the device and also contains an identifier
         to identify the version of the policy currently downloaded.
         This identifier, both its syntax and value, is meaningful only
         to the PDPs.  It is intended to be a mechanism whereby a PDP,
         when accepting a connection from a PEP, can easily identify a
         known incarnation of policy.  This PRC defines a flag via which
         the installed contexts are divided into a set of contexts
         ('configuration contexts') out of which only one context is
         active and a the remaining contexts form a set of 'outsourcing
         contexts' which are all active.  The incarnation PRC also
         defines an attribute to indicate which configuration context is



Sahita, et. al.              Informational                     [Page 18]

RFC 3318           Framework Policy Information Base          March 2003


         the active one at the present time in the 'configuration
         contexts' set.  The incarnation instance is specific to the
         particular Subject Category (Client-Type).

      Component Limitations Table

         Some devices may not be able to implement the full range of
         values for all attributes.  In principle, each PRC supports a
         set of errors that the PEP can report to the PDP in the event
         that the specified policy is not implementable.  It may be
         preferable for the PDP to be informed of the device limitations
         before actually attempting to install policy, and while the
         error can indicate that a particular attribute value is
         unacceptable to the PEP, this does not help the PDP ascertain
         which values would be acceptable.  To alleviate these
         limitations, the PEP can report some limitations of attribute
         values and/or classes and possibly guidance values for the
         attribute in the Component Limitations Table

      Device Identification Table

         This PRC contains a single PRI that contains device-specific
         information that is used to facilitate efficient policy
         installation by a PDP.  The instance of this PRC is reported to
         the PDP in a COPS request message so that the PDP can take into
         account certain device characteristics during policy
         installation.

4.2. Device Capabilities group

   This group contains the PRCs that describe the characteristics of
   interfaces of the device and the Role Combinations assigned to them.

      Capabilities Set Table

         The capabilities the PEP supports are described by rows in this
         PRC (frwkCapabilitySetTable).  Each row, or instance of this
         class, associates a unique capability name with a set of
         capabilities that an entity on the PEP may support.  The unique
         name is used to form a set of capabilities that the name
         represents.  The capability references can specify instances in
         relevant capability tables in any PIB.  The PEP notifies the
         PDP of these capability sets and then the PDP configures the
         interfaces, per role combination.  The unique name
         (frwkCapabilitySetName) is not to be confused with the IfType
         object in the Interfaces Group MIB [RFC2863].





Sahita, et. al.              Informational                     [Page 19]

RFC 3318           Framework Policy Information Base          March 2003


      Interface and Role Combination Table

         The Capabilities Set Table (explained above) describes the
         entities on the PEP (for example, interfaces) by their
         capabilities, by assigning the capability sets a unique name
         (frwkCapabilitySetName).  It is possible to tailor the behavior
         of interfaces by assigning specific role-combinations to the
         capability sets.  This allows interfaces with the same
         capability sets to be assigned different policies, based on the
         current roles assigned to them.  At the PDP, configuration is
         done in terms of these interface capability set names and the
         role-combinations assigned to them.  Thus, each row of this
         class is a <Interface Index, interface capability set name,
         Role Combo> tuple, that indicates the roles that have been
         assigned to a particular capability set (as identified by
         frwkRoleComboCapSetName) and to a particular interface.  Note
         that the uniqueness criteria for this PRC has all the
         attributes, thus a frwkRoleComboCapSetName may have multiple
         role-combinations that it is associated with.  Via the IfIndex,
         this PRC answers the questions of 'which interfaces have a
         specific role combination?' and 'what role combination a
         specific interface is a part of?'.

4.3. Classifier group

   This group contains the IP, IEEE 802 and Internal Label Classifier
   elements.  The set of tables consist of a Base Filter table that
   contains the Index InstanceId and the Negation flag for the filter.
   This frwkBaseFilterTable is extended to form the IP Filter table, the
   802 Filter table [802] and the Internal Label table.  Filters may
   also be defined outside this document and used to extend the Base
   Filter table.

   The Extended classes do not have a separate Index value. Instances of
   the extended classes have the same indices as their base class
   instance.  Inheritance is achieved using the EXTENDS keyword as
   defined in [SPPI].

4.4. Marker group

   This group contains the 802 marker and internal label marker PRCs.
   The 802 marker may be applied to mark 802 packets with the required
   VLAN Id and/or priority value.  The Internal Label marker is applied
   to traffic in order to label it with a network device specific label.
   Such a label is used to assist the differentiation of an input flow
   after it has been aggregated with other flows.  The label is





Sahita, et. al.              Informational                     [Page 20]

RFC 3318           Framework Policy Information Base          March 2003


   implementation specific and may be used for other policy related
   functions like flow accounting purposes and/or other data path
   treatments.

5. The Framework PIB Module

  FRAMEWORK-PIB PIB-DEFINITIONS ::= BEGIN

  IMPORTS
      Unsigned32, Integer32, MODULE-IDENTITY,
      MODULE-COMPLIANCE, OBJECT-TYPE, OBJECT-GROUP, pib
              FROM COPS-PR-SPPI
      InstanceId, Prid
              FROM COPS-PR-SPPI-TC
      RoleCombination, PrcIdentifierOid, AttrIdentifierOrZero,
      ClientType, ClientHandle
              FROM FRAMEWORK-TC-PIB
      InetAddress, InetAddressType,
      InetAddressPrefixLength, InetPortNumber
              FROM INET-ADDRESS-MIB
      InterfaceIndex
              FROM IF-MIB
      DscpOrAny
              FROM DIFFSERV-DSCP-TC
      TruthValue, PhysAddress
              FROM SNMPv2-TC
      SnmpAdminString
              FROM SNMP-FRAMEWORK-MIB;

  frameworkPib  MODULE-IDENTITY
      SUBJECT-CATEGORIES { all }
      LAST-UPDATED "200302130000Z"  -- 13 Feb 2003
      ORGANIZATION "IETF RAP WG"
      CONTACT-INFO "
                    Keith McCloghrie
                    Cisco Systems, Inc.
                    170 West Tasman Drive,
                    San Jose, CA 95134-1706 USA
                    Phone: +1 408 526 5260
                    Email: kzm@cisco.com

                    John Seligson
                    Nortel Networks, Inc.
                    4401 Great America Parkway
                    Santa Clara, CA 95054 USA
                    Phone: +1 408 495 2992
                    Email: jseligso@nortelnetworks.com




Sahita, et. al.              Informational                     [Page 21]

RFC 3318           Framework Policy Information Base          March 2003


                    Ravi Sahita
                    Intel Labs.
                    2111 NE 25th Ave.

                    Hillsboro, OR 97124 USA
                    Phone: +1 503 712 1554
                    Email: ravi.sahita@intel.com

                    RAP WG Mailing list: rap@ops.ietf.org"

      DESCRIPTION
           "A PIB module containing the base set of PRCs that
           provide support for management of multiple PIB contexts,
           association of roles to device capabilities and other
           reusable PRCs. PEPs are required for to implement this
           PIB if the above features are desired. This PIB defines
           PRCs applicable to 'all' subject-categories.

           Copyright (C) The Internet Society (2003). This version
           of this PIB module is part of RFC 3318; see the RFC
           itself for full legal notices."
      REVISION     "200302130000Z"  -- 13 Feb 2003
      DESCRIPTION
           "Initial version, published in RFC 3318."

      ::= { pib 2 }

  --
  -- The root OID for PRCs in the Framework PIB
  --

  frwkBasePibClasses
               OBJECT IDENTIFIER ::= { frameworkPib 1 }

  --
  -- PRC Support Table
  --














Sahita, et. al.              Informational                     [Page 22]

RFC 3318           Framework Policy Information Base          March 2003


  frwkPrcSupportTable OBJECT-TYPE
      SYNTAX         SEQUENCE OF FrwkPrcSupportEntry
      PIB-ACCESS     notify
      STATUS         current
      DESCRIPTION
          "Each instance of this PRC specifies a PRC that the device
          supports and a bit string to indicate the attributes of the
          class that are supported.  These PRIs are sent to the PDP to
          indicate to the PDP which PRCs, and which attributes of
          these PRCs, the device supports.

          All install and install-notify PRCs supported by the device
          must be represented in this PRC. Notify PRCs may be
          represented for informational purposes."

      ::= { frwkBasePibClasses 1 }

  frwkPrcSupportEntry OBJECT-TYPE
      SYNTAX         FrwkPrcSupportEntry
      STATUS         current
      DESCRIPTION
          "An instance of the frwkPrcSupport class that identifies a
          specific PRC and associated attributes as supported
          by the device."

      PIB-INDEX { frwkPrcSupportPrid }
      UNIQUENESS { frwkPrcSupportSupportedPrc }

      ::= { frwkPrcSupportTable 1 }

  FrwkPrcSupportEntry ::= SEQUENCE {
          frwkPrcSupportPrid           InstanceId,
          frwkPrcSupportSupportedPrc   PrcIdentifierOid,
          frwkPrcSupportSupportedAttrs OCTET STRING
  }

  frwkPrcSupportPrid OBJECT-TYPE
      SYNTAX         InstanceId
      STATUS         current
      DESCRIPTION
          "An arbitrary integer index that uniquely identifies an
          instance of the frwkPrcSupport class."

      ::= { frwkPrcSupportEntry 1 }







Sahita, et. al.              Informational                     [Page 23]

RFC 3318           Framework Policy Information Base          March 2003


  frwkPrcSupportSupportedPrc OBJECT-TYPE
      SYNTAX         PrcIdentifierOid
      STATUS         current
      DESCRIPTION
          "The object identifier of a supported PRC. The value is the
           OID of the Entry object of the PRC definition. The Entry
           Object definition of a PRC has an OID with value XxxTable.1
           Where, XxxTable is the OID assigned to the PRC Table
           Object definition. There may not be more than one instance
           of the frwkPrcSupport class with the same value of
           frwkPrcSupportSupportedPrc."

      ::= { frwkPrcSupportEntry 2 }

  frwkPrcSupportSupportedAttrs OBJECT-TYPE
      SYNTAX         OCTET STRING
      STATUS         current
      DESCRIPTION
          "A bit string representing the supported attributes of the
          class that is identified by the frwkPrcSupportSupportedPrc
          object.

          Each bit of this bit string corresponds to a class
          attribute, with the most significant bit of the i-th octet
          of this octet string corresponding to the (8*i - 7)-th
          attribute, and the least significant bit of the i-th octet
          corresponding to the (8*i)-th class attribute. Each bit
          specifies whether or not the corresponding class attribute
          is currently supported, with a '1' indicating support and a
          '0' indicating no support.

          If the value of this bit string is N bits long and there are
          more than N class attributes then the bit string is
          logically extended with 0's to the required length.
          On the other hand, If the PDP receives a bit string of
          length N and there are less that N class attributes then the
          PDP should ignore the extra bits in the bit string, i.e.,
          assume those attributes are unsupported."
        REFERENCE
          "COPS Usage for Policy Provisioning.  RFC 3084, section
          2.2.1."

      ::= { frwkPrcSupportEntry 3 }

  --
  -- PIB Incarnation Table
  --




Sahita, et. al.              Informational                     [Page 24]

RFC 3318           Framework Policy Information Base          March 2003


  frwkPibIncarnationTable OBJECT-TYPE
      SYNTAX         SEQUENCE OF FrwkPibIncarnationEntry
      PIB-ACCESS     install-notify
      STATUS         current
      DESCRIPTION
          "This PRC contains a single PRovisioning Instance per
          installed context that identifies the current incarnation
          of the PIB and the PDP or network manager that installed
          this incarnation.  The instance of this PRC is reported to
          the PDP in the REQ message so that the PDP can (attempt to)
          ascertain the current state of the PIB. A network manager
          may use the instance to determine the state of the device."

      ::= { frwkBasePibClasses 2 }

  frwkPibIncarnationEntry OBJECT-TYPE
      SYNTAX         FrwkPibIncarnationEntry
      STATUS         current
      DESCRIPTION
          "An instance of the frwkPibIncarnation class. Only
          one instance of this PRC is ever instantiated per context"

      PIB-INDEX { frwkPibIncarnationPrid }

      ::= { frwkPibIncarnationTable 1 }

  FrwkPibIncarnationEntry ::= SEQUENCE {
          frwkPibIncarnationPrid                InstanceId,
          frwkPibIncarnationName                SnmpAdminString,
          frwkPibIncarnationId                  OCTET STRING,
          frwkPibIncarnationLongevity           INTEGER,
          frwkPibIncarnationTtl                 Unsigned32,
          frwkPibIncarnationInCtxtSet           TruthValue,
          frwkPibIncarnationActive              TruthValue,
          frwkPibIncarnationFullState           TruthValue
  }

  frwkPibIncarnationPrid OBJECT-TYPE
      SYNTAX         InstanceId
      STATUS         current
      DESCRIPTION
          "An index to uniquely identify an instance of this PRC."

      ::= { frwkPibIncarnationEntry 1 }







Sahita, et. al.              Informational                     [Page 25]

RFC 3318           Framework Policy Information Base          March 2003


  frwkPibIncarnationName OBJECT-TYPE
      SYNTAX         SnmpAdminString (SIZE (0..255))
      STATUS         current
      DESCRIPTION
          "The name of the PDP that installed the current incarnation
          of the PIB into the device.  A zero-length string value for
          this type implies the PDP has not assigned this type any
          value. By default, it is the zero length string."

      ::= { frwkPibIncarnationEntry 2 }

  frwkPibIncarnationId OBJECT-TYPE
      SYNTAX         OCTET STRING (SIZE (0..255))
      STATUS         current
      DESCRIPTION
          "An ID to identify the current incarnation.  It has meaning
          to the PDP/manager that installed the PIB and perhaps its
          standby PDPs/managers. A zero-length string value for
          this type implies the PDP has not assigned this type any
          value. By default, it is the zero-length string."

      ::= { frwkPibIncarnationEntry 3 }

  frwkPibIncarnationLongevity OBJECT-TYPE
      SYNTAX         INTEGER {
                          expireNever(1),
                          expireImmediate(2),
                          expireOnTimeout(3)
                     }
      STATUS         current
      DESCRIPTION
          "This attribute controls what the PEP does with the
          downloaded policy on a Client Close message or a loss of
          connection to the PDP.

          If set to expireNever, the PEP continues to operate with the
          installed policy indefinitely.  If set to expireImmediate,
          the PEP immediately expires the policy obtained from the PDP
          and installs policy from local configuration.  If set to
          expireOnTimeout, the PEP continues to operate with the
          policy installed by the PDP for a period of time specified
          by frwkPibIncarnationTtl.  After this time (and it has not
          reconnected to the original or new PDP) the PEP expires this
          policy and reverts to local configuration.

          For all cases, it is the responsibility of the PDP to check
          the incarnation and download new policy, if necessary, on a
          reconnect. On receiving a Remove-State for the active



Sahita, et. al.              Informational                     [Page 26]

RFC 3318           Framework Policy Information Base          March 2003


          context, this attribute value MUST be ignored and the PEP
          should expire the policy in that active context immediately.
          Policy enforcement timing only applies to policies that have
          been installed dynamically (e.g., by a PDP via COPS)."
      REFERENCE
          "COPS Usage for Policy Provisioning. RFC 3084."

      ::= { frwkPibIncarnationEntry 4 }

  frwkPibIncarnationTtl OBJECT-TYPE
      SYNTAX         Unsigned32
      UNITS          "seconds"
      STATUS         current
      DESCRIPTION
          "The number of seconds after a Client Close or TCP timeout
          for which the PEP continues to enforce the policy in the
          PIB. After this interval, the PIB is considered expired and
          the device no longer enforces the policy installed in the
          PIB.

          This attribute is only meaningful if
          frwkPibIncarnationLongevity is set to expireOnTimeout."

      ::= { frwkPibIncarnationEntry 5 }

  frwkPibIncarnationInCtxtSet OBJECT-TYPE
      SYNTAX        TruthValue
      STATUS         current
      DESCRIPTION
          "When the PDP installs a PRI with this flag set to 'true' it
          implies this context belongs to the set of contexts out of
          which at the most one context can be active at a given time.
          If this attribute is set to 'false' this context is one of
          the outsourcing (simultaneous active) contexts on the PEP.

          This attribute is 'true' for all contexts belong to the set
          of configuration contexts. Within the configuration context
          set, one context can be active identified by the
          frwkPibIncarnationActive attribute."
      REFERENCE
          "TruthValue Textual Convention, defined in RFC 2579."
      ::= { frwkPibIncarnationEntry 6 }









Sahita, et. al.              Informational                     [Page 27]

RFC 3318           Framework Policy Information Base          March 2003


  frwkPibIncarnationActive OBJECT-TYPE
      SYNTAX         TruthValue
      STATUS         current
      DESCRIPTION
          "When the PDP installs a PRI on the PEP with this attribute
          set to 'true' and if this context belongs to the
          'configuration contexts' set, i.e., the
          frwkPibIncarnationInCtxtSet is set to 'true', then the PIB
          instance to which this PRI belongs must become the active
          PIB instance. In this case, the previous active instance
          from this set MUST become inactive and the
          frwkPibIncarnationActive attribute in that PIB instance MUST
          be set to 'false'.

          When the PDP installs an attribute frwkPibIncarnationActive
          on the PEP  that is 'true' in one PIB instance and if the
          context belongs to the 'configuration contexts' set, the PEP
          must ensure, re-setting the attribute if necessary, that the
          frwkPibIncarnationActive attribute is  'false' in all other
          contexts which belong to the 'configuration contexts' set."

      ::= { frwkPibIncarnationEntry 7 }

  frwkPibIncarnationFullState OBJECT-TYPE
      SYNTAX         TruthValue
      STATUS         current
      DESCRIPTION
          "This attribute is interpreted only when sent in a COPS
          request message from the PEP to the PDP. It does not have
          any meaning when sent from the PDP to the PEP.

          If this attribute is set to 'true' by the PEP, then the
          request that the PEP sends to the PDP must be interpreted as
          the complete configuration request for the PEP. The PDP must
          in this case refresh the request information for the
          handle that the request containing this PRI was received on.
          If this attribute is set to 'false', then the
             request PRIs sent in the request must be interpreted as
          updates to the previous request PRIs sent using that handle.
          See section 3.3 for details on updating request state
          information."
      REFERENCE
          "RFC 3318 Section 2.3"

      ::= { frwkPibIncarnationEntry 8 }

  --
  -- Device Identification Table



Sahita, et. al.              Informational                     [Page 28]

RFC 3318           Framework Policy Information Base          March 2003


  --

  frwkDeviceIdTable OBJECT-TYPE

      SYNTAX         SEQUENCE OF FrwkDeviceIdEntry
      PIB-ACCESS     notify
      STATUS         current
      DESCRIPTION
          "This PRC contains a single PRovisioning Instance that
          contains general purpose device-specific information that is
          used to facilitate efficient policy communication by a PDP.
          The  instance of this PRC is reported to the PDP in a COPS
          request message so that the PDP can take into account
          certain device characteristics during policy installation."

      ::= { frwkBasePibClasses 3 }

  frwkDeviceIdEntry OBJECT-TYPE
      SYNTAX         FrwkDeviceIdEntry
      STATUS         current
      DESCRIPTION
          "An instance of the frwkDeviceId class. Only one instance of
          this PRC is ever instantiated."

      PIB-INDEX { frwkDeviceIdPrid }

      ::= { frwkDeviceIdTable 1 }

  FrwkDeviceIdEntry ::= SEQUENCE {
          frwkDeviceIdPrid        InstanceId,
          frwkDeviceIdDescr       SnmpAdminString,
          frwkDeviceIdMaxMsg      Unsigned32,
          frwkDeviceIdMaxContexts Unsigned32
  }

  frwkDeviceIdPrid OBJECT-TYPE
      SYNTAX         InstanceId
      STATUS         current
      DESCRIPTION
          "An index to uniquely identify an instance of this PRC."

      ::= { frwkDeviceIdEntry 1 }









Sahita, et. al.              Informational                     [Page 29]

RFC 3318           Framework Policy Information Base          March 2003


  frwkDeviceIdDescr OBJECT-TYPE
      SYNTAX         SnmpAdminString (SIZE (1..255))
      STATUS         current
      DESCRIPTION
          "A textual description of the PEP. This value should include
          the name and version identification of the PEP's hardware
          and software."

      ::= { frwkDeviceIdEntry 2 }

  frwkDeviceIdMaxMsg OBJECT-TYPE
      SYNTAX         Unsigned32 (64..4294967295)
      UNITS          "octets"
      STATUS         current
      DESCRIPTION
          "The maximum COPS-PR message size, in octets, that the
          device is capable of processing. Received messages with a
          size in excess of this value must cause the PEP to return an
          error to the PDP containing the global error code
          'maxMsgSizeExceeded'. This is an additional error-avoidance
          mechanism to allow the administrator to know the maximum
          message size supported so that they have the ability to
          control the message size of messages sent to the device.
          This attribute must have a non-zero value. The device should
          send the MAX value for Unsigned32 for this attribute if it
          not defined."
      DEFVAL { 4294967295 }

      ::= { frwkDeviceIdEntry 3 }

  frwkDeviceIdMaxContexts OBJECT-TYPE
     SYNTAX         Unsigned32 (1..4294967295)
     UNITS          "contexts"
     STATUS         current
     DESCRIPTION
         "The maximum number of unique contexts supported by
          the device. This is an additional error-avoidance mechanism
          to allow the administrators to have the ability to know the
          maximum number of contexts supported so that they can
          control the number of configuration contexts they install on
          the device. This attribute must have a non-zero value. The
          device should send the MAX value for Unsigned32 for this
          attribute if it not defined."
      DEFVAL { 4294967295 }

     ::= { frwkDeviceIdEntry 4 }

  --



Sahita, et. al.              Informational                     [Page 30]

RFC 3318           Framework Policy Information Base          March 2003


  -- Component Limitations Table
  --

  frwkCompLimitsTable OBJECT-TYPE
      SYNTAX         SEQUENCE OF FrwkCompLimitsEntry
      PIB-ACCESS     notify
      STATUS         current
      DESCRIPTION
          "This PRC supports the ability to export information
          detailing PRC/attribute implementation limitations to the
          policy management system. Instances of this PRC apply only
          for PRCs with access type 'install' or 'install-notify'.

          Each instance of this PRC identifies a PRovisioning Class
          or attribute and a limitation related to the implementation
          of the class/attribute in the device. Additional information
          providing guidance related to the limitation may also be
          present. These PRIs are sent to the PDP to indicate which
          PRCs or PRC attributes the device supports in a restricted
          manner."

      ::= { frwkBasePibClasses 4 }

  frwkCompLimitsEntry OBJECT-TYPE
      SYNTAX         FrwkCompLimitsEntry
      STATUS         current
      DESCRIPTION
          "An instance of the frwkCompLimits class that identifies
          a PRC or PRC attribute and a limitation related to the PRC
          or PRC attribute implementation supported by the device.
          COPS-PR lists the error codes that MUST be returned (if
          applicable)for policy installation that don't abide by the
          restrictions indicated by the limitations exported. [SPPI]
          defines an INSTALL-ERRORS clause that allows PIB designers
          to define PRC specific error codes that can be returned for
          policy installation. This allows efficient debugging of PIB
          implementations."
      REFERENCE
          "COPS Usage for Policy Provisioning. RFC 3084."

      PIB-INDEX { frwkCompLimitsPrid }
      UNIQUENESS { frwkCompLimitsComponent,
                   frwkCompLimitsAttrPos,
                   frwkCompLimitsNegation,
                   frwkCompLimitsType,
                   frwkCompLimitsSubType,
                   frwkCompLimitsGuidance }




Sahita, et. al.              Informational                     [Page 31]

RFC 3318           Framework Policy Information Base          March 2003


      ::= { frwkCompLimitsTable 1 }

  FrwkCompLimitsEntry ::= SEQUENCE {
          frwkCompLimitsPrid           InstanceId,
          frwkCompLimitsComponent      PrcIdentifierOid,
          frwkCompLimitsAttrPos        AttrIdentifierOrZero,
          frwkCompLimitsNegation       TruthValue,
          frwkCompLimitsType           INTEGER,
          frwkCompLimitsSubType        INTEGER,
          frwkCompLimitsGuidance       OCTET STRING
  }

  frwkCompLimitsPrid OBJECT-TYPE
      SYNTAX         InstanceId
      STATUS         current
      DESCRIPTION
          "An arbitrary integer index that uniquely identifies an
          instance of the frwkCompLimits class."

      ::= { frwkCompLimitsEntry 1 }

  frwkCompLimitsComponent OBJECT-TYPE
      SYNTAX         PrcIdentifierOid
      STATUS         current
      DESCRIPTION
          "The value is the OID of a PRC (the table entry) which is
          supported in some limited fashion or contains an attribute
          that is supported in some limited fashion with regard to
          it's definition in the associated PIB module. The same OID
          may appear in the table several times, once for each
          implementation limitation acknowledged by the device."

      ::= { frwkCompLimitsEntry 2 }

  frwkCompLimitsAttrPos OBJECT-TYPE
      SYNTAX         AttrIdentifierOrZero
      STATUS         current
      DESCRIPTION
          "The relative position of the attribute within the PRC
          specified by the frwkCompLimitsComponent. A value of 1 would
          represent the first columnar object in the PRC and a value
          of N would represent the Nth columnar object in the PRC. A
          value of zero (0) indicates that the limit applies to the
          PRC itself and not to a specific attribute."

      ::= { frwkCompLimitsEntry 3 }





Sahita, et. al.              Informational                     [Page 32]

RFC 3318           Framework Policy Information Base          March 2003


  frwkCompLimitsNegation OBJECT-TYPE
      SYNTAX        TruthValue
      STATUS        current
      DESCRIPTION
           "A boolean value ,if 'true', negates the component limit
           exported."

      ::= { frwkCompLimitsEntry 4 }

  frwkCompLimitsType OBJECT-TYPE
      SYNTAX    INTEGER {
                           priSpaceLimited(1),
                           attrValueSupLimited(2),
                           attrEnumSupLimited(3),
                           attrLengthLimited(4),
                           prcLimitedNotify(5)
                        }
      STATUS   current
      DESCRIPTION
          "A value describing an implementation limitation for the
          device related to the PRC or PRC attribute identified by
          the frwkCompLimitsComponent and the frwkCompLimitsAttrPos
          attributes.

          Values for this object are one of the following:

          priSpaceLimited(1) - No more instances than that specified
          by the guidance value may be installed in the given class.
          The component identified MUST be a valid PRC. The SubType
          used MUST be valueOnly(9).

          attrValueSupLimited(2) - Limited values are acceptable for
          the identified component. The component identified MUST be a
          valid PRC attribute. The guidance OCTET STRING will be
          decoded according to the attribute type.

          attrEnumSupLimited(3) - Limited enumeration values are legal
          for the identified component. The attribute identified MUST
          be a valid enum type.

          attrLengthLimited(4) - The length of the specified
          value for the identified component is limited. The component
          identified MUST be a valid PRC attribute of base-type OCTET
          STRING.

          prcLimitedNotify (5) - The component is currently limited
          for use by request or report messages prohibiting decision
          installation. The component identified must be a valid PRC."



Sahita, et. al.              Informational                     [Page 33]

RFC 3318           Framework Policy Information Base          March 2003


      ::= { frwkCompLimitsEntry 5 }

     frwkCompLimitsSubType OBJECT-TYPE
      SYNTAX         INTEGER {
                                  none(1),
                                  lengthMin(2),
                                  lengthMax(3),
                                  rangeMin(4),
                                  rangeMax(5),
                                  enumMin(6),
                                  enumMax(7),
                                  enumOnly(8),
                                  valueOnly(9),
                                  bitMask(10)
                              }
      STATUS         current
      DESCRIPTION
          "This object indicates the type of guidance related
          to the noted limitation (as indicated by the
          frwkCompLimitsType attribute) that is provided
          in the frwkCompLimitsGuidance attribute.

          A value of 'none(1)' means that no additional
          guidance is provided for the noted limitation type.

          A value of 'lengthMin(2)' means that the guidance
          attribute provides data related to the minimum
          acceptable length for the value of the identified
          component. A corresponding class instance
          specifying the 'lengthMax(3)' value is required
          in conjunction with this sub-type.

          A value of 'lengthMax(3)' means that the guidance
          attribute provides data related to the maximum
          acceptable length for the value of the identified
          component. A corresponding class instance
          specifying the 'lengthMin(2)' value is required
          in conjunction with this sub-type.

          A value of 'rangeMin(4)' means that the guidance
          attribute provides data related to the lower bound
          of the range for the value of the identified
          component. A corresponding class instance
          specifying the 'rangeMax(5)' value is required
          in conjunction with this sub-type.

          A value of 'rangeMax(5)' means that the guidance
          attribute provides data related to the upper bound



Sahita, et. al.              Informational                     [Page 34]

RFC 3318           Framework Policy Information Base          March 2003


          of the range for the value of the identified
          component. A corresponding class instance
          specifying the 'rangeMin(4)' value is required
          in conjunction with this sub-type.

          A value of 'enumMin(6)' means that the guidance
          attribute provides data related to the lowest
          enumeration acceptable for the value of the
          identified component. A corresponding
          class instance specifying the 'enumMax(7)'
          value is required in conjunction with this sub-type.

          A value of 'enumMax(7)' means that the guidance
          attribute provides data related to the largest
          enumeration acceptable for the value of the
          identified component. A corresponding
          class instance specifying the 'enumMin(6)'
          value is required in conjunction with this sub-type.

          A value of 'enumOnly(8)' means that the guidance
          attribute provides data related to a single
          enumeration acceptable for the value of the
          identified component.

          A value of 'valueOnly(9)' means that the guidance
          attribute provides data related to a single
          value that is acceptable for the identified
          component.

          A value of 'bitMask(10)' means that the guidance
          attribute is a bit mask such that all the combinations of
          bits set in the bitmask are acceptable values for the
          identified component which should be an attribute of type

          'BITS'.

          For example, an implementation of the frwkIpFilter class may
          be limited in several ways, such as address mask, protocol
          and Layer 4 port options. These limitations could be
          exported using this PRC with the following instances:

          Component        Type                 Sub-Type   Guidance
          ------------------------------------------------------------
          DstPrefixLength  attrValueSupLimited  valueOnly   24
          SrcPrefixLength  attrValueSupLimited  valueOnly   24
          Protocol         attrValueSupLimited  rangeMin    10
          Protocol         attrValueSupLimited  rangeMax    20




Sahita, et. al.              Informational                     [Page 35]

RFC 3318           Framework Policy Information Base          March 2003


          The above entries describe a number of limitations that
          may be in effect for the frwkIpFilter class on a given
          device. The limitations include restrictions on acceptable
          values for certain attributes.

          Also, an implementation of a PRC may be limited in the ways
          it can be accessed. For instance, for a fictitious PRC
          dscpMapEntry, which has a PIB-ACCESS of 'install-notify':

          Component    Type              SubType  Guidance
          ------------------------------------------------------------
          dscpMapEntry prcLimitedNotify  none     zero-length string."

         ::= { frwkCompLimitsEntry 6 }

   frwkCompLimitsGuidance OBJECT-TYPE
         SYNTAX         OCTET STRING
         STATUS         current
         DESCRIPTION
             "A value used to convey additional information related
             to the implementation limitation. Note that a guidance
             value will not necessarily be provided for all exported
             limitations. If a guidance value is not provided, the
             value must be a zero-length string.

             The format of the guidance value, if one is present as
             indicated by the frwkCompLimitsSubType attribute,
             is described by the following table. Note that the
             format of guidance value is dictated by the base-type of
             the component whose limitation is being exported,
             interpreted in the context of the frwkCompLimitsType and
             frwkCompLimitsSubType values. Any other restrictions
             (such as size/range/enumerated value) on the guidance
             value MUST be complied with according to the definition
             of the component for which guidance is being specified.

             Note that numbers are encoded in network byte order.

             Base Type                      Value
             ---------                      -----
             Unsigned32/Integer32/INTEGER   32-bit value.
             Unsigned64/Integer64        64-bit Value.
             OCTET STRING                octets of data.
             OID                         32-bit OID components.
             BITS                        Binary octets of length
                                         same as Component specified."

         ::= { frwkCompLimitsEntry 7 }



Sahita, et. al.              Informational                     [Page 36]

RFC 3318           Framework Policy Information Base          March 2003


  --
  -- Complete Reference specification table
  --

  frwkReferenceTable OBJECT-TYPE
      SYNTAX         SEQUENCE OF FrwkReferenceEntry
      PIB-ACCESS     install-notify
      STATUS         current
      DESCRIPTION
          "Each instance of this PRC specifies a reference to a PRI
          in a specific PIB context (handle) for a specific client-
          type. This table gives the PDP the ability to set up
          policies that span installed contexts and the PEP the
          ability to reference instances in another, perhaps
          configured context. The PEP must send a
          'attrReferenceUnknown' COPS-PR error to the PDP if it
          encounters an invalid reference. "
      REFERENCE
          "COPS Usage for Policy Provisioning. RFC 3084, error
          codes section 4.5."

      ::= { frwkBasePibClasses 5 }

  frwkReferenceEntry OBJECT-TYPE
      SYNTAX         FrwkReferenceEntry
      STATUS         current
      DESCRIPTION
          "Entry specification for the frwkReferenceTable."

      PIB-INDEX { frwkReferencePrid }
      UNIQUENESS { }

      ::= { frwkReferenceTable 1 }

  FrwkReferenceEntry ::= SEQUENCE {
          frwkReferencePrid           InstanceId,
          frwkReferenceClientType     ClientType,
          frwkReferenceClientHandle   ClientHandle,
          frwkReferenceInstance       Prid
  }

  frwkReferencePrid  OBJECT-TYPE
      SYNTAX         InstanceId
      STATUS         current
      DESCRIPTION
          "An arbitrary integer index that uniquely identifies an
          instance of the frwkReference class."




Sahita, et. al.              Informational                     [Page 37]

RFC 3318           Framework Policy Information Base          March 2003


      ::= { frwkReferenceEntry 1 }

  frwkReferenceClientType OBJECT-TYPE
      SYNTAX         ClientType
      STATUS         current
      DESCRIPTION
          "Is unused if set to zero else specifies a client-type for
           which the reference is to be interpreted. This non-zero
           client-type must be activated explicitly via a separate
           COPS client-open else this attribute is not valid."

      ::= { frwkReferenceEntry 2 }

  frwkReferenceClientHandle OBJECT-TYPE
      SYNTAX         ClientHandle
      STATUS         current
      DESCRIPTION
          "Must be set to specify a valid client-handle in the scope
          of the client-type specified."

      ::= { frwkReferenceEntry 3 }

  frwkReferenceInstance OBJECT-TYPE
      SYNTAX         Prid
      STATUS         current
      DESCRIPTION
          "References a PRI in the context identified by
           frwkReferenceClientHandle for client-type identified by
           frwkReferenceClientType."

      ::= { frwkReferenceEntry 4 }

  --
  -- Error specification table
  --

  frwkErrorTable OBJECT-TYPE
      SYNTAX         SEQUENCE OF FrwkErrorEntry
      PIB-ACCESS     install
      STATUS         current
      DESCRIPTION
          "Each instance of this PRC specifies a class specific
          error object. Instances of this PRC are transient, i.e.,
          instances received in a COPS decision message must not be
          maintained by the PEP in its copy of the PIB instances. This
          PRC allows a PDP to send error information to the PEP if the
          PDP cannot process updates to a Request successfully."




Sahita, et. al.              Informational                     [Page 38]

RFC 3318           Framework Policy Information Base          March 2003


      ::= { frwkBasePibClasses 6 }

  frwkErrorEntry OBJECT-TYPE
      SYNTAX         FrwkErrorEntry
      STATUS         current
      DESCRIPTION
          "Entry specification for the frwkErrorTable."

      PIB-INDEX { frwkErrorPrid }
      UNIQUENESS {
                   frwkErrorCode,
                   frwkErrorSubCode,
                   frwkErrorPrc,
                   frwkErrorInstance
                 }

      ::= { frwkErrorTable 1 }

  FrwkErrorEntry ::= SEQUENCE {
          frwkErrorPrid        InstanceId,
          frwkErrorCode        Unsigned32,
          frwkErrorSubCode     Unsigned32,
          frwkErrorPrc         PrcIdentifierOid,
          frwkErrorInstance    InstanceId
  }

  frwkErrorPrid  OBJECT-TYPE
      SYNTAX         InstanceId
      STATUS         current
      DESCRIPTION
          "An arbitrary integer index that uniquely identifies an
          instance of the frwkError class."

      ::= { frwkErrorEntry 1 }

  frwkErrorCode OBJECT-TYPE
      SYNTAX         Unsigned32 (0..65535)
      STATUS         current
      DESCRIPTION
          "Error code defined in COPS-PR CPERR object."
      REFERENCE
          "COPS Usage for Policy Provisioning. RFC 3084."

      ::= { frwkErrorEntry 2 }

  frwkErrorSubCode OBJECT-TYPE
      SYNTAX         Unsigned32 (0..65535)
      STATUS         current



Sahita, et. al.              Informational                     [Page 39]

RFC 3318           Framework Policy Information Base          March 2003


      DESCRIPTION
          "The class-specific error object is used to communicate
          errors relating to specific PRCs."

      ::= { frwkErrorEntry 3 }

  frwkErrorPrc OBJECT-TYPE
      SYNTAX         PrcIdentifierOid
      STATUS         current
      DESCRIPTION
          "The PRC due to which the error specified by codes
          (frwkErrorCode , frwkErrorSubCode) occurred."

      ::= { frwkErrorEntry 4 }

  frwkErrorInstance OBJECT-TYPE
      SYNTAX         InstanceId
      STATUS         current
      DESCRIPTION
          "The PRI of the identified PRC (frwkErrorPrc) due to which
          the error specified by codes (frwkErrorCode ,
          frwkErrorSubCode) occurred. Must be set to zero if unused."

      ::= { frwkErrorEntry 5 }

  --
  -- The device capabilities and role combo classes group
  --

  frwkDeviceCapClasses
              OBJECT IDENTIFIER ::= { frameworkPib 2 }
  --
  -- Capability Set Table
  --

  frwkCapabilitySetTable OBJECT-TYPE
      SYNTAX         SEQUENCE OF FrwkCapabilitySetEntry
      PIB-ACCESS     notify
      STATUS         current
      DESCRIPTION

          "This PRC describes the capability sets that exist on the
          interfaces on the device. The capability set is given a
          unique name that identifies a set. These capability set
          names are used by the PDP to determine policy information to
          be associated with interfaces that possess similar sets of
          capabilities."




Sahita, et. al.              Informational                     [Page 40]

RFC 3318           Framework Policy Information Base          March 2003


      ::= { frwkDeviceCapClasses 1 }

  frwkCapabilitySetEntry OBJECT-TYPE
      SYNTAX         FrwkCapabilitySetEntry
      STATUS         current
      DESCRIPTION
          "An instance of this PRC describes a particular set of
          capabilities and associates a unique name with the set."

      PIB-INDEX { frwkCapabilitySetPrid }
      UNIQUENESS { frwkCapabilitySetName,
                   frwkCapabilitySetCapability }

      ::= { frwkCapabilitySetTable 1 }

  FrwkCapabilitySetEntry ::= SEQUENCE {
          frwkCapabilitySetPrid           InstanceId,
          frwkCapabilitySetName           SnmpAdminString,
          frwkCapabilitySetCapability     Prid
  }

  frwkCapabilitySetPrid OBJECT-TYPE
      SYNTAX         InstanceId
      STATUS         current
      DESCRIPTION
          "An arbitrary integer index that uniquely identifies a
          instance of the class."

      ::= { frwkCapabilitySetEntry 1 }

  frwkCapabilitySetName OBJECT-TYPE
      SYNTAX         SnmpAdminString (SIZE (1..255))
      STATUS         current
      DESCRIPTION
          "The name for the capability set.  This name  is the unique
          identifier of a set of capabilities. This attribute must not
          be assigned a zero-length string."

      ::= { frwkCapabilitySetEntry 2 }

  frwkCapabilitySetCapability OBJECT-TYPE
      SYNTAX      Prid
      STATUS      current
      DESCRIPTION

          "The complete PRC OID and instance identifier specifying the
          capability PRC instance for the interface. This attribute
          references a specific instance of a capability table. The



Sahita, et. al.              Informational                     [Page 41]

RFC 3318           Framework Policy Information Base          March 2003


          capability table whose instance is referenced must be
          defined in the client type specific PIB that this PIB is
          used with. The referenced capability instance becomes a part
          of the set of capabilities associated with the specified
          frwkCapabilitySetName."

      ::= { frwkCapabilitySetEntry 3 }

  --
  -- Interface and Role Combination Tables
  --

  frwkRoleComboTable OBJECT-TYPE
      SYNTAX         SEQUENCE OF FrwkRoleComboEntry
      PIB-ACCESS     install-notify
      STATUS         current
      DESCRIPTION
          "This is an abstract PRC that may be extended or referenced
          to enumerate the role combinations, capability set names
          assigned to any interface on a PEP. The identification of
          the interface is to be defined by its extensions or
          referencing PRCs."

      ::= { frwkDeviceCapClasses 2 }

  frwkRoleComboEntry OBJECT-TYPE
      SYNTAX         FrwkRoleComboEntry
      STATUS         current
      DESCRIPTION
          "An instance of this PRC describes one association of an
          interface to a role-combination and capability set name .
          Note that an interface can have multiple associations. This
          constraint is controlled by the extending or referencing
          PRC's uniqueness clause."

      PIB-INDEX { frwkRoleComboPrid }
      UNIQUENESS { }

      ::= { frwkRoleComboTable 1 }

  FrwkRoleComboEntry ::= SEQUENCE {
          frwkRoleComboPrid         InstanceId,
          frwkRoleComboRoles        RoleCombination,
          frwkRoleComboCapSetName   SnmpAdminString
  }

  frwkRoleComboPrid OBJECT-TYPE
      SYNTAX         InstanceId



Sahita, et. al.              Informational                     [Page 42]

RFC 3318           Framework Policy Information Base          March 2003


      STATUS         current
      DESCRIPTION
          "An arbitrary integer index that uniquely identifies an
          instance of the class."

      ::= { frwkRoleComboEntry 1 }

  frwkRoleComboRoles OBJECT-TYPE
      SYNTAX         RoleCombination
      STATUS         current
      DESCRIPTION
          "The role combination assigned to a specific interface."

      ::= { frwkRoleComboEntry 2 }

  frwkRoleComboCapSetName OBJECT-TYPE
      SYNTAX         SnmpAdminString (SIZE (0..255))
      STATUS         current
      DESCRIPTION
          "The name of the capability set associated with
          the Role Combination specified in frwkRoleComboRoles. If
          this is a zero length string it implies the PEP is not
          exporting any capability set information for this
          RoleCombination. The PDP must then use the RoleCombinations
          provided as the only means of assigning policies
          If a non-zero length string is specified, the name must
          exist in frwkCapabilitySetTable."

      ::= { frwkRoleComboEntry 3 }

  --
  -- Interface, Role Combination association via IfIndex
  --

  frwkIfRoleComboTable OBJECT-TYPE
      SYNTAX         SEQUENCE OF FrwkIfRoleComboEntry
      PIB-ACCESS     install-notify
      STATUS         current
      DESCRIPTION
          "This PRC enumerates the interface to role combination and
          frwkRoleComboCapSetName mapping for all policy managed
          interfaces of a device. Policy for an interface depends not
          only on the capability set of an interface but also on its
          roles. This  table specifies all the <interface index,
          interface capability set name, role combination> tuples
          currently on the device"

      ::= { frwkDeviceCapClasses 3 }



Sahita, et. al.              Informational                     [Page 43]

RFC 3318           Framework Policy Information Base          March 2003


  frwkIfRoleComboEntry OBJECT-TYPE
      SYNTAX         FrwkIfRoleComboEntry
      STATUS         current
      DESCRIPTION
          "An instance of this PRC describes the association of
          a interface to an capability set name and a role
          combination.
          Note that a capability set name can have multiple role
          combinations assigned to it, but an IfIndex can have only
          one role combination associated."

      EXTENDS { frwkRoleComboEntry }
      UNIQUENESS { frwkIfRoleComboIfIndex,
                   frwkRoleComboCapSetName   }

      ::= { frwkIfRoleComboTable 1 }

  FrwkIfRoleComboEntry ::= SEQUENCE {
          frwkIfRoleComboIfIndex      InterfaceIndex
  }

  frwkIfRoleComboIfIndex OBJECT-TYPE
      SYNTAX         InterfaceIndex
      STATUS         current
      DESCRIPTION
          "The value of this attribute is the ifIndex which is
          associated with the specified RoleCombination and interface
          capability set name."

      ::= { frwkIfRoleComboEntry 1 }

  --
  -- The Classification classes group
  --

  frwkClassifierClasses
             OBJECT IDENTIFIER ::= { frameworkPib 3 }
  --
  -- The Base Filter Table
  --

  frwkBaseFilterTable OBJECT-TYPE
      SYNTAX         SEQUENCE OF FrwkBaseFilterEntry
      PIB-ACCESS     install
      STATUS         current






Sahita, et. al.              Informational                     [Page 44]

RFC 3318           Framework Policy Information Base          March 2003


      DESCRIPTION
          "The Base Filter class.  A packet has to match all
          fields in an Filter.  Wildcards may be specified for those
          fields that are not relevant."

      ::= { frwkClassifierClasses 1 }

  frwkBaseFilterEntry OBJECT-TYPE
      SYNTAX         FrwkBaseFilterEntry
      STATUS         current
      DESCRIPTION
          "An instance of the frwkBaseFilter class."

      PIB-INDEX { frwkBaseFilterPrid }

      ::= { frwkBaseFilterTable 1 }

  FrwkBaseFilterEntry ::= SEQUENCE {
          frwkBaseFilterPrid         InstanceId,
          frwkBaseFilterNegation     TruthValue
  }

  frwkBaseFilterPrid OBJECT-TYPE
      SYNTAX         InstanceId
      STATUS         current
      DESCRIPTION
          "An integer index to uniquely identify this Filter among all
          the Filters."

      ::= { frwkBaseFilterEntry 1 }

  frwkBaseFilterNegation OBJECT-TYPE
      SYNTAX         TruthValue
      STATUS         current
      DESCRIPTION
          "This attribute behaves like a logical NOT for the filter.
          If the packet matches this filter and the value of this
          attribute is 'true', the action associated with this filter
          is not applied to the packet.  If the value of this
          attribute is 'false', then the action is applied to the
          packet."

      ::= { frwkBaseFilterEntry 2 }

  --
  -- The IP Filter Table
  --




Sahita, et. al.              Informational                     [Page 45]

RFC 3318           Framework Policy Information Base          March 2003


  frwkIpFilterTable OBJECT-TYPE
      SYNTAX         SEQUENCE OF FrwkIpFilterEntry
      PIB-ACCESS     install
      STATUS         current
      DESCRIPTION
          "Filter definitions.  A packet has to match all fields in a
          filter.  Wildcards may be specified for those fields that
          are not relevant."

      INSTALL-ERRORS {
          invalidDstL4PortData(1),
          invalidSrcL4PortData(2)
          }
      ::= { frwkClassifierClasses 2 }

  frwkIpFilterEntry OBJECT-TYPE
      SYNTAX         FrwkIpFilterEntry
      STATUS         current
      DESCRIPTION
          "An instance of the frwkIpFilter class."

      EXTENDS { frwkBaseFilterEntry }
      UNIQUENESS { frwkBaseFilterNegation,
                   frwkIpFilterAddrType,
                   frwkIpFilterDstAddr,
                   frwkIpFilterDstPrefixLength,
                   frwkIpFilterSrcAddr,
                   frwkIpFilterSrcPrefixLength,
                   frwkIpFilterDscp,
                   frwkIpFilterFlowId,
                   frwkIpFilterProtocol,
                   frwkIpFilterDstL4PortMin,
                   frwkIpFilterDstL4PortMax,
                   frwkIpFilterSrcL4PortMin,
                   frwkIpFilterSrcL4PortMax }

      ::= { frwkIpFilterTable 1 }

  FrwkIpFilterEntry ::= SEQUENCE {
          frwkIpFilterAddrType         InetAddressType,
          frwkIpFilterDstAddr          InetAddress,
          frwkIpFilterDstPrefixLength  InetAddressPrefixLength,
          frwkIpFilterSrcAddr          InetAddress,
          frwkIpFilterSrcPrefixLength  InetAddressPrefixLength,
          frwkIpFilterDscp             DscpOrAny,
          frwkIpFilterFlowId           Integer32,
          frwkIpFilterProtocol         Unsigned32,
          frwkIpFilterDstL4PortMin     InetPortNumber,



Sahita, et. al.              Informational                     [Page 46]

RFC 3318           Framework Policy Information Base          March 2003


          frwkIpFilterDstL4PortMax     InetPortNumber,
          frwkIpFilterSrcL4PortMin     InetPortNumber,
          frwkIpFilterSrcL4PortMax     InetPortNumber
  }

  frwkIpFilterAddrType OBJECT-TYPE

      SYNTAX         InetAddressType
      STATUS         current
      DESCRIPTION
          "The address type enumeration value to specify the type of
          the packet's IP address.

          While other types of addresses are defined in the
          InetAddressType textual convention, an IP filter can only
          use IPv4 and IPv6 addresses directly to classify traffic.
          All other InetAddressTypes require mapping to the
          corresponding Ipv4 or IPv6 address before being used to
          classify traffic. Therefore, this object as such is not
          limited to IPv4 and IPv6 addresses, i.e., it can be assigned
          any of the valid values defined in the InetAddressType TC,
          but the mapping of the address values to IPv4 or IPv6
          addresses for the address attributes (frwkIpFilterDstAddr
          and frwkIpFilterSrcAddr) must be done by the PEP. For
          example when dns (16) is used, the PEP must resolve
          the address to IPv4 or IPv6 at install time."
      REFERENCE
          "Textual Conventions for Internet Network Addresses.
          RFC 3291."

      ::= { frwkIpFilterEntry 1 }

  frwkIpFilterDstAddr OBJECT-TYPE

      SYNTAX         InetAddress
      STATUS         current
      DESCRIPTION
          "The IP address to match against the packet's
           destination IP address. If the address type is 'ipv4',
           'ipv6', 'ipv4z' or 'ipv6z' then, the attribute
           frwkIpFilterDstPrefixLength indicates the number of bits
           that are relevant. "
      REFERENCE
          "Textual Conventions for Internet Network Addresses.
          RFC 3291."

      ::= { frwkIpFilterEntry 2 }




Sahita, et. al.              Informational                     [Page 47]

RFC 3318           Framework Policy Information Base          March 2003


  frwkIpFilterDstPrefixLength OBJECT-TYPE
      SYNTAX         InetAddressPrefixLength
      STATUS         current
      DESCRIPTION
          "The length of a mask for the matching of the destination
           IP address. This attribute is interpreted only if the
           InetAddressType is 'ipv4', 'ipv4z', 'ipv6' or 'ipv6z'.
           Masks are constructed by setting bits in sequence from the
           most-significant bit downwards for
           frwkIpFilterDstPrefixLength bits length. All other bits in
           the mask, up to the  number needed to fill the length of
           the address frwkIpFilterDstAddr are cleared to zero. A zero
           bit in the mask then means that the corresponding bit in
           the address always matches.

           In IPv4 addresses, a length of 0 indicates a match of any
           address; a length of 32 indicates a match of a single host
           address, and a length between 0 and 32 indicates the use of
           a CIDR Prefix. IPv6 is similar, except that prefix lengths
           range from 0..128."
      REFERENCE
          "Textual Conventions for Internet Network Addresses.
          RFC 3291."
      DEFVAL { 0 }

      ::= { frwkIpFilterEntry 3 }

  frwkIpFilterSrcAddr OBJECT-TYPE
      SYNTAX         InetAddress
      STATUS         current
      DESCRIPTION
          "The IP address to match against the packet's source IP
          address. If the address type is 'ipv4', 'ipv6', 'ipv4z' or
          'ipv6z' then, the attribute frwkIpFilterSrcPrefixLength
          indicates the number of bits that are relevant."
      REFERENCE
          "Textual Conventions for Internet Network Addresses.
          RFC 3291."

      ::= { frwkIpFilterEntry 4 }

  frwkIpFilterSrcPrefixLength OBJECT-TYPE
      SYNTAX         InetAddressPrefixLength
      UNITS          "bits"
      STATUS         current
      DESCRIPTION
          "The length of a mask for the matching of the source IP
           address. This attribute is interpreted only if the



Sahita, et. al.              Informational                     [Page 48]

RFC 3318           Framework Policy Information Base          March 2003


           InetAddressType is 'ipv4', 'ipv4z', 'ipv6' or 'ipv6z'.
           Masks are constructed by setting bits in sequence from the
           most-significant bit downwards for
           frwkIpFilterSrcPrefixLength bits length. All other bits in
           the mask, up to the  number needed to fill the length of
           the address frwkIpFilterSrcAddr are cleared to zero.  A
           zero bit in the mask then means that the corresponding bit
           in the address always matches.

           In IPv4 addresses, a length of 0 indicates a match of any
           address; a length of 32 indicates a match of a single host
           address, and a length between 0 and 32 indicates the use of
           a CIDR Prefix. IPv6 is similar, except that prefix lengths
           range from 0..128."
      REFERENCE
          "Textual Conventions for Internet Network Addresses.
          RFC 3291."
      DEFVAL { 0 }

      ::= { frwkIpFilterEntry 5 }

  frwkIpFilterDscp OBJECT-TYPE
      SYNTAX         DscpOrAny
      STATUS         current
      DESCRIPTION
          "The value that the DSCP in the packet can have and
           match this filter. A value of -1 indicates that a specific
           DSCP value has not been defined and thus all DSCP values
           are considered a match."
      REFERENCE
          "Management Information Base for the Differentiated Services
           Architecture. RFC 3289."
      DEFVAL { -1 }

      ::= { frwkIpFilterEntry 6 }

  frwkIpFilterFlowId OBJECT-TYPE
      SYNTAX        Integer32 (-1 | 0..1048575)
      STATUS         current
      DESCRIPTION
          "The flow label or flow identifier in an IPv6 header
           that may be used to discriminate traffic flows.
           The value of -1 for this attribute MUST imply that
           any flow label value in the IPv6 header will match,
           resulting in the flow label field of the IPv6 header
           being ignored for matching this filter entry."

      ::= { frwkIpFilterEntry 7 }



Sahita, et. al.              Informational                     [Page 49]

RFC 3318           Framework Policy Information Base          March 2003



  frwkIpFilterProtocol OBJECT-TYPE
      SYNTAX         Unsigned32 (0..255)
      STATUS         current
      DESCRIPTION
          "The layer-4 protocol Id to match against the IPv4 protocol
          number or the IPv6 Next-Header number in the packet. A value
          of 255 means match all. Note the protocol number of 255 is
          reserved by IANA, and Next-Header number of 0 is used in
          IPv6."
      DEFVAL { 255 }

      ::= { frwkIpFilterEntry 8 }

  frwkIpFilterDstL4PortMin OBJECT-TYPE
      SYNTAX         InetPortNumber
      STATUS         current
      DESCRIPTION
          "The minimum value that the packet's layer 4 destination
          port number can have and match this filter. This value must
          be equal to or lesser that the value specified for this
          filter in frwkIpFilterDstL4PortMax.

          COPS-PR error code 'attrValueInvalid' must be returned if
          the frwkIpFilterSrcL4PortMin is greater than
          frwkIpFilterSrcL4PortMax"
      REFERENCE
          "COPS Usage for Policy Provisioning.  RFC 3084, error
          codes section 4.5."
      DEFVAL { 0 }

     ::= { frwkIpFilterEntry 9 }

  frwkIpFilterDstL4PortMax OBJECT-TYPE
      SYNTAX         InetPortNumber
      STATUS         current
      DESCRIPTION
          "The maximum value that the packet's layer 4 destination
          port number can have and match this filter. This value must
          be equal to or greater that the value specified for this
          filter in frwkIpFilterDstL4PortMin.

          COPS-PR error code 'attrValueInvalid' must be returned if
          the frwkIpFilterDstL4PortMax is less than
          frwkIpFilterDstL4PortMin"
      REFERENCE
          "COPS Usage for Policy Provisioning.  RFC 3084, error
          codes section 4.5."



Sahita, et. al.              Informational                     [Page 50]

RFC 3318           Framework Policy Information Base          March 2003


      DEFVAL { 65535 }

      ::= { frwkIpFilterEntry 10 }

  frwkIpFilterSrcL4PortMin OBJECT-TYPE
      SYNTAX         InetPortNumber
      STATUS         current
      DESCRIPTION
          "The minimum value that the packet's layer 4 source port
          number can have and match this filter. This value must
          be equal to or lesser that the value specified for this
          filter in frwkIpFilterSrcL4PortMax.

          COPS-PR error code 'attrValueInvalid' must be returned if
          the frwkIpFilterSrcL4PortMin is greated than
          frwkIpFilterSrcL4PortMax"
      REFERENCE
          "COPS Usage for Policy Provisioning.  RFC 3084, error
          codes section 4.5."
      DEFVAL { 0 }

      ::= { frwkIpFilterEntry 11 }

  frwkIpFilterSrcL4PortMax OBJECT-TYPE
      SYNTAX         InetPortNumber
      STATUS         current
      DESCRIPTION
          "The maximum value that the packet's layer 4 source port
          number can have and match this filter.  This value must be
          equal to or greater that the value specified for this filter
          in frwkIpFilterSrcL4PortMin.

          COPS-PR error code 'attrValueInvalid' must be returned if
          the frwkIpFilterSrcL4PortMax is less than
          frwkIpFilterSrcL4PortMin"
      REFERENCE
          "COPS Usage for Policy Provisioning.  RFC error codes
          section 4.5."
      DEFVAL { 65535 }

      ::= { frwkIpFilterEntry 12 }

  --
  -- The IEEE 802 Filter Table
  --

  frwk802FilterTable OBJECT-TYPE
      SYNTAX         SEQUENCE OF Frwk802FilterEntry



Sahita, et. al.              Informational                     [Page 51]

RFC 3318           Framework Policy Information Base          March 2003


      PIB-ACCESS     install
      STATUS         current
      DESCRIPTION
          "IEEE 802-based filter definitions. A class that contains
          attributes of IEEE 802 (e.g., 802.3) traffic that form
          filters that are used to perform traffic classification."
      REFERENCE
          "IEEE Standards for Local and Metropolitan Area Networks.
          Overview and Architecture, ANSI/IEEE Std 802, 1990."
      ::= { frwkClassifierClasses 3 }

  frwk802FilterEntry OBJECT-TYPE
      SYNTAX         Frwk802FilterEntry
      STATUS         current
      DESCRIPTION
          "IEEE 802-based filter definitions.  An entry specifies
          (potentially) several distinct matching components. Each
          component is tested against the data in a frame
          individually. An overall match occurs when all of the
          individual components match the data they are compared
          against in the frame being processed. A failure of any
          one test causes the overall match to fail.

          Wildcards may be specified for those fields that are not
          relevant."

      EXTENDS { frwkBaseFilterEntry }
      UNIQUENESS { frwkBaseFilterNegation,
                   frwk802FilterDstAddr,
                   frwk802FilterDstAddrMask,
                   frwk802FilterSrcAddr,
                   frwk802FilterSrcAddrMask,
                   frwk802FilterVlanId,
                   frwk802FilterVlanTagRequired,
                   frwk802FilterEtherType,
                   frwk802FilterUserPriority }

      ::= { frwk802FilterTable 1 }

  Frwk802FilterEntry ::= SEQUENCE {
          frwk802FilterDstAddr         PhysAddress,
          frwk802FilterDstAddrMask     PhysAddress,
          frwk802FilterSrcAddr         PhysAddress,
          frwk802FilterSrcAddrMask     PhysAddress,
          frwk802FilterVlanId          Integer32,
          frwk802FilterVlanTagRequired INTEGER,
          frwk802FilterEtherType       Integer32,
          frwk802FilterUserPriority    BITS



Sahita, et. al.              Informational                     [Page 52]

RFC 3318           Framework Policy Information Base          March 2003


  }

  frwk802FilterDstAddr OBJECT-TYPE
      SYNTAX         PhysAddress
      STATUS         current
      DESCRIPTION
          "The 802 address against which the 802 DA of incoming
          traffic streams will be compared. Frames whose 802 DA
          matches the physical address specified by this object,
          taking into account address wildcarding as specified by the
          frwk802FilterDstAddrMask object, are potentially subject to
          the processing guidelines that are associated with this
          entry through the related action class."
      REFERENCE
          "Textual Conventions for SMIv2, RFC 2579."

      ::= { frwk802FilterEntry 1 }

  frwk802FilterDstAddrMask OBJECT-TYPE
      SYNTAX         PhysAddress
      STATUS         current
      DESCRIPTION
          "This object specifies the bits in a 802 destination address
          that should be considered when performing a 802 DA
          comparison against the address specified in the
          frwk802FilterDstAddr object.

          The value of this object represents a mask that is logically
          and'ed with the 802 DA in received frames to derive the
          value to be compared against the frwk802FilterDstAddr
          address. A zero bit in the mask thus means that the
          corresponding bit in the address always matches. The
          frwk802FilterDstAddr value must also be masked using this
          value prior to any comparisons.

          The length of this object in octets must equal the length in
          octets of the frwk802FilterDstAddr. Note that a mask with no
          bits set (i.e., all zeroes) effectively wildcards the
          frwk802FilterDstAddr object."

      ::= { frwk802FilterEntry 2 }

  frwk802FilterSrcAddr OBJECT-TYPE
      SYNTAX         PhysAddress
      STATUS         current
      DESCRIPTION
          "The 802 MAC address against which the 802 MAC SA of
          incoming traffic streams will be compared. Frames whose 802



Sahita, et. al.              Informational                     [Page 53]

RFC 3318           Framework Policy Information Base          March 2003


          MAC SA matches the physical address specified by this
          object, taking into account address wildcarding as specified
          by the frwk802FilterSrcAddrMask object, are potentially
          subject to the processing guidelines that are associated
          with this entry through the related action class."

      ::= { frwk802FilterEntry 3 }

  frwk802FilterSrcAddrMask OBJECT-TYPE
      SYNTAX         PhysAddress
      STATUS         current
      DESCRIPTION
          "This object specifies the bits in a 802 MAC source address
          that should be considered when performing a 802 MAC SA
          comparison against the address specified in the
          frwk802FilterSrcAddr object.

          The value of this object represents a mask that is logically
          and'ed with the 802 MAC SA in received frames to derive the
          value to be compared against the frwk802FilterSrcAddr
          address. A zero bit in the mask thus means that the
          corresponding bit in the address always matches. The
          frwk802FilterSrcAddr value must also be masked using this
          value prior to any comparisons.

          The length of this object in octets must equal the length in
          octets of the frwk802FilterSrcAddr. Note that a mask with no
          bits set (i.e., all zeroes) effectively wildcards the
          frwk802FilterSrcAddr object."

      ::= { frwk802FilterEntry 4 }

  frwk802FilterVlanId OBJECT-TYPE
      SYNTAX         Integer32 (-1 | 1..4094)
      STATUS         current
      DESCRIPTION
          "The VLAN ID (VID) that uniquely identifies a VLAN
          within the device. This VLAN may be known or unknown
          (i.e., traffic associated with this VID has not yet
          been seen by the device) at the time this entry
          is instantiated.

          Setting the frwk802FilterVlanId object to -1 indicates that
          VLAN data should not be considered during traffic
          classification."

      ::= { frwk802FilterEntry 5 }




Sahita, et. al.              Informational                     [Page 54]

RFC 3318           Framework Policy Information Base          March 2003


  frwk802FilterVlanTagRequired OBJECT-TYPE
      SYNTAX         INTEGER {
                         taggedOnly(1),
                         priorityTaggedPlus(2),
                         untaggedOnly(3),
                         ignoreTag(4)
                     }
      STATUS         current
      DESCRIPTION
          "This object indicates whether the presence of an
          IEEE 802.1Q VLAN tag in data link layer frames must
          be considered when determining if a given frame
          matches this 802 filter entry.

          A value of 'taggedOnly(1)' means that only frames
          containing a VLAN tag with a non-Null VID (i.e., a
          VID in the range 1..4094) will be considered a match.

          A value of 'priorityTaggedPlus(2)' means that only
          frames containing a VLAN tag, regardless of the value
          of the VID, will be considered a match.

          A value of 'untaggedOnly(3)' indicates that only
          untagged frames will match this filter component.

          The presence of a VLAN tag is not taken into
          consideration in terms of a match if the value is
          'ignoreTag(4)'."

      ::= { frwk802FilterEntry 6 }

  frwk802FilterEtherType OBJECT-TYPE
      SYNTAX         Integer32 (-1 | 0..'ffff'h)
      STATUS         current
      DESCRIPTION
          "This object specifies the value that will be compared
          against the value contained in the EtherType field of an
          IEEE 802 frame. Example settings would include 'IP'
          (0x0800), 'ARP' (0x0806) and 'IPX' (0x8137).

          Setting the frwk802FilterEtherTypeMin object to -1 indicates
          that EtherType data should not be considered during traffic
          classification.

          Note that the position of the EtherType field depends on
          the underlying frame format. For Ethernet-II encapsulation,
          the EtherType field follows the 802 MAC source address. For
          802.2 LLC/SNAP encapsulation, the EtherType value follows



Sahita, et. al.              Informational                     [Page 55]

RFC 3318           Framework Policy Information Base          March 2003


          the Organization Code field in the 802.2 SNAP header. The
        value that is tested with regard to this filter component
        therefore depends on the data link layer frame format being
        used. If this 802 filter component is active when there is
        no EtherType field in a frame (e.g., 802.2 LLC), a match is
        implied."

    ::= { frwk802FilterEntry 7 }

frwk802FilterUserPriority OBJECT-TYPE
    SYNTAX         BITS {
                        matchPriority0(0),
                        matchPriority1(1),
                        matchPriority2(2),
                        matchPriority3(3),
                        matchPriority4(4),
                        matchPriority5(5),
                        matchPriority6(6),
                        matchPriority7(7)
                   }
    STATUS         current
    DESCRIPTION
        "The set of values, representing the potential range
        of user priority values, against which the value contained
        in the user priority field of a tagged 802.1 frame is
        compared. A test for equality is performed when determining
        if a match exists between the data in a data link layer
        frame and the value of this 802 filter component. Multiple
        values may be set at one time such that potentially several
        different user priority values may match this 802 filter
        component.

        Setting all of the bits that are associated with this
        object causes all user priority values to match this
        attribute. This essentially makes any comparisons
        with regard to user priority values unnecessary. Untagged
        frames are treated as an implicit match."

    ::= { frwk802FilterEntry 8 }

--
-- The Internal label filter extension
--

frwkILabelFilterTable OBJECT-TYPE
    SYNTAX         SEQUENCE OF FrwkILabelFilterEntry
    PIB-ACCESS     install
    STATUS         current



Sahita, et. al.              Informational                     [Page 56]

RFC 3318           Framework Policy Information Base          March 2003


    DESCRIPTION
        "Internal label filter Table. This PRC is used to achieve
         classification based on the internal flow label set by the
         PEP possibly after ingress classification to avoid
         re-classification at the egress interface on the same PEP."

    ::= { frwkClassifierClasses 4 }

frwkILabelFilterEntry OBJECT-TYPE
    SYNTAX         FrwkILabelFilterEntry
    STATUS         current
    DESCRIPTION
        "Internal label filter entry definition."

    EXTENDS { frwkBaseFilterEntry }
    UNIQUENESS { frwkBaseFilterNegation,
                 frwkILabelFilterILabel }

    ::= { frwkILabelFilterTable 1 }

FrwkILabelFilterEntry ::= SEQUENCE {
   frwkILabelFilterILabel      OCTET STRING
}

frwkILabelFilterILabel      OBJECT-TYPE
    SYNTAX       OCTET STRING
    STATUS       current
    DESCRIPTION
       "The Label that this flow uses for differentiating traffic
        flows.  The flow labeling is meant for network device
       internal usage. A value of zero length string matches all
       internal labels."
    ::= { frwkILabelFilterEntry 1 }

--
-- The Marker classes group
--

frwkMarkerClasses
           OBJECT IDENTIFIER ::= { frameworkPib 4 }
--
-- The 802 Marker Table
--

frwk802MarkerTable OBJECT-TYPE
    SYNTAX         SEQUENCE OF Frwk802MarkerEntry
    PIB-ACCESS     install
    STATUS         current



Sahita, et. al.              Informational                     [Page 57]

RFC 3318           Framework Policy Information Base          March 2003


    DESCRIPTION
        "The 802 Marker class. An 802 packet can be marked with the
         specified VLAN id, priority level."

    ::= { frwkMarkerClasses 1 }

frwk802MarkerEntry OBJECT-TYPE
    SYNTAX         Frwk802MarkerEntry
    STATUS         current
    DESCRIPTION
        "frwk802Marker entry definition."

    PIB-INDEX { frwk802MarkerPrid }
    UNIQUENESS { frwk802MarkerVlanId,
                 frwk802MarkerPriority }

    ::= { frwk802MarkerTable 1 }

Frwk802MarkerEntry::= SEQUENCE {
        frwk802MarkerPrid          InstanceId,
        frwk802MarkerVlanId        Unsigned32,
        frwk802MarkerPriority      Unsigned32
}

frwk802MarkerPrid  OBJECT-TYPE
    SYNTAX         InstanceId
    STATUS         current
    DESCRIPTION
        "An integer index to uniquely identify this 802 Marker."

    ::= { frwk802MarkerEntry 1 }

frwk802MarkerVlanId  OBJECT-TYPE
    SYNTAX         Unsigned32 (1..4094)
    STATUS         current
    DESCRIPTION
        "The VLAN ID (VID) that uniquely identifies a VLAN within
         the device."

    ::= { frwk802MarkerEntry 2 }

frwk802MarkerPriority  OBJECT-TYPE
    SYNTAX         Unsigned32 (0..7)
    STATUS         current
    DESCRIPTION
        "The user priority field of a tagged 802.1 frame."

    ::= { frwk802MarkerEntry 3 }



Sahita, et. al.              Informational                     [Page 58]

RFC 3318           Framework Policy Information Base          March 2003



--
-- The Internal Label Marker Table
--

frwkILabelMarkerTable OBJECT-TYPE
    SYNTAX         SEQUENCE OF FrwkILabelMarkerEntry
    PIB-ACCESS     install
    STATUS         current
    DESCRIPTION
        "The Internal Label Marker class. A flow in a PEP can be
        marked with an internal label using this PRC."

    ::= { frwkMarkerClasses 2 }

frwkILabelMarkerEntry OBJECT-TYPE
    SYNTAX         FrwkILabelMarkerEntry
    STATUS         current
    DESCRIPTION
        "frwkILabelkMarker entry definition."

    PIB-INDEX { frwkILabelMarkerPrid }
    UNIQUENESS { frwkILabelMarkerILabel }

    ::= { frwkILabelMarkerTable 1 }

FrwkILabelMarkerEntry::= SEQUENCE {
        frwkILabelMarkerPrid          InstanceId,
        frwkILabelMarkerILabel        OCTET STRING
}

frwkILabelMarkerPrid  OBJECT-TYPE
    SYNTAX         InstanceId
    STATUS         current
    DESCRIPTION
        "An integer index to uniquely identify this Label Marker."

    ::= { frwkILabelMarkerEntry 1 }

frwkILabelMarkerILabel  OBJECT-TYPE
    SYNTAX         OCTET STRING
    STATUS         current
    DESCRIPTION
        "This internal label is implementation specific and may be
         used for other policy related functions like flow
         accounting purposes and/or other data path treatments."

    ::= { frwkILabelMarkerEntry 2 }



Sahita, et. al.              Informational                     [Page 59]

RFC 3318           Framework Policy Information Base          March 2003



--
-- Conformance Section
--

frwkBasePibConformance
                OBJECT IDENTIFIER ::= { frameworkPib 5 }

frwkBasePibCompliances
                OBJECT IDENTIFIER ::= { frwkBasePibConformance 1 }

frwkBasePibGroups
                OBJECT IDENTIFIER ::= { frwkBasePibConformance 2 }

frwkBasePibCompliance MODULE-COMPLIANCE
    STATUS  current
    DESCRIPTION
            "Describes the requirements for conformance to the
            Framework PIB."

    MODULE  -- this module
        MANDATORY-GROUPS { frwkPrcSupportGroup,
                           frwkPibIncarnationGroup,
                           frwkDeviceIdGroup,
                           frwkCompLimitsGroup,
                           frwkCapabilitySetGroup,
                           frwkRoleComboGroup,
                           frwkIfRoleComboGroup }

        OBJECT          frwkPibIncarnationLongevity
        PIB-MIN-ACCESS  notify
        DESCRIPTION
           "Install support is required if policy expiration is to
           be supported."

        OBJECT          frwkPibIncarnationTtl
        PIB-MIN-ACCESS  notify
        DESCRIPTION
           "Install support is required if policy expiration is to
           be supported."

        OBJECT          frwkPibIncarnationInCtxtSet
        PIB-MIN-ACCESS  notify
        DESCRIPTION
           "Install support is required if configuration contexts
           and outsourcing contexts are both to be supported."

        OBJECT          frwkPibIncarnationFullState



Sahita, et. al.              Informational                     [Page 60]

RFC 3318           Framework Policy Information Base          March 2003


        PIB-MIN-ACCESS  notify
        DESCRIPTION
            "Install support is required if incremental updates to
            request states is to be supported."

    GROUP   frwkReferenceGroup
        DESCRIPTION
            "The frwkReferenceGroup is mandatory if referencing
            across PIB contexts for specific client-types is to be
            supported."

    GROUP   frwkErrorGroup
        DESCRIPTION
            "The frwkErrorGroup is mandatory sending errors in
             decisions is to be supported."

    GROUP   frwkBaseFilterGroup
        DESCRIPTION
            "The frwkBaseFilterGroup is mandatory if filtering
             based on traffic components is to be supported."

    GROUP   frwkIpFilterGroup
        DESCRIPTION
            "The frwkIpFilterGroup is mandatory if filtering
             based on IP traffic components is to be supported."

    GROUP   frwk802FilterGroup
        DESCRIPTION
            "The frwk802FilterGroup is mandatory if filtering
            based on 802 traffic criteria is to be supported."

    GROUP   frwkILabelFilterGroup
        DESCRIPTION
            "The frwkILabelFilterGroup is mandatory if filtering
            based on PEP internal label is to be supported."

    GROUP   frwk802MarkerGroup
        DESCRIPTION
            "The frwk802MarkerGroup is mandatory if marking a packet
            with 802 traffic criteria is to be supported."

    GROUP   frwkILabelMarkerGroup
        DESCRIPTION
            "The frwkILabelMarkerGroup is mandatory if marking a
            flow with internal labels is to be supported."

    ::= { frwkBasePibCompliances 1 }




Sahita, et. al.              Informational                     [Page 61]

RFC 3318           Framework Policy Information Base          March 2003


frwkPrcSupportGroup OBJECT-GROUP
    OBJECTS {
             frwkPrcSupportPrid,
             frwkPrcSupportSupportedPrc,
             frwkPrcSupportSupportedAttrs }
    STATUS  current
    DESCRIPTION
            "Objects from the frwkPrcSupportTable."

    ::= { frwkBasePibGroups 1 }

frwkPibIncarnationGroup OBJECT-GROUP
    OBJECTS {
             frwkPibIncarnationPrid,
             frwkPibIncarnationName,
             frwkPibIncarnationId,
             frwkPibIncarnationLongevity,
             frwkPibIncarnationTtl,
             frwkPibIncarnationInCtxtSet,
             frwkPibIncarnationActive,
             frwkPibIncarnationFullState
            }
    STATUS  current
    DESCRIPTION
            "Objects from the frwkDevicePibIncarnationTable."

    ::= { frwkBasePibGroups 2 }

frwkDeviceIdGroup OBJECT-GROUP
    OBJECTS {
             frwkDeviceIdPrid,
             frwkDeviceIdDescr,
             frwkDeviceIdMaxMsg,
             frwkDeviceIdMaxContexts }
    STATUS  current
    DESCRIPTION
            "Objects from the frwkDeviceIdTable."

    ::= { frwkBasePibGroups 3 }

frwkCompLimitsGroup OBJECT-GROUP
    OBJECTS {
             frwkCompLimitsPrid,
             frwkCompLimitsComponent,
             frwkCompLimitsAttrPos,
             frwkCompLimitsNegation,
             frwkCompLimitsType,
             frwkCompLimitsSubType,



Sahita, et. al.              Informational                     [Page 62]

RFC 3318           Framework Policy Information Base          March 2003


             frwkCompLimitsGuidance }
    STATUS  current
    DESCRIPTION
            "Objects from the frwkCompLimitsTable."

    ::= { frwkBasePibGroups 4 }

frwkReferenceGroup OBJECT-GROUP
    OBJECTS {
             frwkReferencePrid,
             frwkReferenceClientType,
             frwkReferenceClientHandle,
             frwkReferenceInstance }
    STATUS  current
    DESCRIPTION
            "Objects from the frwkReferenceTable."

    ::= { frwkBasePibGroups 5 }

frwkErrorGroup OBJECT-GROUP
    OBJECTS {
             frwkErrorPrid,
             frwkErrorCode,
             frwkErrorSubCode,
             frwkErrorPrc,
             frwkErrorInstance }
    STATUS  current
    DESCRIPTION
            "Objects from the frwkErrorTable."

    ::= { frwkBasePibGroups 6 }

frwkCapabilitySetGroup OBJECT-GROUP
    OBJECTS {
             frwkCapabilitySetPrid,
             frwkCapabilitySetName,
             frwkCapabilitySetCapability }
    STATUS  current
    DESCRIPTION
            "Objects from the frwkCapabilitySetTable."

    ::= { frwkBasePibGroups 7 }

frwkRoleComboGroup OBJECT-GROUP
    OBJECTS {
             frwkRoleComboPrid,
             frwkRoleComboRoles,
             frwkRoleComboCapSetName }



Sahita, et. al.              Informational                     [Page 63]

RFC 3318           Framework Policy Information Base          March 2003


    STATUS  current
    DESCRIPTION
            "Objects from the frwkRoleComboTable."

    ::= { frwkBasePibGroups 8 }

frwkIfRoleComboGroup OBJECT-GROUP
    OBJECTS { frwkIfRoleComboIfIndex }
    STATUS  current
    DESCRIPTION
            "Objects from the frwkIfRoleComboTable."

    ::= { frwkBasePibGroups 9 }

frwkBaseFilterGroup OBJECT-GROUP
    OBJECTS {
             frwkBaseFilterPrid,
             frwkBaseFilterNegation }
    STATUS  current
    DESCRIPTION
            "Objects from the frwkBaseFilterTable."

    ::= { frwkBasePibGroups 10 }

frwkIpFilterGroup OBJECT-GROUP
    OBJECTS {
             frwkIpFilterAddrType,
             frwkIpFilterDstAddr,
             frwkIpFilterDstPrefixLength,
             frwkIpFilterSrcAddr,
             frwkIpFilterSrcPrefixLength,
             frwkIpFilterDscp,
             frwkIpFilterFlowId,
             frwkIpFilterProtocol,
             frwkIpFilterDstL4PortMin,
             frwkIpFilterDstL4PortMax,
             frwkIpFilterSrcL4PortMin,
             frwkIpFilterSrcL4PortMax }
    STATUS  current
    DESCRIPTION
            "Objects from the frwkIpFilterTable."

    ::= { frwkBasePibGroups 11 }

frwk802FilterGroup OBJECT-GROUP
    OBJECTS {
             frwk802FilterDstAddr,
             frwk802FilterDstAddrMask,



Sahita, et. al.              Informational                     [Page 64]

RFC 3318           Framework Policy Information Base          March 2003


             frwk802FilterSrcAddr,
             frwk802FilterSrcAddrMask,
             frwk802FilterVlanId,
             frwk802FilterVlanTagRequired,
             frwk802FilterEtherType,
             frwk802FilterUserPriority }
    STATUS  current
    DESCRIPTION
            "Objects from the frwk802FilterTable."

    ::= { frwkBasePibGroups 12 }

frwkILabelFilterGroup OBJECT-GROUP
    OBJECTS { frwkILabelFilterILabel }
    STATUS  current
    DESCRIPTION
            "Objects from the frwkILabelFilterTable."

    ::= { frwkBasePibGroups 13 }

frwk802MarkerGroup OBJECT-GROUP
    OBJECTS {
             frwk802MarkerPrid,
             frwk802MarkerVlanId,
             frwk802MarkerPriority }
    STATUS  current
    DESCRIPTION
            "Objects from the frwk802MarkerTable."

    ::= { frwkBasePibGroups 14 }

frwkILabelMarkerGroup OBJECT-GROUP
    OBJECTS {
             frwkILabelMarkerPrid,
             frwkILabelMarkerILabel }
    STATUS  current
    DESCRIPTION
            "Objects from the frwkILabelMarkerTable."

    ::= { frwkBasePibGroups 15 }

END









Sahita, et. al.              Informational                     [Page 65]

RFC 3318           Framework Policy Information Base          March 2003


6. Security Considerations

   It is clear that this PIB is used for configuration using [COPS-PR],
   and anything that can be configured can be misconfigured, with a
   potentially disastrous effect.  At this writing, no security holes
   have been identified beyond those that the COPS base protocol
   security is itself intended to address.  These relate primarily to
   controlled access to sensitive information and the ability to
   configure a device - or which might result from operator error, which
   is beyond the scope of any security architecture.

   There are a number of PRovisioning Classes defined in this PIB that
   have a PIB-ACCESS clause of install and install-notify (read-create).
   These are:

   frwkPibIncarnationTable: Malicious access of this PRC can cause the
   PEP to use an incorrect context of policies.

   frwkReferenceTable: Malicious access of this PRC can cause the PEP to
   interpret the installed policy in an incorrect manner.

   frwkErrorTable: Malicious access of this PRC can cause the PEP to
   incorrectly assume that the PDP could not process its messages.

   FrwkCapabilitySetTable, frwkRoleComboTable and frwkIfRoleComboTable:
   Malicious access of these PRCs can cause the PEP to apply policies to
   the wrong interfaces.

   FrwkBaseFilterTable, frwkIpFilterTable, frwk802FilterTable and
   frwkILabelFilterTable: Malicious access of these PRCs can cause
   unintended classification of traffic on the PEP potentially leading
   to incorrect policies being applied.

   frwk802MarkerTable, frwkILabelMarkerTable: Malicious access of these
   PRCs can cause unintended marking of traffic on the PEP potentially
   leading to incorrect policies being applied.

   Such objects may be considered sensitive or vulnerable in some
   network environments.  The support for "Install" or "Install-Notify"
   decisions sent over [COPS-PR] in a non-secure environment without
   proper protection can have a negative effect on network operations.
   There are a number of PRovisioning Classes in this PIB that may
   contain information that may be sensitive from a business
   perspective, in that they may represent a customer's service contract
   or the filters that the service provider chooses to apply to a
   customer's ingress or egress traffic.  There are no PRCs that are
   sensitive in their own right, such as passwords or monetary amounts.
   It may be important to control even "Notify"(read-only) access to



Sahita, et. al.              Informational                     [Page 66]

RFC 3318           Framework Policy Information Base          March 2003


   these PRCs and possibly to even encrypt the values of these PRIs when
   sending them over the network via COPS-PR.  The use of IPSEC between
   the PDP and the PEP, as described in [COPS], provides the necessary
   protection against security threats.  However, even if the network
   itself is secure, there is no control as to who on the secure network
   is allowed to "Install/Notify" (read/change/create/delete) the PRIs
   in this PIB.

   It is then a customer/user responsibility to ensure that the PEP/PDP
   giving access to an instance of this PIB, is properly configured to
   give access to only the PRIs and principals (users) that have
   legitimate rights to indeed "Install" or "Notify" (change/create/
   delete) them.

7. IANA Considerations

   This document describes the frameworkPib and frwkTcPib Policy
   Information Base (PIB) modules for registration under the "pib"
   branch registered with IANA.  The IANA has assigned PIB numbers 2 and
   3, respectively.

   Both these PIBs use "all" in the SUBJECT-CATEGORIES clause, i.e.,
   they apply to all COPS client types.  No new COPS client type is to
   be registered for these two PIB modules.

8. References

8.1 Normative References

   [COPS]           Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan,
                    R. and A. Sastry, "The COPS (Common Open Policy
                    Service) Protocol", RFC 2748, January 2000.

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

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

   [SNMP-SMI]       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.




Sahita, et. al.              Informational                     [Page 67]

RFC 3318           Framework Policy Information Base          March 2003


   [INETADDR]       Daniele, M., Haberman, B., Routhier, S. and J.
                    Schoenwaelder, "Textual Conventions for Internet
                    Network Addresses", RFC 3291, May 2002.

   [802]            IEEE Standards for Local and Metropolitan Area
                    Networks: Overview and Architecture, ANSI/IEEE Std
                    802, 1990.

   [SNMPFRWK]       Harrington, D., Presuhn, R. and B. Wijnen, "An
                    Architecture for Describing Simple Network
                    Management Protocol (SNMP) Management Frameworks",
                    STD 62, RFC 3411, December 2002.

   [RFC2863]        McCloghrie, K. and F. Kastenholz, "The Interfaces
                    Group MIB", RFC 2863, June 2000.

   [DS-MIB]         Baker, F., Chan, K. and  A. Smith, "Management
                    Information Base for the Differentiated Services
                    Architecture", RFC 3289, May 2002.

   [SNMPv2TC]       McCloghrie, K., Perkins, D., and J. Schoenwaelder,
                    "Textual Conventions for SMIv2", STD 58, RFC 2579,
                    April 1999.

   [RFC2279]        Yergeau, F. "UTF-8, a transformation format of ISO
                    10646", RFC 2279, January 1998.

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

8.2 Informative References

   [RAP-FRAMEWORK]  Yavatkar, R and D. Pendarakis, "A Framework for
                    Policy-based Admission Control", RFC 2753, January
                    2000.

   [POLTERM]        Westerinen, A., Schnizlein, J., Strassner, J.,
                    Scherling, M., Quinn, B., Herzog, S., Huynh, A.,
                    Carlson, M., Perry, J. and S. Waldbusser,
                    "Terminology for Policy-Based Management", RFC 3198,
                    November 2001.

9. Acknowledgments

   Early versions of this specification were also co-authored by Michael
   Fine, Francis Reichmeyer, John Seligson and Andrew Smith.





Sahita, et. al.              Informational                     [Page 68]

RFC 3318           Framework Policy Information Base          March 2003


   Special thanks to Carol Bell, David Durham and Bert Wijnen for their
   many significant comments.

   Additional useful comments have been made by Diana Rawlins, Martin
   Bokaemper, Tina Iliff, Pedro Da Silva, Juergen Schoenwaelder,
   Noisette Yoann and Man Li.

10. Authors' Addresses

   Ravi Sahita
   Intel Labs.
   2111 NE 25th Avenue
   Hillsboro, OR 97124 USA

   Phone: +1 503 712 1554
   EMail: ravi.sahita@intel.com


   Scott Hahn
   Intel Corp.
   2111 NE 25th Avenue
   Hillsboro, OR 97124 USA

   Phone: +1 503 264 8231
   EMail: scott.hahn@intel.com


   Kwok Ho Chan
   Nortel Networks, Inc.
   600 Technology Park Drive
   Billerica, MA 01821 USA

   Phone: +1 978 288 8175
   EMail: khchan@nortelnetworks.com


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

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








Sahita, et. al.              Informational                     [Page 69]

RFC 3318           Framework Policy Information Base          March 2003


11.  Full Copyright Statement

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



















Sahita, et. al.              Informational                     [Page 70]