File: rfc3198.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 (1179 lines) | stat: -rw-r--r-- 47,806 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






Network Working Group                                      A. Westerinen
Request for Comments: 3198                                 J. Schnizlein
Category: Informational                                    Cisco Systems
                                                            J. Strassner
                                                  Intelliden Corporation
                                                            M. Scherling
                                                                   xCert
                                                                B. Quinn
                                                          Celox Networks
                                                               S. Herzog
                                                        PolicyConsulting
                                                                A. Huynh
                                                     Lucent Technologies
                                                              M. Carlson
                                                        Sun Microsystems
                                                                J. Perry
                                                       Network Appliance
                                                           S. Waldbusser
                                                           November 2001


                Terminology for Policy-Based Management

Status of this Memo

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

Copyright Notice

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

Abstract

   This document is a glossary of policy-related terms.  It provides
   abbreviations, explanations, and recommendations for use of these
   terms.  The document takes the approach and format of RFC 2828, which
   defines an Internet Security Glossary. The intent is to improve the
   comprehensibility and consistency of writing that deals with network
   policy, particularly Internet Standards documents (ISDs).










Westerinen, et al.           Informational                      [Page 1]

RFC 3198        Terminology for Policy-Based Management    November 2001


Table of Contents

   1. Introduction...................................................  2
   2. Explanation of Paragraph Markings..............................  3
   3. Terms..........................................................  3
   4. Intellectual Property.......................................... 16
   5. Acknowledgements............................................... 17
   6. Security Considerations........................................ 17
   7. References..................................................... 17
   8. Authors' Addresses............................................. 19
   9. Full Copyright Statement....................................... 21

1. Introduction

   This document provides abbreviations, definitions, and explanations
   of terms related to network policy.  All definitions are provided in
   Section 3, with the terms listed in alphabetical order.

   The intent is to improve the comprehensibility and consistency of
   Internet Standards documents (ISDs) -- i.e., RFCs, Internet-Drafts,
   and other material produced as part of the Internet Standards Process
   [RFC2026].  Benefits across the ISDs are well-stated in the
   Introduction to RFC 2828 [RFC2828]:

   o  "Clear, Concise, and Easily Understood Documentation" - Requires
      that the set of terms and definitions be consistent, self-
      supporting and uniform across all ISDs.

   o  Technical Excellence - Where all ISDs use terminology accurately,
      precisely, and unambiguously.

   o  Prior Implementation and Testing - Requires that terms are used in
      their plainest form, that private and "made-up" terms are avoided
      in ISDs, and that new definitions are not created that conflict
      with established ones.

   o  "Openness, Fairness, and Timeliness" - Where ISDs avoid terms that
      are proprietary or otherwise favor a particular vendor, or that
      create a bias toward a particular technology or mechanism.

   Common and/or controversial policy terms are defined.  These terms
   are directly related and specific to network policy.

   Wherever possible, this document takes definitions from existing
   ISDs.  It should be noted that:

   o  Expired Internet-Drafts are not referenced, nor are their
      terminology and definitions used in this document.



Westerinen, et al.           Informational                      [Page 2]

RFC 3198        Terminology for Policy-Based Management    November 2001


   o  Multiple definitions may exist across the ISDs.  Each definition
      is listed, with its source.

2. Explanation of Paragraph Markings

   Section 3 marks terms and definitions as follows:

   o  Capitalization: Only terms that are proper nouns are capitalized.

   o  Paragraph Marking: Definitions and explanations are stated in
      paragraphs that are marked as follows:

      -  "P" identifies basic policy-related terms.

      -  "T" identifies various techniques to create or convey policy-
         related information in a network.  For example, COPS and an
         "Information Model" are two techniques for communicating and
         describing policy-related data.  SNMP and MIBs are another.

      -  "A" identifies specific Work Groups and general "areas of use"
         of policy.  For example, AAA and QoS are two "areas of use"
         where policy concepts are extremely important to their function
         and operation.

3. Terms

   Note:  In providing policy definitions, other "technology specific"
   terms (for example, related to Differentiated Services) may be used
   and referenced.  These non-policy terms will not be defined in this
   document, and the reader is requested to go to the referenced ISD for
   additional detail.

   $ AAA
      See "Authentication, Authorization, Accounting".

   $ abstraction levels
      See "policy abstraction".

   $ action
      See "policy action".

   $ Authentication, Authorization, Accounting (AAA)
      (A) AAA deals with control, authentication, authorization and
          accounting of systems and environments based on policies set
          by the administrators and users of the systems.  The use of
          policy may be implicit - as defined by RADIUS [RFC2138]. In
          RADIUS, a network access server sends dial-user credentials to
          an AAA server, and receives authentication that the user is



