< draft-ietf-policy-core-schema-15.txt		draft-ietf-policy-core-schema-16.txt >
	Policy Framework Working Group J. Strassner		Policy Framework Working Group J. Strassner
	Internet-draft Intelliden Corporation		Internet-draft Intelliden Corporation
	Category: Standards Track E. Ellesson		Category: Standards Track B. Moore
	LongBoard, Inc.
	B. Moore
	IBM Corporation		IBM Corporation
	R. Moats		R. Moats
	Lemur Networks, Inc.		Lemur Networks, Inc.
	August 2002		E. Ellesson
			October 2002
	Policy Core LDAP Schema		Policy Core LDAP Schema
	draft-ietf-policy-core-schema-15.txt		draft-ietf-policy-core-schema-16.txt
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance with all		This document is an Internet-Draft and is in full conformance with all
	provisions of Section 10 of RFC2026.		provisions of Section 10 of RFC2026.
	Internet-Drafts are working documents of the Internet Engineering Task		Internet-Drafts are working documents of the Internet Engineering Task
	Force (IETF), its areas, and its working groups. Note that other		Force (IETF), its areas, and its working groups. Note that other
	groups may also distribute working documents as Internet-Drafts.		groups may also distribute working documents as Internet-Drafts.
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 39 ¶
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html		http://www.ietf.org/shadow.html
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2002). All Rights Reserved.		Copyright (C) The Internet Society (2002). All Rights Reserved.
	Abstract		Abstract
	This document defines a mapping of the Policy Core Information Model [1]		This document defines a mapping of the Policy Core Information Model
	to a form that can be implemented in a directory that uses LDAP as its		to a form that can be implemented in a directory that uses Lightweight
	access protocol. This model defines two hierarchies of object classes:		Directory Access Protocol (LDAP) as its access protocol. This model
	structural classes representing information for representing and		defines two hierarchies of object classes: structural classes
	controlling policy data as specified in RFC3060, and relationship		representing information for representing and controlling policy data
	classes that indicate how instances of the structural classes are		as specified in RFC3060, and relationship classes that indicate how
	related to each other. Classes are also added to the LDAP schema to		instances of the structural classes are related to each other. Classes
	improve the performance of a client's interactions with an LDAP server		are also added to the LDAP schema to improve the performance of a
	when the client is retrieving large amounts of policy-related		client's interactions with an LDAP server when the client is retrieving
	information. These classes exist only to optimize LDAP retrievals:		large amounts of policy-related information. These classes exist only
	there are no classes in the information model that correspond to them.		to optimize LDAP retrievals: there are no classes in the information
			model that correspond to them.
	Table of Contents		Table of Contents
	1. Introduction 3		1. Introduction 3
	2. The Policy Core Information Model 4		2. The Policy Core Information Model 4
	3. Inheritance Hierarchy for the PCLS 5		3. Inheritance Hierarchy for the PCLS 5
	4. General Discussion of Mapping the Information Model to LDAP 6		4. General Discussion of Mapping the Information Model to LDAP 6
	4.1. Summary of Class and Association Mappings 7		4.1. Summary of Class and Association Mappings 7
	4.2. Usage of DIT Content and Structure Rules and Name Forms 9		4.2. Usage of DIT Content and Structure Rules and Name Forms 9
	4.3. Naming Attributes in the PCLS 10		4.3. Naming Attributes in the PCLS 10
	skipping to change at page 3, line 15 ¶		skipping to change at page 3, line 15 ¶
	OIDs for the schema elements in this document have not been assigned.		OIDs for the schema elements in this document have not been assigned.
	This note to be removed by the RFC editor before publication. All uses		This note to be removed by the RFC editor before publication. All uses
	of OIDs are indicated symbolically: for example, IANA-ASSIGNED-OID.1.1		of OIDs are indicated symbolically: for example, IANA-ASSIGNED-OID.1.1
	is a placeholder that will be replaced by a real OID that is assigned by		is a placeholder that will be replaced by a real OID that is assigned by
	IANA before publication.		IANA before publication.
	1. Introduction		1. Introduction
	This document takes as its starting point the object-oriented		This document takes as its starting point the object-oriented
	information model for representing information for representing and		information model for representing information for representing and
	controlling policy data as specified in [1]. LDAP implementers, please		controlling policy data as specified in [1]. Lightweight Directory Access
	note that the use of the term "policy" in this document does not refer		Protocol (LDAP) [2] implementers, please note that the use of the term
	to the use of the term "policy" as defined in X.501 [3]. Rather, the use		"policy" in this document does not refer to the use of the term "policy"
	of the term "policy" throughout this document is defined as follows:		as defined in X.501 [4]. Rather, the use of the term "policy" throughout
			this document is defined as follows:
	Policy is defined as a set of rules to administer, manage, and		Policy is defined as a set of rules to administer, manage, and
	control access to network resources.		control access to network resources.
	This work is currently under joint development in the IETF's Policy		This work is currently under joint development in the IETF's Policy
	Framework working group and in the Policy working group of the		Framework working group and in the Policy working group of the
	Distributed Management Task Force (DMTF). This model defines two		Distributed Management Task Force (DMTF). This model defines two
	hierarchies of object classes: structural classes representing policy		hierarchies of object classes: structural classes representing policy
	information and control of policies, and relationship classes that		information and control of policies, and relationship classes that
	indicate how instances of the structural classes are related to each		indicate how instances of the structural classes are related to each
	other. In general, both of these class hierarchies will need to be		other. In general, both of these class hierarchies will need to be
	mapped to a particular data store.		mapped to a particular data store.
	This draft defines the mapping of these information model classes to a		This draft defines the mapping of these information model classes to a
	directory that uses LDAPv3 as its access protocol. Two types of		directory that uses LDAP as its access protocol. Two types of
	mappings are involved:		mappings are involved:
	- For the structural classes in the information model, the mapping is		- For the structural classes in the information model, the mapping is
	basically one-for-one: information model classes map to LDAP		basically one-for-one: information model classes map to LDAP
	classes, information model properties map to LDAP attributes.		classes, information model properties map to LDAP attributes.
	- For the relationship classes in the information model, different		- For the relationship classes in the information model, different
	mappings are possible. In this document, the PCIM's relationship		mappings are possible. In this document, the Policy Core Information
	classes and their properties are mapped in three ways: to LDAP		Model's (PCIM's) relationship classes and their properties are mapped
	auxiliary classes, to attributes representing DN references, and		in three ways: to LDAP auxiliary classes, to attributes representing
	to superior-subordinate relationships in the Directory Information		distinguished name (DN) references, and to superior-subordinate
	Tree (DIT).		relationships in the Directory Information Tree (DIT).
	Implementations that use an LDAP directory as their policy repository		Implementations that use an LDAP directory as their policy repository
	and want to implement policy information according to RFC3060 [1] SHALL		and want to implement policy information according to RFC3060 [1] SHALL
	use the LDAP schema defined in this document, or a schema that		use the LDAP schema defined in this document, or a schema that
	subclasses from the schema defined in this document. The use of the		subclasses from the schema defined in this document. The use of the
	information model defined in reference [1] as the starting point		information model defined in reference [1] as the starting point
	enables the inheritance and the relationship class hierarchies to be		enables the inheritance and the relationship class hierarchies to be
	extensible, such that other types of policy repositories, such as		extensible, such that other types of policy repositories, such as
	relational databases, can also use this information.		relational databases, can also use this information.
	skipping to change at page 4, line 47 ¶		skipping to change at page 4, line 47 ¶
	schema includes two classes (pcimSubtreesPtrAuxClass and		schema includes two classes (pcimSubtreesPtrAuxClass and
	pcimElementAuxClass) for optimizing LDAP retrievals. In all, the schema		pcimElementAuxClass) for optimizing LDAP retrievals. In all, the schema
	contains 23 classes.		contains 23 classes.
	Within the context of this document, the term "PCLS" (Policy Core LDAP		Within the context of this document, the term "PCLS" (Policy Core LDAP
	Schema) is used to refer to the LDAP class definitions that this		Schema) is used to refer to the LDAP class definitions that this
	document contains. The term "PCIM" refers to classes defined in [1].		document contains. The term "PCIM" refers to classes defined in [1].
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in RFC 2119 [9].		document are to be interpreted as described in RFC 2119 [10].
	2. The Policy Core Information Model		2. The Policy Core Information Model
	This document contains an LDAP schema representing the classes defined		This document contains an LDAP schema representing the classes defined
	in the companion document "Policy Core Information Model -- Version 1		in the companion document "Policy Core Information Model -- Version 1
	Specification" [1]. Other documents may subsequently be produced, with		Specification" [1]. Other documents may subsequently be produced, with
	mappings of this same PCIM to other storage technologies. Since the		mappings of this same PCIM to other storage technologies. Since the
	detailed semantics of the PCIM classes appear only in [1], that document		detailed semantics of the PCIM classes appear only in [1], that document
	is a prerequisite for reading and understanding this document.		is a prerequisite for reading and understanding this document.
	skipping to change at page 9, line 12 ¶		skipping to change at page 9, line 12 ¶
	conditions and policy actions in an LDAP directory. This topic is		conditions and policy actions in an LDAP directory. This topic is
	discussed in Section 4.4 below.		discussed in Section 4.4 below.
	4.2 Usage of DIT Content and Structure Rules and Name Forms		4.2 Usage of DIT Content and Structure Rules and Name Forms
	There are three powerful tools that can be used to help define schemata.		There are three powerful tools that can be used to help define schemata.
	The first, DIT content rules, is a way of defining the content of an		The first, DIT content rules, is a way of defining the content of an
	entry for a structural object class. It can be used to specify the		entry for a structural object class. It can be used to specify the
	following characteristics of the entry:		following characteristics of the entry:
	- additional mandatory attributes that the entries MUST contain		- additional mandatory attributes that the entries are required to
	- additional optional attributes that the entries MAY contain		contain
			- additional optional attributes the entries are allowed to contain
	- the set of additional auxiliary object classes that these entries		- the set of additional auxiliary object classes that these entries
	MAY be members of		are allowed to be members of
	- any optional attributes from the structural and auxiliary object		- any optional attributes from the structural and auxiliary object
	class definitions that the entries MUST NOT contain.		class definitions that the entries are required to preclude
	DIT content rules are NOT mandatory for any structural object class.		DIT content rules are NOT mandatory for any structural object class.
	A DIT structure rule, together with a name form, controls the placement		A DIT structure rule, together with a name form, controls the placement
	and naming of an entry within the scope of a subschema. Name forms		and naming of an entry within the scope of a subschema. Name forms
	define which attribute type(s) MUST and MAY be used in forming the		define which attribute type(s) are required and are allowed to be used in
	Relative Distinguished Names (RDNs) of entries. DIT structure rules		forming the Relative Distinguished Names (RDNs) of entries. DIT structure
	specify which entries MAY be superior to other entries, and hence		rules specify which entries are allowed to be superior to other entries,
	control the way that RDNs are added together to make DNs.		and hence control the way that RDNs are added together to make DNs.
	A name form specifies the following:		A name form specifies the following:
	- the structural object class of the entries named by this name form		- the structural object class of the entries named by this name form
	- attributes that MUST be used in forming the RDNs of these entries		- attributes that are required to be used in forming the RDNs of these
	- attributes that MAY be used in forming the RDNs of these entries		entries
			- attributes that are allowed to be used in forming the RDNs of these
			entries
	- an object identifier to uniquely identify this name form		- an object identifier to uniquely identify this name form
	Note that name forms can only be specified for structural object		Note that name forms can only be specified for structural object
	classes. However, every entry in the DIT must have a name form		classes. However, every entry in the DIT must have a name form
	controlling it.		controlling it.
	Unfortunately, current LDAP servers vary quite a lot in their support of		Unfortunately, current LDAP servers vary quite a lot in their support of
	these features. There are also three crucial implementation points that		these features. There are also three crucial implementation points that
	must be followed. First, X.500 use of structure rules requires that a		must be followed. First, X.500 use of structure rules requires that a
	structural object class with no superior structure rule be a subschema		structural object class with no superior structure rule be a subschema
	skipping to change at page 10, line 34 ¶		skipping to change at page 10, line 34 ¶
	- The LDAP attribute cn (corresponding to X.500's commonName) is		- The LDAP attribute cn (corresponding to X.500's commonName) is
	included as a MAY attribute in the abstract class pcimPolicy, and		included as a MAY attribute in the abstract class pcimPolicy, and
	thus by inheritance in all of its subclasses. In X.500, commonName		thus by inheritance in all of its subclasses. In X.500, commonName
	typically functions as an RDN attribute, for naming instances of		typically functions as an RDN attribute, for naming instances of
	many classes (e.g., X.500's person class).		many classes (e.g., X.500's person class).
	- A special attribute is provided for implementations that expect to		- A special attribute is provided for implementations that expect to
	map between native CIM and LDAP representations of policy		map between native CIM and LDAP representations of policy
	information. This attribute, called orderedCimKeys, is defined in		information. This attribute, called orderedCimKeys, is defined in
	the class dlm1ManagedElement [5]. The value of this attribute is		the class dlm1ManagedElement [6]. The value of this attribute is
	derived algorithmically from values that are already present in a		derived algorithmically from values that are already present in a
	CIM policy instance. The normative reference for this algorithm is		CIM policy instance. The normative reference for this algorithm is
	contained in [5]. See the appendix of this document for a		contained in [6]. See the appendix of this document for a
	description of the algorithm.		description of the algorithm.
	Since any of these naming attributes MAY be used for naming an instance		Since any of these naming attributes MAY be used for naming an instance
	of a PCLS class, implementations MUST be able to accommodate instances		of a PCLS class, implementations MUST be able to accommodate instances
	named in any of these ways.		named in any of these ways.
	Note that it is recommended that two or more of these attributes SHOULD		Note that it is recommended that two or more of these attributes SHOULD
	NOT be used together to form a multi-part RDN, since support for multi-		NOT be used together to form a multi-part RDN, since support for multi-
	part RDNs is limited among existing directory implementations.		part RDNs is limited among existing directory implementations.
	skipping to change at page 13, line 40 ¶		skipping to change at page 13, line 40 ¶
	other entries, with one exception: a policy rule may reference its		other entries, with one exception: a policy rule may reference its
	validity periods with the pcimRuleValidityPeriodList attribute, but have		validity periods with the pcimRuleValidityPeriodList attribute, but have
	its other conditions attached to itself.		its other conditions attached to itself.
	The tradeoffs between simple and complex policy rules are between the		The tradeoffs between simple and complex policy rules are between the
	efficiency of simple rules and the flexibility and greater potential for		efficiency of simple rules and the flexibility and greater potential for
	reuse of complex rules. With a simple policy rule, the semantic options		reuse of complex rules. With a simple policy rule, the semantic options
	are limited:		are limited:
	- All conditions are ANDed together. This combination can be		- All conditions are ANDed together. This combination can be
	represented in two ways in the DNF / CNF (please see [1] for		represented in two ways in the Disjunctive Normal Form (DNF)/
	definitions of these terms) expressions characteristic of policy		Conjunctive Normal Form (CNF) (please see [1] for definitions of
	conditions: as a DNF expression with a single AND group, or as		these terms) expressions characteristic of policy conditions: as a
	a CNF expression with multiple single-condition OR groups. The		DNF expression with a single AND group, or as a CNF expression with
	first of these is arbitrarily chosen as the representation for		multiple single-condition OR groups. The first of these is
	the ANDed conditions in a simple policy rule.		arbitrarily chosen as the representation for the ANDed conditions
			in a simple policy rule.
	- If multiple actions are included, no order can be specified for		- If multiple actions are included, no order can be specified for
	them.		them.
	If a policy administrator needs to combine conditions in some other way,		If a policy administrator needs to combine conditions in some other way,
	or if there is a set of actions that must be ordered, then the only		or if there is a set of actions that must be ordered, then the only
	option is to use a complex policy rule.		option is to use a complex policy rule.
	Finally, Figure 6 illustrates the same policy rule Rule1, but this time		Finally, Figure 6 illustrates the same policy rule Rule1, but this time
	its condition and action are reusable. The association classes CA and		its condition and action are reusable. The association classes CA and
	skipping to change at page 15, line 7 ¶		skipping to change at page 15, line 7 ¶
	Among these semantics are those of representing either a rule-specific		Among these semantics are those of representing either a rule-specific
	or a reusable policy condition or policy action.		or a reusable policy condition or policy action.
	In order to preserve the ability to represent a rule-specific or a		In order to preserve the ability to represent a rule-specific or a
	reusable condition or action, as well as a simple policy rule, all the		reusable condition or action, as well as a simple policy rule, all the
	subclasses of pcimConditionAuxClass and pcimActionAuxClass MUST also be		subclasses of pcimConditionAuxClass and pcimActionAuxClass MUST also be
	auxiliary classes.		auxiliary classes.
	4.5. Location and Retrieval of Policy Objects in the Directory		4.5. Location and Retrieval of Policy Objects in the Directory
	When a PDP goes to an LDAP directory to retrieve the policy object		When a Policy Decision Point (PDP) goes to an LDAP directory to retrieve
	instances relevant to the PEPs it serves, it is faced with two related		the policy object instances relevant to the Policy Enforcement Points
	problems:		(PEPs) it serves, it is faced with two related problems:
	- How does it locate and retrieve the directory entries that apply to		- How does it locate and retrieve the directory entries that apply to
	its PEPs? These entries may include instances of the PCLS classes,		its PEPs? These entries may include instances of the PCLS classes,
	instances of domain-specific subclasses of these classes, and		instances of domain-specific subclasses of these classes, and
	instances of other classes modeling such resources as user groups,		instances of other classes modeling such resources as user groups,
	interfaces, and address ranges.		interfaces, and address ranges.
	- How does it retrieve the directory entries it needs in an efficient		- How does it retrieve the directory entries it needs in an efficient
	manner, so that retrieval of policy information from the directory		manner, so that retrieval of policy information from the directory
	does not become a roadblock to scalability? There are two facets to		does not become a roadblock to scalability? There are two facets to
	skipping to change at page 18, line 18 ¶		skipping to change at page 18, line 18 ¶
	directly from the information model to an LDAP representation are		directly from the information model to an LDAP representation are
	detailed in [1]. Consequently, all that this document presents for		detailed in [1]. Consequently, all that this document presents for
	these classes is the specification for how to do the mapping from the		these classes is the specification for how to do the mapping from the
	information model (which is independent of repository type and access		information model (which is independent of repository type and access
	protocol) to a form that can be accessed using LDAP. Remember that some		protocol) to a form that can be accessed using LDAP. Remember that some
	new classes needed to be created (that were not part of [1]) to		new classes needed to be created (that were not part of [1]) to
	implement the LDAP mapping. These new LDAP-only classes are fully		implement the LDAP mapping. These new LDAP-only classes are fully
	documented in this document.		documented in this document.
	The formal language for specifying the classes, attributes, and DIT		The formal language for specifying the classes, attributes, and DIT
	structure and content rules is that defined in reference [2]. If your		structure and content rules is that defined in reference [3]. If your
	implementation does not support auxiliary class inheritance, you will		implementation does not support auxiliary class inheritance, you will
	have to list auxiliary classes in content rules explicitly or define		have to list auxiliary classes in content rules explicitly or define
	them in another (implementation-specific) way.		them in another (implementation-specific) way.
	The following notes apply to this section in its entirety.		The following notes apply to this section in its entirety.
	Note 1: in the following definitions, the class and attribute		Note 1: in the following definitions, the class and attribute
	definitions follow RFC2252 [2] but they are line-wrapped to enhance		definitions follow RFC2252 [3] but they are line-wrapped to enhance
	human readability.		human readability.
	Note 2: where applicable, the possibilities for specifying DIT structure		Note 2: where applicable, the possibilities for specifying DIT structure
	and content rules are noted. However, care must be taken in specifying		and content rules are noted. However, care must be taken in specifying
	DIT structure rules. This is because X.501 [3] states that an entry may		DIT structure rules. This is because X.501 [4] states that an entry may
	only exist in the DIT as a subordinate to another superior entry (the		only exist in the DIT as a subordinate to another superior entry (the
	superior) if a DIT structure rule exists in the governing subschema		superior) if a DIT structure rule exists in the governing subschema
	which:		which:
	1) indicates a name form for the structural object class of the		1) indicates a name form for the structural object class of the
	subordinate entry, and		subordinate entry, and
	2) either includes the entry's superior structure rule as a possible		2) either includes the entry's superior structure rule as a possible
	superior structure rule, or		superior structure rule, or
	3) does not specify a superior structure rule.		3) does not specify a superior structure rule.
	skipping to change at page 19, line 18 ¶		skipping to change at page 19, line 18 ¶
	role-combination [1]).		role-combination [1]).
	Another strategy would be for the PDP to use only equality filters. This		Another strategy would be for the PDP to use only equality filters. This
	approach eliminates the extraneous replies, but it requires the PDP to		approach eliminates the extraneous replies, but it requires the PDP to
	explicitly build the desired role-combinations itself. It also requires		explicitly build the desired role-combinations itself. It also requires
	extra queries. Note that this approach is practical only because the		extra queries. Note that this approach is practical only because the
	role names in a role combination are required to appear in alphabetical		role names in a role combination are required to appear in alphabetical
	order.		order.
	Note 4: in the following definitions, note that all LDAP matching rules		Note 4: in the following definitions, note that all LDAP matching rules
	are defined in [2] and in [8]. The corresponding X.500 matching rules		are defined in [3] and in [9]. The corresponding X.500 matching rules
	are defined in [7].		are defined in [8].
	Note 5: some of the following attribute definitions specify additional		Note 5: some of the following attribute definitions specify additional
	constraints on various data types (e.g., this integer has values that are valid		constraints on various data types (e.g., this integer has values that are valid
	from 1..10). Text has been added to instruct servers and applications what to		from 1..10). Text has been added to instruct servers and applications what to
	do if a value outside of this range is encountered.		do if a value outside of this range is encountered.
	In all cases, if a constraint is violated, then the policy rule SHOULD be		In all cases, if a constraint is violated, then the policy rule SHOULD be
	treated as being disabled, meaning that execution of the policy rule SHOULD be		treated as being disabled, meaning that execution of the policy rule SHOULD be
	stopped.		stopped.
	5.1. The Abstract Class pcimPolicy		5.1. The Abstract Class pcimPolicy
	The abstract class pcimPolicy is a direct mapping of the abstract class		The abstract class pcimPolicy is a direct mapping of the abstract class
	Policy from the PCIM. The class value "pcimPolicy" is also used as the		Policy from the PCIM. The class value "pcimPolicy" is also used as the
	mechanism for identifying policy-related instances in the Directory		mechanism for identifying policy-related instances in the Directory
	Information Tree. An instance of any class may be "tagged" with this		Information Tree. An instance of any class may be "tagged" with this
	class value by attaching to it the auxiliary class pcimElementAuxClass.		class value by attaching to it the auxiliary class pcimElementAuxClass.
	Since pcimPolicy is derived from the class dlm1ManagedElement defined in		Since pcimPolicy is derived from the class dlm1ManagedElement defined in
	reference [5], this specification has a normative dependency on that		reference [6], this specification has a normative dependency on that
	element of reference [5].		element of reference [6].
	The class definition is as follows:		The class definition is as follows:
	( IANA-ASSIGNED-OID.1.1 NAME 'pcimPolicy'		( IANA-ASSIGNED-OID.1.1 NAME 'pcimPolicy'
	DESC 'An abstract class that is the base class for all classes		DESC 'An abstract class that is the base class for all classes
	that describe policy-related instances.'		that describe policy-related instances.'
	SUP dlm1ManagedElement		SUP dlm1ManagedElement
	ABSTRACT		ABSTRACT
	MAY ( cn $ dlmCaption $ dlmDescription $ orderedCimKeys $		MAY ( cn $ dlmCaption $ dlmDescription $ orderedCimKeys $
	pcimKeywords )		pcimKeywords )
	)		)
	The attribute cn is defined in RFC 2256 [6]. The dlmCaption,		The attribute cn is defined in RFC 2256 [7]. The dlmCaption,
	dlmDescription, and orderedCimKeys attributes are defined in [5].		dlmDescription, and orderedCimKeys attributes are defined in [6].
	The pcimKeywords attribute is a multi-valued attribute that contains a		The pcimKeywords attribute is a multi-valued attribute that contains a
	set of keywords to assist directory clients in locating the policy		set of keywords to assist directory clients in locating the policy
	objects identified by these keywords. It is defined as follows:		objects identified by these keywords. It is defined as follows:
	( IANA-ASSIGNED-OID.2.3 NAME 'pcimKeywords'		( IANA-ASSIGNED-OID.2.3 NAME 'pcimKeywords'
	DESC 'A set of keywords to assist directory clients in		DESC 'A set of keywords to assist directory clients in
	locating the policy objects applicable to them.'		locating the policy objects applicable to them.'
	EQUALITY caseIgnoreMatch		EQUALITY caseIgnoreMatch
	ORDERING caseIgnoreOrderingMatch		ORDERING caseIgnoreOrderingMatch
	skipping to change at page 41, line 55 ¶		skipping to change at page 41, line 55 ¶
	)		)
	5.14. The Three Policy Repository Classes		5.14. The Three Policy Repository Classes
	These classes provide a container for reusable policy information, such		These classes provide a container for reusable policy information, such
	as reusable policy conditions and/or reusable policy actions. This		as reusable policy conditions and/or reusable policy actions. This
	document is concerned with mapping just the properties that appear in		document is concerned with mapping just the properties that appear in
	these classes. Conceptually, this may be thought of as a special		these classes. Conceptually, this may be thought of as a special
	location in the DIT where policy information may reside. Since		location in the DIT where policy information may reside. Since
	pcimRepository is derived from the class dlm1AdminDomain defined in		pcimRepository is derived from the class dlm1AdminDomain defined in
	reference [5], this specification has a normative dependency on that		reference [6], this specification has a normative dependency on that
	element of reference [5] (as well as on its entire derivation		element of reference [6] (as well as on its entire derivation
	hierarchy, which also appears in reference [5]). To maximize		hierarchy, which also appears in reference [6]). To maximize
	flexibility, the pcimRepository class is defined as abstract. A		flexibility, the pcimRepository class is defined as abstract. A
	subclass pcimRepositoryAuxClass provides for auxiliary attachment to		subclass pcimRepositoryAuxClass provides for auxiliary attachment to
	another entry, while a structural subclass pcimRepositoryInstance is		another entry, while a structural subclass pcimRepositoryInstance is
	available to represent a policy repository as a standalone entry.		available to represent a policy repository as a standalone entry.
	The definition for the pcimRepository class is as follows:		The definition for the pcimRepository class is as follows:
	( IANA-ASSIGNED-OID.1.18 NAME 'pcimRepository'		( IANA-ASSIGNED-OID.1.18 NAME 'pcimRepository'
	DESC 'A container for reusable policy information.'		DESC 'A container for reusable policy information.'
	SUP dlm1AdminDomain		SUP dlm1AdminDomain
	skipping to change at page 49, line 18 ¶		skipping to change at page 49, line 18 ¶
	valuable) resources. It may be the case that these values must not be		valuable) resources. It may be the case that these values must not be
	disclosed to, or manipulated by, unauthorized parties.		disclosed to, or manipulated by, unauthorized parties.
	Since this document forms the basis for the representation of a policy		Since this document forms the basis for the representation of a policy
	data model in a specific format (an LDAP-accessible directory), it is		data model in a specific format (an LDAP-accessible directory), it is
	herein appropriate to reference the data model-specific tools and		herein appropriate to reference the data model-specific tools and
	mechanisms that are available for achieving the authentication and		mechanisms that are available for achieving the authentication and
	authorization implicit in a requirement that restricts read and/or read-		authorization implicit in a requirement that restricts read and/or read-
	write access to these values stored in a directory.		write access to these values stored in a directory.
			General LDAP security considerations apply, as documented in RFC3377 [2].
	LDAP-specific authentication and authorization tools and mechanisms are		LDAP-specific authentication and authorization tools and mechanisms are
	found in the following standards track documents, which are appropriate		found in the following standards track documents, which are appropriate
	for application to the management of security applied to policy data		for application to the management of security applied to policy data
	models stored in an LDAP-accessible directory:		models stored in an LDAP-accessible directory:
	- RFC 2829 (Authentication Methods for LDAP)		- RFC 2829 (Authentication Methods for LDAP)
	- RFC 2830 (Lightweight Directory Access Protocol (v3): Extension		- RFC 2830 (Lightweight Directory Access Protocol (v3): Extension
	for Transport Layer Security)		for Transport Layer Security)
	Any identified security requirements that are not dealt with in the		Any identified security requirements that are not dealt with in the
	appropriate discipline-specific information model documents, or in this		appropriate discipline-specific information model documents, or in this
	document, MUST be dealt with in the derivative data model documents		document, MUST be dealt with in the derivative data model documents
	which are specific to each discipline.		which are specific to each discipline.
	8. IANA Considerations		8. IANA Considerations
			Reference RFC 3383 "Internet Assigned Numbers Authority (IANA)
			Considerations for the Lightweight Directory Access Protocol (LDAP)"[16].
	8.1. Object Identifiers		8.1. Object Identifiers
	It is requested that IANA register an LDAP Object Identifer		It is requested that IANA register an LDAP Object Identifer
	for use in this technical specification according to the		for use in this technical specification according to the
	following template:		following template:
	Subject: Request for LDAP OID Registration		Subject: Request for LDAP OID Registration
	Person & email address to contact for further information:		Person & email address to contact for further information:
	Bob Moore (remoore@us.ibm.com)		Bob Moore (remoore@us.ibm.com)
	Specification: RFC XXXX		Specification: RFC XXXX
	skipping to change at page 50, line 25 ¶		skipping to change at page 50, line 25 ¶
	Bob Moore (remoore@us.ibm.com)		Bob Moore (remoore@us.ibm.com)
	Usage: see comment		Usage: see comment
	Specification: RFC XXXX		Specification: RFC XXXX
	Author/Change Controller: IESG		Author/Change Controller: IESG
	Comments:		Comments:
	The following descriptors should be added:		The following descriptors should be added:
	NAME Type OID		NAME Type OID
	-------------- ---- ------------		-------------- ---- ------------
	pcimPolicy' O IANA-ASSIGNED-OID.1.1		pcimPolicy O IANA-ASSIGNED-OID.1.1
	pcimGroup O IANA-ASSIGNED-OID.1.2		pcimGroup O IANA-ASSIGNED-OID.1.2
	pcimGroupAuxClass O IANA-ASSIGNED-OID.1.3		pcimGroupAuxClass O IANA-ASSIGNED-OID.1.3
	pcimGroupInstance O IANA-ASSIGNED-OID.1.4		pcimGroupInstance O IANA-ASSIGNED-OID.1.4
	pcimRule O IANA-ASSIGNED-OID.1.5		pcimRule O IANA-ASSIGNED-OID.1.5
	pcimRuleAuxClass O IANA-ASSIGNED-OID.1.6		pcimRuleAuxClass O IANA-ASSIGNED-OID.1.6
	pcimRuleInstance O IANA-ASSIGNED-OID.1.7		pcimRuleInstance O IANA-ASSIGNED-OID.1.7
	pcimRuleConditionAssociation O IANA-ASSIGNED-OID.1.8		pcimRuleConditionAssociation O IANA-ASSIGNED-OID.1.8
	pcimRuleValidityAssociation O IANA-ASSIGNED-OID.1.9		pcimRuleValidityAssociation O IANA-ASSIGNED-OID.1.9
	pcimRuleActionAssociation O IANA-ASSIGNED-OID.1.10		pcimRuleActionAssociation O IANA-ASSIGNED-OID.1.10
	pcimConditionAuxClass O IANA-ASSIGNED-OID.1.11		pcimConditionAuxClass O IANA-ASSIGNED-OID.1.11
	skipping to change at page 53, line 11 ¶		skipping to change at page 53, line 11 ¶
	groups. We would especially like to thank Lee Rafalow, Glenn Waters,		groups. We would especially like to thank Lee Rafalow, Glenn Waters,
	David Black, Michael Richardson, Mark Stevens, David Jones, Hugh Mahon,		David Black, Michael Richardson, Mark Stevens, David Jones, Hugh Mahon,
	Yoram Snir, and Yoram Ramberg for their helpful comments.		Yoram Snir, and Yoram Ramberg for their helpful comments.
	11. Normative References		11. Normative References
	[1] Moore, B., and E. Ellesson, J. Strassner, A. Westerinen "Policy		[1] Moore, B., and E. Ellesson, J. Strassner, A. Westerinen "Policy
	Core Information Model -- Version 1 Specification", RFC 3060,		Core Information Model -- Version 1 Specification", RFC 3060,
	February 2001.		February 2001.
	[2] Wahl, M., and A. Coulbeck, T. Howes, S. Kille, "Lightweight		[2] Hodges, J., and Morgan R., "Lightweight Directory Access Protocol
			(v3): Technical Specification", RFC3377, September 2002.
			[3] Wahl, M., and A. Coulbeck, T. Howes, S. Kille, "Lightweight
	Directory Access Protocol (v3): Attribute Syntax Definitions", RFC		Directory Access Protocol (v3): Attribute Syntax Definitions", RFC
	2252, December 1997.		2252, December 1997.
	[3] The Directory: Models. ITU-T Recommendation X.501, 2001.		[4] The Directory: Models. ITU-T Recommendation X.501, 2001.
	[4] Distributed Management Task Force, Inc., "Common Information		[5] Distributed Management Task Force, Inc., "Common Information
	Model (CIM) Specification", Version 2.2, June 14, 1999. This		Model (CIM) Specification", Version 2.2, June 14, 1999. This
	document is available on the following DMTF web page:		document is available on the following DMTF web page:
	http://www.dmtf.org/standards/documents/CIM/DSP0004.pdf		http://www.dmtf.org/standards/documents/CIM/DSP0004.pdf
	[5] Distributed Management Task Force, Inc., "DMTF LDAP Schema for the		[6] Distributed Management Task Force, Inc., "DMTF LDAP Schema for the
	CIM v2.5 Core Information Model", April 15, 2002. This document		CIM v2.5 Core Information Model", April 15, 2002. This document
	is available on the following DMTF web page:		is available on the following DMTF web page:
	http://www.dmtf.org/standards/documents/DEN/DSP0123.pdf		http://www.dmtf.org/standards/documents/DEN/DSP0123.pdf
	[6] Wahl, M., "A Summary of the X.500(96) User Schema for use with		[7] Wahl, M., "A Summary of the X.500(96) User Schema for use with
	LDAPv3", RFC 2256, December 1997.		LDAPv3", RFC 2256, December 1997.
	[7] The Directory: Selected Attribute Types. ITU-T Recommendation		[8] The Directory: Selected Attribute Types. ITU-T Recommendation
	X.520, 2001.		X.520, 2001.
	[8] K. Zeilenga, ed., "LDAPv3: A Collection of User Schema",		[9] K. Zeilenga, ed., "LDAPv3: A Collection of User Schema",
	<draft-zeilenga-ldap-user-schema-06.txt>, May 2002.		<draft-zeilenga-ldap-user-schema-06.txt>, May 2002.
	12. Informative References		12. Informative References
	[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[10] Bradner, S., "Key words for use in RFCs to Indicate Requirement
	Levels", BCP 14, RFC 2119, March 1997.		Levels", BCP 14, RFC 2119, March 1997.
	[10] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF		[11] Hovey, R., and S. Bradner, "The Organizations Involved in the IETF
	Standards Process", BCP 11, RFC 2028, October 1996.		Standards Process", BCP 11, RFC 2028, October 1996.
	[11] Strassner, J., policy architecture BOF presentation, 42nd IETF		[12] Strassner, J., policy architecture BOF presentation, 42nd IETF
	Meeting, Chicago, Illinois, October 1998. Minutes of this BOF are		Meeting, Chicago, Illinois, October 1998. Minutes of this BOF are
	available at the following location:		available at the following location:
	http://www.ietf.org/proceedings/98aug/index.html.		http://www.ietf.org/proceedings/98aug/index.html.
	[12] DMTF web site, http://www.dmtf.org.
	[13] Yavatkar, R., and R. Guerin, D. Pendarakis, "A Framework for		[13] Yavatkar, R., and R. Guerin, D. Pendarakis, "A Framework for
	Policy-based Admission Control", RFC 2753, January 2000.		Policy-based Admission Control", RFC 2753, January 2000.
	[14] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, "Authentication		[14] M. Wahl, H. Alvestrand, J. Hodges, R. Morgan, "Authentication
	Methods for LDAP", RFC 2829, May 2000		Methods for LDAP", RFC 2829, May 2000
	[15] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory Access		[15] J. Hodges, R. Morgan, M. Wahl, "Lightweight Directory Access
	Protocol (v3): Extension for Transport Layer Security", RFC 2830,		Protocol (v3): Extension for Transport Layer Security", RFC 2830,
	May 2000.		May 2000.
			[16] Zeilenga, K., "Internet Assigned Numbers Authority (IANA)
			Considerations for the Lightweight Directory Access Protocol
			(LDAP)", BCP 64, RFC 3383, September 2002.
	13. Authors' Addresses		13. Authors' Addresses
	John Strassner		John Strassner
	Intelliden Corporation		Intelliden Corporation
	90 South Cascade Avenue		90 South Cascade Avenue
	Colorado Springs, CO 80903		Colorado Springs, CO 80903
	Phone: +1.719.785.0648		Phone: +1.719.785.0648
	Fax: +1.719.785.0644		Fax: +1.719.785.0644
	E-mail: john.strassner@intelliden.com		E-mail: john.strassner@intelliden.com
	Ed Ellesson
	3026 Carriage Trail
	Hillsborough, NC 27278
	Phone: +1 919-361-3230
	E-mail: ellesson@mindspring.com
	Bob Moore		Bob Moore
	IBM Corporation		IBM Corporation
	P. O. Box 12195, BRQA/B501/E116		P. O. Box 12195, BRQA/B501/E116
	3039 Cornwallis Rd.		3039 Cornwallis Rd.
	Research Triangle Park, NC 27709-2195		Research Triangle Park, NC 27709-2195
	Phone: +1 919-254-4436		Phone: +1 919-254-4436
	Fax: +1 919-254-6243		Fax: +1 919-254-6243
	E-mail: remoore@us.ibm.com		E-mail: remoore@us.ibm.com
	Ryan Moats		Ryan Moats
	Lemur Networks, Inc.		Lemur Networks, Inc.
	15621 Drexel Circle		15621 Drexel Circle
	Omaha, NE 68135		Omaha, NE 68135
	Phone: +1-402-894-9456		Phone: +1-402-894-9456
	E-mail: rmoats@lemurnetworks.net		E-mail: rmoats@lemurnetworks.net
			Ed Ellesson
			3026 Carriage Trail
			Hillsborough, NC 27278
			Phone: +1 919-644-3977
			E-mail: ellesson@mindspring.com
	14. Full Copyright Statement		14. Full Copyright Statement
	Copyright (C) The Internet Society (2002). All Rights Reserved.		Copyright (C) The Internet Society (2002). All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it or		others, and derivative works that comment on or otherwise explain it or
	assist in its implementation may be prepared, copied, published and		assist in its implementation may be prepared, copied, published and
	distributed, in whole or in part, without restriction of any kind,		distributed, in whole or in part, without restriction of any kind,
	provided that the above copyright notice and this paragraph are included		provided that the above copyright notice and this paragraph are included
	on all such copies and derivative works. However, this document itself		on all such copies and derivative works. However, this document itself
	skipping to change at page 57, line 22 ¶		skipping to change at page 57, line 22 ¶
	identified by the values of their key properties, and each combination		identified by the values of their key properties, and each combination
	of key values must be unique. A limited form of hierarchical naming is		of key values must be unique. A limited form of hierarchical naming is
	available in CIM, however, by using weak associations: since a weak		available in CIM, however, by using weak associations: since a weak
	association involves propagation of key properties and their values from		association involves propagation of key properties and their values from
	the superior object to the subordinate one, the subordinate object can		the superior object to the subordinate one, the subordinate object can
	be thought of as being named "under" the superior object. Once they		be thought of as being named "under" the superior object. Once they
	have been propagated, however, propagated key properties and their		have been propagated, however, propagated key properties and their
	values function in exactly the same way that native key properties and		values function in exactly the same way that native key properties and
	their values do in identifying a CIM instance.		their values do in identifying a CIM instance.
	The CIM mapping document [5] introduces a special attribute,		The CIM mapping document [6] introduces a special attribute,
	orderedCIMKeys, to help map from the CIM_ManagedElement class to the		orderedCIMKeys, to help map from the CIM_ManagedElement class to the
	LDAP class dlm1ManagedElement. This attribute SHOULD only be used in an		LDAP class dlm1ManagedElement. This attribute SHOULD only be used in an
	environment where it is necessary to map between an LDAP-accessible		environment where it is necessary to map between an LDAP-accessible
	directory and a CIM repository. For an LDAP environment, other LDAP		directory and a CIM repository. For an LDAP environment, other LDAP
	naming attributes are defined (i.e., cn and a class-specific naming		naming attributes are defined (i.e., cn and a class-specific naming
	attribute) that SHOULD be used instead.		attribute) that SHOULD be used instead.
	The role of orderedCIMKeys is to represent the information necessary to		The role of orderedCIMKeys is to represent the information necessary to
	correlate an entry in an LDAP-accessible directory with an instance in a		correlate an entry in an LDAP-accessible directory with an instance in a
	CIM name space. Depending on how naming of CIM-related entries is		CIM name space. Depending on how naming of CIM-related entries is
	skipping to change at page 57, line 56 ¶		skipping to change at page 57, line 56 ¶
	<className>.<key>=<value>[,<key>=<value>]*		<className>.<key>=<value>[,<key>=<value>]*
	where the <key>=<value> elements are ordered by the names of the key		where the <key>=<value> elements are ordered by the names of the key
	properties, according to the collating sequence for US ASCII. The only		properties, according to the collating sequence for US ASCII. The only
	spaces allowed in the DirectoryString are those that fall within a		spaces allowed in the DirectoryString are those that fall within a
	<value> element. As with alphabetizing the key properties, the goal of		<value> element. As with alphabetizing the key properties, the goal of
	suppressing the spaces is once again to make the results of string		suppressing the spaces is once again to make the results of string
	operations predictable.		operations predictable.
	The values of the <value> elements are derived from the various CIM		The values of the <value> elements are derived from the various CIM
	syntaxes according to a grammar specified in [4].		syntaxes according to a grammar specified in [5].
End of changes. 44 change blocks.
	81 lines changed or deleted		94 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/