Westerinen, et al.           Informational                      [Page 3]

RFC 3198        Terminology for Policy-Based Management    November 2001


          who he/she claims, along with a set of attribute-value pairs
          authorizing various service features. Policy is implied in
          both the authentication, which can be restricted by time of
          day, number of sessions, calling number, etc., and the
          attribute-values authorized.

   $ CIM
      See "Common Information Model".

   $ Common Information Model (CIM)
      (T) An object-oriented information model published by the DMTF
          (Distributed Management Task Force) [DMTF].  It consists of a
          Specification detailing the abstract modeling constructs and
          principles of the Information Model, and a textual language
          definition to represent the Model.  CIM's schemas are defined
          as a set of files, written in the language of the
          Specification, with graphical renderings using UML [UML].
          Sets of classes and associations represent CIM's Core and
          Common Models, defining an information model for the
          "enterprise" - addressing general concepts (in Core), and
          systems, devices, users, software distribution, the physical
          environment, networks and policy (in the Common Models).  (See
          also "information model".)

   $ Common Open Policy Service (COPS)
      (T) A simple query and response TCP-based protocol that can be
          used to exchange policy information between a Policy Decision
          Point (PDP) and its clients (Policy Enforcement Points, PEPs)
          [RFC2748].  The COPS protocol is used to provide for the
          outsourcing of policy decisions for RSVP [RFC2749]. Another
          usage is for the provisioning of policy [RFC3084]. (See also
          "Policy Decision Point" and "Policy Enforcement Point".)

   $ condition
      See "policy condition".

   $ configuration
      (P) "Configuration" can be defined from two perspectives:
          -  The set of parameters in network elements and other systems
             that determine their function and operation. Some
             parameters are static, such as packet queue assignment and
             can be predefined and downloaded to a network element.
             Others are more dynamic, such as the actions taken by a
             network device upon the occurrence of some event.  The
             distinction between static (predefined) "configuration" and
             the dynamic state of network elements blurs as setting
             parameters becomes more responsive, and signaling controls
             greater degrees of a network device's behavior.



Westerinen, et al.           Informational                      [Page 4]

RFC 3198        Terminology for Policy-Based Management    November 2001


          -  A static setup of a network element, done before shipment
             to a customer and which cannot be modified by the customer.
          The first is the accepted usage in the Internet community.

   $ COPS
      See "Common Open Policy Service".

   $ data model
      (T) A mapping of the contents of an information model into a form
          that is specific to a particular type of data store or
          repository.  A "data model" is basically the rendering of an
          information model according to a specific set of mechanisms
          for representing, organizing, storing and handling data.  It
          has three parts [DecSupp]:
          -  A collection of data structures such as lists, tables,
             relations, etc.
          -  A collection of operations that can be applied to the
             structures such as retrieval, update, summation, etc.
          -  A collection of integrity rules that define the legal
             states (set of values) or changes of state (operations on
             values).
          (See also "information model".)

   $ DEN
      See "Directory Enabled Networks".

   $ Differentiated Services (DS)
      (T) The IP header field, called the DS-field.  In IPv4, it defines
          the layout of the ToS (Type of Service) octet; in IPv6, it is
          the Traffic Class octet [RFC2474].
      (A) "Differentiated Services" is also an "area of use" for QoS
          policies.  It requires policy to define the correspondence
          between codepoints in the packet's DS-field and individual
          per-hop behaviors (to achieve a specified per-domain
          behavior).  In addition, policy can be used to specify the
          routing of packets based on various classification criteria.
          (See also "Quality of Service" and "filter".)

   $ diffserv
      See "Differentiated Services".

   $ Directory Enabled Networks (DEN)
      (T) A data model that is the LDAP mapping of CIM (the Common
          Information Model).  Its goals are to enable the deployment
          and use of policy by starting with common service and user
          concepts (defined in the information model), specifying their





Westerinen, et al.           Informational                      [Page 5]

RFC 3198        Terminology for Policy-Based Management    November 2001


          mapping/storage in an LDAP-based repository, and using these
          concepts in vendor/device-independent policy rules [DMTF].
          (See also "Common Information Model" and "data model".)

   $ domain
      (P) A collection of elements and services, administered in a
          coordinated fashion.  (See also "policy domain".)

   $ DS
      See "Differentiated Services".

   $ filter
      (T) A set of terms and/or criteria used for the purpose of
          separating or categorizing.  This is accomplished via single-
          or multi-field matching of traffic header and/or payload data.
          "Filters" are often manipulated and used in network operation
          and policy.  For example, packet filters specify the criteria
          for matching a pattern (for example, IP or 802 criteria) to
          distinguish separable classes of traffic.

   $ goal
      See "policy goal".

   $ information model
      (T) An abstraction and representation of the entities in a managed
          environment, their properties, attributes and operations, and
          the way that they relate to each other.  It is independent of
          any specific repository, software usage, protocol, or
          platform.

   $ Management Information Base (MIB)
      (T) A collection of information that can be accessed via the
          Simple Network Management Protocol.  Management information is
          defined in MIB modules using the rules contained in SNMP's
          Structure of Management Information (SMI) specifications
          [RFC2570].  Management information is an abstract concept, and
          definitions can be created for high level policy
          specifications, low level policy, as well as technology and
          vendor specific configurations, status and statistics.  (See
          also "Simple Network Management Protocol" and "Structure of
          Management Information".)

   $ MIB
      See "Management Information Base".







Westerinen, et al.           Informational                      [Page 6]

RFC 3198        Terminology for Policy-Based Management    November 2001


   $ MPLS
      See "Multiprotocol Label Switching".  (Also, MPLS may refer to
      Multi-Protocol Lambda Switching in optical networks.  But, this is
      unrelated to policy and not discussed further in this document.)

   $ Multiprotocol Label Switching (MPLS)
      (T) Integrates a label swapping and switching framework with
          network layer routing [RFC2702].  The basic idea involves
          assigning short fixed length labels to packets at the ingress
          to an MPLS cloud.  Throughout the interior of the MPLS domain,
          the labels attached to packets are used to make forwarding
          decisions (usually without recourse to the original packet
          headers).

   $ outsourced policy
      (P) An execution model where a policy enforcement device issues a
          query to delegate a decision for a specific policy event to
          another component, external to it.  For example, in RSVP, the
          arrival of a new RSVP message to a PEP requires a fast policy
          decision (not to delay the end-to-end setup). The PEP may use
          COPS-RSVP to send a query to the PDP, asking for a policy
          decision [RFC2205, RFC2748].  "Outsourced policy" is
          contrasted with "provisioned policy", but they are not
          mutually exclusive and operational systems may combine the
          two.

   $ PCIM
      See "Policy Core Information Model".

   $ PDP
      See "Policy Decision Point".

   $ PEP
      See "Policy Enforcement Point".

   $ PIB
      See "Policy Information Base".

   $ policy
      (P) "Policy" can be defined from two perspectives:
          -  A definite goal, course or method of action to guide and
             determine present and future decisions.  "Policies" are
             implemented or executed within a particular context (such
             as policies defined within a business unit).
          -  Policies as a set of rules to administer, manage, and
             control access to network resources [RFC3060].





Westerinen, et al.           Informational                      [Page 7]

RFC 3198        Terminology for Policy-Based Management    November 2001


          Note that these two views are not contradictory since
          individual rules may be defined in support of business goals.
          (See also "policy goal", "policy abstraction" and "policy
          rule".)

   $ policy abstraction
      (P) Policy can be represented at different levels, ranging from
          business goals to device-specific configuration parameters.
          Translation between different levels of "abstraction" may
          require information other than policy, such as network and
          host parameter configuration and capabilities.  Various
          documents and implementations may specify explicit levels of
          abstraction.  However, these do not necessarily correspond to
          distinct processing entities or the complete set of levels in
          all environments.  (See also "configuration" and "policy
          translation".)

   $ policy action
      (P) Definition of what is to be done to enforce a policy rule,
          when the conditions of the rule are met.  Policy actions may
          result in the execution of one or more operations to affect
          and/or configure network traffic and network resources.
          -  In [RFC3060], a rule's actions may be ordered.

   $ policy condition
      (P) A representation of the necessary state and/or prerequisites
          that define whether a policy rule's actions should be
          performed.  This representation need not be completely
          specified, but may be implicitly provided in an implementation
          or protocol.  When the policy condition(s) associated with a
          policy rule evaluate to TRUE, then (subject to other
          considerations such as rule priorities and decision
          strategies) the rule should be enforced.
      (T) In [RFC3060], a rule's conditions can be expressed as either
          an ORed set of ANDed sets of statements (disjunctive normal
          form), or an ANDed set of ORed sets of statements (conjunctive
          normal form).  Individual condition statements can also be
          negated.

   $ policy conflict
      (P) Occurs when the actions of two rules (that are both satisfied
          simultaneously) contradict each other.  The entity
          implementing the policy would not be able to determine which
          action to perform.  The implementers of policy systems must
          provide conflict detection and avoidance or resolution
          mechanisms to prevent this situation.  "Policy conflict" is
          contrasted with "policy error".




Westerinen, et al.           Informational                      [Page 8]

RFC 3198        Terminology for Policy-Based Management    November 2001


   $ policy conversion
      See "policy translation".

   $ Policy Core Information Model (PCIM) [RFC3060]
      (T) An information model describing the basic concepts of policy
          groups, rules, conditions, actions, repositories and their
          relationships.  This model is described as a "core" model
          since it cannot be applied without domain-specific extensions
          (for example, extensions for QoS or IPsec).  PCIM is "core"
          with respect to the area of policy.  However, it is a "Common
          Model," with respect to CIM - in that it extends the basic CIM
          concepts for policy.  (See also "Common Information Model".)

   $ policy decision
      (P) Two perspectives of "policy decision" exist:
          -  A "process" perspective that deals with the evaluation of a
             policy rule's conditions
          -  A "result" perspective that deals with the actions for
             enforcement, when the conditions of a policy rule are TRUE

   $ Policy Decision Point (PDP)
      (P) A logical entity that makes policy decisions for itself or for
          other network elements that request such decisions [RFC2753].
          (See also "policy decision".)

   $ policy domain
      (P) A collection of elements and services, and/or a portion of an
          Internet over which a common and consistent set of policies
          are administered in a coordinated fashion [RFC2474]. This
          definition of a policy domain does not preclude multiple
          sources of policy creation within an organization, but does
          require that the resultant policies be coordinated.
          -  Policies defined in the context of one domain may need to
             be communicated or negotiated outside of that domain. (See
             also "policy negotiation".)

   $ policy enforcement
      (P) The execution of a policy decision.

   $ Policy Enforcement Point (PEP)
      (P) A logical entity that enforces policy decisions [RFC2753].
          (See also "policy enforcement".)

   $ policy error
      (P) "Policy errors" occur when attempts to enforce policy actions
          fail, whether due to temporary state or permanent mismatch
          between the policy actions and the device enforcement
          capabilities.  This is contrasted with "policy conflict".



Westerinen, et al.           Informational                      [Page 9]

RFC 3198        Terminology for Policy-Based Management    November 2001


   $ policy goal
      (P) Goals are the business objectives or desired state intended to
          be maintained by a policy system.  As the highest level of
          abstraction of policy, these goals are most directly described
          in business rather than technical terms.  For example, a goal
          might state that a particular application operate on a network
          as though it had its own dedicated network, despite using a
          shared infrastructure. 'Policy goals' can include the
          objectives of a service level agreement, as well as the
          assignment of resources to applications or individuals.  A
          policy system may be created that automatically strives to
          achieve a goal through feedback regarding whether the goal
          (such as a service level) is being met.

   $ Policy Information Base (PIB)
      (T) Collections of related PRovisioning Classes (PRCs), defined as
          a module.  (See also "PRovisioning Class".)

   $ policy mapping
      See "policy translation".

   $ policy negotiation
      (P) Exposing the desired or appropriate part of a policy to
          another domain.  This is necessary to support partial
          interconnection between domains, which are operating with
          different sets of policies.

   $ policy repository
      (P) "Policy repository" can be defined from three perspectives:
          -  A specific data store that holds policy rules, their
             conditions and actions, and related policy data.  A
             database or directory would be an example of such a store.
          -  A logical container representing the administrative scope
             and naming of policy rules, their conditions and actions,
             and related policy data.  A "QoS policy" domain would be an
             example of such a container.
          -  In [RFC3060], a more restrictive definition than the prior
             one exists.  A PolicyRepository is a model abstraction
             representing an administratively defined, logical container
             for reusable policy elements.

   $ policy request
      (P) A message requesting a policy-related service.  This may refer
          to a request to retrieve a specific set of policy rules, to
          determine the actions to enforce, or other policy requests.
          When sent by a PEP to a PDP, it is more accurately qualified
          as a "policy decision request" [RFC2753].  (See also "policy
          decision".)



Westerinen, et al.           Informational                     [Page 10]

RFC 3198        Terminology for Policy-Based Management    November 2001


   $ policy rule
      (P) A basic building block of a policy-based system.  It is the
          binding of a set of actions to a set of conditions - where the
          conditions are evaluated to determine whether the actions are
          performed [RFC3060].

   $ policy server
      (P) A marketing term whose definition is imprecise. Originally,
          [RFC2753] referenced a "policy server".  As the RFC evolved,
          this term became more precise and known as the Policy Decision
          Point (PDP).  Today, the term is used in marketing and other
          literature to refer specifically to a PDP, or for any entity
          that uses/services policy.

   $ policy translation
      (P) The transformation of a policy from a representation and/or
          level of abstraction, to another representation or level of
          abstraction.  For example, it may be necessary to convert PIB
          data to a command line format.  In this "conversion," the
          translation to the new representation is likely to require a
          change in the level of abstraction (becoming more or less
          specific).  Although these are logically distinct tasks, they
          are (in most cases) blurred in the act of
          translating/converting/mapping.  Therefore, this is also known
          as "policy conversion" or "policy mapping".

   $ PolicyGroup
      (T) An abstraction in the Policy Core Information Model [RFC3060].
          It is a class representing a container, aggregating either
          policy rules or other policy groups.  It allows the grouping
          of rules into a Policy, and the refinement of high-level
          Policies to lower-level or different (i.e., converted or
          translated) peer groups.

   $ PRC
      See "PRovisioning Class".

   $ PRI
      See "PRovisioning Instance".

   $ provisioned policy
      (P) An execution model where network elements are pre-configured,
          based on policy, prior to processing events. Configuration is
          pushed to the network device, e.g., based on time of day or at
          initial booting of the device.  The focus of this model is on
          the distribution of configuration information, and is
          exemplified by Differentiated Services [RFC2475].  Based on
          events received, devices use downloaded (pre-provisioned)



Westerinen, et al.           Informational                     [Page 11]

RFC 3198        Terminology for Policy-Based Management    November 2001


          mechanisms to implement policy. "Provisioned policy" is
          contrasted with "outsourced policy".

   $ PRovisioning Class (PRC)
      (T) An ordered set of attributes representing a type of policy
          data.  PRCs are defined in PIB modules (encoded using SPPI)
          and registered in the Object Identifier tree.  Instances of
          each PRC are organized in tables, similar to conceptual tables
          in SMIv2.  (See also "Structure of Policy Provisioning
          Information" and "Policy Information Base".)
          The acronym, PRC, has evolved from "policy rule class" to
          "provisioning class".  The reason for the change is that a
          discrepancy existed between the use of the words, "policy
          rule" in the PRC context versus other uses in PCIM and the
          industry.  In the latter, rules are If/Then statements - a
          binding of conditions to actions.  PRCs are not "rules" by
          this definition, but the encoding of (network-wide)
          configuration information for a device.

   $ PRovisioning Instance (PRI)
      (T) An instantiation of a PRovisioning Class.  (See also
          "PRovisioning Class".)

   $ QoS
      See "Quality of Service".

   $ Quality of Service (QoS)
      (A) At a high level of abstraction, "Quality of Service" refers to
          the ability to deliver network services according to the
          parameters specified in a Service Level Agreement. "Quality"
          is characterized by service availability, delay, jitter,
          throughput and packet loss ratio.  At a network resource
          level, "Quality of Service" refers to a set of capabilities
          that allow a service provider to prioritize traffic, control
          bandwidth, and network latency.  There are two different
          approaches to "Quality of Service" on IP networks: Integrated
          Services [RFC1633], and Differentiated Service [RFC2475].
          Integrated Services require policy control over the creation
          of signaled reservations, which provide specific quantitative
          end-to-end behavior for a (set of) flow(s).  In contrast,
          Differentiated Services require policy to define the
          correspondence between codepoints in the packet's DS-field and
          individual per-hop behaviors (to achieve a specified per-
          domain behavior).  A maximum of 64 per-hop behaviors limit the
          number of classes of service traffic that can be marked at any
          point in a domain.  These classes of service signal the
          treatment of the packets with respect to various QoS aspects,
          such as flow priority and packet drop precedence.  In



Westerinen, et al.           Informational                     [Page 12]

RFC 3198        Terminology for Policy-Based Management    November 2001


          addition, policy can be used to specify the routing of packets
          based on various classification criteria.  Policy controls the
          set of configuration parameters and routing for each class in
          Differentiated Service, and the admission conditions for
          reservations in Integrated Services.  (See also "policy
          abstraction" and "Service Level Agreement".)

   $ Resource reSerVation Protocol (RSVP)
      (T) A setup protocol designed for an Integrated Services Internet,
          to reserve network resources for a path [RFC2205]. And, a
          signaling mechanism for managing application traffic's QoS in
          a Differentiated Service network.

   $ role
      (P) "Role" is defined from three perspectives:
          -  A business position or function, to which people and
             logical entities are assigned [X.500]
          -  The labeled endpoints of a UML (Unified Modeling Language)
             association.  Quoting from [UML], "When a class
             participates in an association, it has a specific role that
             it plays in that relationship; a role is just the face the
             class at the near end of the association presents to the
             class at the other end of the association".  The Policy
             Core Information Model [RFC3060] uses UML to depict its
             class hierarchy. Relationships/associations are significant
             in the model.
          -  An administratively specified characteristic of a managed
             element (for example, an interface).  It is a selector for
             policy rules and PRovisioning Classes (PRCs), to determine
             the applicability of the rule/PRC to a particular managed
             element [RFC3060].
          Only the third definition (roles as selectors of policy) is
          directly related to the management of network policy. However,
          the first definition (roles as business positions and
          functions) may be referenced in policy conditions and actions.

   $ role combination
      (P) A lexicographically ordered set of roles that characterize
          managed elements and indicate the applicability of policy
          rules and PRovisioning Classes (PRCs).  A policy system uses
          the set of roles reported by the managed element to determine
          the correct rules/PRCs to be sent for enforcement.  That
          determination may examine all applicable policy rules
          identified by the role combination, its sub-combinations and
          the individual roles in the combination [RFC3060].  In the
          case of PRCs, a PRC must explicitly match the role combination
          of the managed element in order to be applicable and/or
          enforced.  (The comparison is typically case-sensitive.)  The



Westerinen, et al.           Informational                     [Page 13]

RFC 3198        Terminology for Policy-Based Management    November 2001


          final set of rules/PRCs for enforcement are defined by the
          policy system, as appropriate for the specified role
          combination of the managed element.

   $ RSVP
      See "Resource reSerVation Protocol".

   $ rule
      See "policy rule".

   $ rule based engine
      (T) A rule based engine is able to evaluate policy condition(s)
          and trigger appropriate policy actions.  A particular rule
          based engine may only be capable of acting upon policy rules
          that are formatted in a specified way or adhere to a specific
          language.

   $ schema
      (T) Two different perspectives of schema are defined:
          -  A set of rules that determines what data can be stored in a
             database or directory service [DirServs]
          -  A collection of data models that are each bound to the same
             type of repository.
          The latter is the preferred and recommended one for Internet
          Standards documents.  (See also "data model".)

   $ service
      (P) The behavior or functionality provided by a network, network
          element or host [DMTF, RFC2216].  Quoting from RFC 2216
          [RFC2216], in order to completely specify a "service", one
          must define the "functions to be performed ..., the
          information required ... to perform these functions, and the
          information made available by the element to other elements of
          the system".  Policy can be used to configure a "service" in a
          network or on a network element/host, invoke its
          functionality, and/or coordinate services in an interdomain or
          end-to-end environment.

   $ Service Level Agreement (SLA)
      (P) The documented result of a negotiation between a
          customer/consumer and a provider of a service, that specifies
          the levels of availability, serviceability, performance,
          operation or other attributes of the service [RFC2475]. (See
          also "Service Level Objective".)







Westerinen, et al.           Informational                     [Page 14]

RFC 3198        Terminology for Policy-Based Management    November 2001


   $ Service Level Objective (SLO)
      (P) Partitions an SLA into individual metrics and operational
          information to enforce and/or monitor the SLA.  "Service Level
          Objectives" may be defined as part of an SLA, an SLS, or in a
          separate document.  It is a set of parameters and their
          values.  The actions of enforcing and reporting monitored
          compliance can be implemented as one or more policies.  (See
          also "Service Level Agreement".)

   $ Service Level Specification (SLS)
      (P) Specifies handling of customer's traffic by a network
          provider.  It is negotiated between a customer and the
          provider, and (for example) in a DiffServ environment, defines
          parameters such as specific Code Points and the Per-Hop-
          Behavior, profile characteristics and treatment of the traffic
          for those Code Points.  An SLS is a specific SLA (a negotiated
          agreement) and its SLOs (the individual metrics and
          operational data to enforce) to guarantee quality of service
          for network traffic.  (See also "Service Level Agreement" and
          "Service Level Objective".)

   $ Simple Network Management Protocol (SNMP)
      (T) SNMP is a framework (including a protocol) for managing
          systems in a network environment [RFC2570].  It can be used
          for policy-based configuration and control using a specific
          MIB Module designed to execute policies on managed elements
          via scripts.  The elements (instances) in a network device are
          evaluated using a policy filter, to determine where policy
          will be applied.

   $ SLA
      See "Service Level Agreement".

   $ SLO
      See "Service Level Objective".

   $ SLS
      See "Service Level Specification".

   $ SMIv2
      See "Structure of Management Information".

   $ SNMP
      See "Simple Network Management Protocol".

   $ SPPI
      See "Structure of Policy Provisioning Information".




Westerinen, et al.           Informational                     [Page 15]

RFC 3198        Terminology for Policy-Based Management    November 2001


   $ Structure of Policy Provisioning Information (SPPI)
      (T) An adapted subset of SNMP's Structure of Management
          Information (SMIv2) that is used to encode collections of
          related PRovisioning Classes as a PIB [RFC3159]. (See also
          "Policy Information Base" and "PRovisioning Class".)

   $ Structure of Management Information, version 2 (SMIv2)
      (T) An adapted subset of OSI's Abstract Syntax Notation One, ASN.1
          (1988) used to encode collections of related objects as SNMP
          Management Information Base (MIB) modules [RFC2578].

   $ subject
      (P) An entity, or collection of entities, which originates a
          request, and is verified as authorized/not authorized to
          perform that request.

   $ target
      (P) An entity, or collection of entities, which is affected by a
          policy.  For example, the "targets" of a policy to reconfigure
          a network device are the individual services that are updated
          and configured.

4. Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   intellectual property or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; neither does it represent that it
   has made any effort to identify any such rights.  Information on the
   IETF's procedures with respect to rights in standards-track and
   standards-related documentation can be found in BCP-11.

   Copies of claims of rights made available for publication and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF Secretariat.

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







Westerinen, et al.           Informational                     [Page 16]

RFC 3198        Terminology for Policy-Based Management    November 2001


5. Acknowledgements

   This document builds on the work of previous terminology drafts. The
   authors of these documents were Fran Reichmeyer, Dan Grossman, John
   Strassner, Ed Ellesson and Matthew Condell.  Also, definitions for
   the general concepts of policy and policy rule include input from
   Predrag Spasic.  Very helpful comments and suggestions were received
   from Juergen Schoenwaelder, Joe Salowey, Jon Saperia, Ravi Sahita,
   Bob Moore, Guus Sliepen, T.H. Jonatan and Dave Perkins.

6. Security Considerations

   This document only defines policy-related terms.  It does not
   describe in detail the vulnerabilities of, threats to, or mechanisms
   that protect specific policy implementations or policy-related
   Internet protocols.

7. References

   [DecSupp]    Building Effective Decision Support Systems.  R.
                Sprague, and E. Carleson.  Prentice Hall, 1982.

   [DirServs]   Understanding and Deploying LDAP Directory Services. T.
                Howes, M. Smith, and G. Good.  MacMillan Technical
                Publications, 1999.

   [DMTF]       Common Information Model (CIM) Schema, version 2.x.
                Distributed Management Task Force, Inc. The components
                of the CIM v2.x schema are available via links on the
                following DMTF web page:
                http://www.dmtf.org/standards/standard_cim.php.

   [RFC1633]    Braden, R., Clark, D. and S. Shenker, "Integrated
                Services in the Internet Architecture: An Overview", RFC
                1633, June 1994.

   [RFC2026]    Bradner, S., "The Internet Standards Process -- Revision
                3", BCP 9, RFC 2026, October 1996.

   [RFC2138]    Rigney, C., Rubens, A., Simpson, W. and S. Willens,
                "Remote Authentication Dial In User Service (RADIUS)",
                RFC 2138, April 1997.

   [RFC2205]    Braden, R., Zhang, L., Berson, S., Herzog, S. and S.
                Jamin, "Resource ReSerVation Protocol (RSVP) -- Version
                1 Functional Specification", RFC 2205, September 1997.





Westerinen, et al.           Informational                     [Page 17]

RFC 3198        Terminology for Policy-Based Management    November 2001


   [RFC2216]    Shenker, S. and J. Wroclawski, "Network Element Service
                Specification Template", September 1997.

   [RFC2474]    Nichols, K., Blake, S., Baker, F. and D. Black,
                "Definition of the Differentiated Services Field (DS
                Field) in the IPv4 and IPv6 Headers", RFC 2474, December
                1998.

   [RFC2475]    Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z.
                and W. Weiss, "An Architecture for Differentiated
                Service", RFC 2475, December 1998.

   [RFC2570]    Case, J., Mundy, R., Partain, D. and B. Stewart,
                "Introduction to Version 3 of the Internet-standard
                Network Management Framework", RFC 2570, April 1999.

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

   [RFC2702]    Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M. and J.
                McManus, "Requirements for Traffic Engineering Over
                MPLS", RFC 2702, September 1999.

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

   [RFC2749]    Herzog, S., Boyle, J., Cohen, R., Durham, D., Rajan, R.
                and A. Sastry, "COPS Usage for RSVP", RFC 2749, January
                2000.

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

   [RFC2828]    Shirey, R., "Internet Security Glossary", FYI 36, RFC
                2828, May 2000.

   [RFC3060]    Moore, B., Ellesson, E., Strassner, J. and A.
                Westerinen, "Policy Core Information Model -- Version 1
                Specification", RFC 3060, February 2001.

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




Westerinen, et al.           Informational                     [Page 18]

RFC 3198        Terminology for Policy-Based Management    November 2001


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

   [UML]        The Unified Modeling Language User Guide.  G. Booch, J.
                Rumbaugh, and I. Jacobson.  Addison-Wesley, 1999.

   [X.500]      Data Communications Networks Directory, Recommendations
                X.500-X.521, Volume VIII - Fascicle VIII.8.  CCITT, IXth
                Plenary Assembly, Melbourne.  November 1988.

8. Authors' Addresses

   Andrea Westerinen
   Cisco Systems, Bldg 20
   725 Alder Drive
   Milpitas, CA 95035

   EMail: andreaw@cisco.com


   John Schnizlein
   Cisco Systems
   9123 Loughran Road
   Fort Washington, MD  20744

   EMail: john.schnizlein@cisco.com


   John Strassner
   Intelliden Corporation
   90 South Cascade Avenue
   Colorado Springs, CO  80903
   Phone:   +1-719-785-0648

   EMail:   john.strassner@intelliden.com


   Mark Scherling
   Xcert International Inc.
   Suite 300
   505 Burrard Street
   Vancouver, BC
   V7X 1M3

   EMail: mscherling@xcert.com




Westerinen, et al.           Informational                     [Page 19]

RFC 3198        Terminology for Policy-Based Management    November 2001


   Bob Quinn
   Celox Networks
   2 Park Central Drive
   Southborough, MA 01772

   EMail: bquinn@celoxnetworks.com


   Jay Perry
   Network Appliance
   495 East Java Drive
   Sunnyvale, CA 94089

   EMail: jay.perry@netapp.com


   Shai Herzog
   PolicyConsulting.com
   200 Clove Rd.
   New Rochelle, NY 10801

   EMail: herzog@PolicyConsulting.com


   An-Ni Huynh
   Lucent Technologies
   2139 Route 35
   Holmdel, NJ 07733


   Mark Carlson
   Sun Microsystems, Inc.
   500 Eldorado Boulevard
   Broomfield, CO 80021

   EMail: mark.carlson@sun.com


   Steve Waldbusser

   Phone: +1-650-948-6500
   Fax:   +1-650-745-0671
   EMail: waldbusser@nextbeacon.com








Westerinen, et al.           Informational                     [Page 20]

RFC 3198        Terminology for Policy-Based Management    November 2001


9. Full Copyright Statement

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

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

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

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

Acknowledgement

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



















Westerinen, et al.           Informational                     [Page 21]