Subject: PCIM I-D Submitted

From: [email-masked]
Date: Fri, 13 Oct 2000 16:42:03 -0400

A new version of the Policy Core Information Model -- Version 1
Specification <draft-ietf-policy-core-info-model-08.txt>, was submitted
this morning, for posting to the I-D repository, and we have passed this
version on to our Area Advisor, Bert Wijnen, for consideration by the IESG
for advancement to Proposed Standard.   It should show up in the repository
very soon.

Thanks to Bob Moore for editing and submitting this document, and to the
authors of, and contributors to, this and earlier drafts.  This version
incorporates the editorial changes agreed upon in Pittsburgh, and also
includes input from Luis Sanchez, and Russ Mundy, representing the Security
Area, who helped us with the appropriate wording  for Section 10, the
Security Considerations section, as well as input from Harald Alvestrand,
who reviewed our work on behalf of the IESG.  Thank you, Luis, Russ and
Harald.

Follow-on derivative documents will extend and map PCIM into specific
technical domains, and into specific representation technologies.  These
extensions and mappings will affect the nature of what needs to be
documented, and where, with regard to security requirements.  The authors
discussed this with Bert, Luis and Russ, and we all agreed to the following
text.  This completes our effort to address the issues which came up as a
result of last call on this document.

<begin quoted Section 10>

10. Security Considerations

   The Policy Core Information Model (PCIM) presented in this document
   provides an object-oriented model for describing policy information.  It
   provides a basic framework for describing the structure of policy
   information, in a form independent of any specific repository or access
   protocol, for use by an operational system.  PCIM is not intended to
   represent any particular system design or implementation, nor does it
   define a protocol, and as such it does not have any specific security
   requirements.

   However, it should also be noted that certain derivative documents, which
   use PCIM as a base, will need to convey more specific security
   considerations.  In order to communicate the nature of what will be
   expected in these follow-on derivative documents, it is necessary to
   review the reasons that PCIM, as defined in this document, is neither
   implementable, nor representative of any real-world system, as well as
   the nature of the expected follow-on extensions and mappings.

   There are three independent reasons that PCIM, as defined here, is
   neither implementable nor representative of any real-world system:

     1. Its classes are independent of any specific repository that uses
         any specific access protocol. Therefore, its classes are designed
         not to be implemented directly.  PCIM should instead be viewed as a
         schematic that directs how information should be represented,
         independent of any specific model implementation constraints.

     2. Its classes were designed to be independent of any specific policy
         domain. For example, DiffServ and IPSec represent two different
         policy domains. Each document which extends PCIM to one of these
         domains will derive subclasses from the classes and relationships
         defined in PCIM, in order to represent extensions of a generic
         model to cover specific technical domains.

     3. It's an information model, which must be mapped to a specific data
         model (native CIM schema, LDAP schema, MIB, whatever) before it can
         be implemented.  Derivative documents will map the extended
         information models noted in item 2, above, to specific types of
         data model implementations.

   Even though specific security requirements are not appropriate for PCIM,
   specific security requirements MUST be defined for each operational real-
   world application of PCIM.  Just as there will be a wide range of
   operational, real-world systems using PCIM, there will also be a wide
   range of security requirements for these systems.  Some operational,
   real-world systems that are deployed using PCIM may have extensive
   security requirements that impact nearly all classes and subclasses
   utilized by such a system, while other systems' security requirements
   might have very little impact.

   The derivative documents, discussed above, will create the context for
   applying operational, real-world, system-level security requirements
   against the various models which derive from PCIM.

   For example, in some real-world scenarios, the values associated with
   certain properties, within certain instantiated classes, may represent
   information associated with scarce, and/or costly (and therefore
   valuable) resources.  It may be the case that these values must not be
   disclosed to, or manipulated by, unauthorized parties.  As long as the
   derived model remains an information model (as opposed to a data model),
   it is not possible to discuss the data model-specific tools and
   mechanisms that are available for achieving the authentication and
   authorization implicit in a requirement that restricts read and/or read-
   write access to these values.  Therefore, these mechanisms will need to
   be discussed in each of the data models to which the derived information
   models are mapped.  If there are any general security requirements that
   can be identified and can be applied across multiple types of data
   models, it would be appropriate to discuss those at the information model
   level, rather than the data model level.  In any case, any identified
   security requirements that are not dealt with in the information model
   document, MUST be dealt with in the derivative data model documents.

   We can illustrate these points by extending the example from Section 2.
   A real-world system that provides QoS Gold Service to John would likely
   need to provide at least the following security-related capabilities and
   mechanisms (see [12] for definitions of security related terms):

     o Data integrity for the information (e.g. property values and
        instantiated relationships) that specify that John gets QoS Gold
        Service, from the point(s) that the information is entered into the
        system to the point(s) where network components actually provide
        that Service.

     o Authentication and Authorization methods to ensure that only system
        administrators (and not John or other engineers) can remotely
        administer components of the system.

     o An Authentication method to insure that John receives Gold Service,
        and the other members of the engineering group receive Bronze
        Service.

   These are one possible set of requirements associated with an example
   real-world system which delivers Gold Service, and the appropriate place
   to document these would be in some combination of the information model
   and the derivative data models for QoS Policy.  Each of the data models
   would also need to discuss how these requirements are satisfied, using
   the mechanisms typically available to such a data model, given the
   particular technology or set of technologies which it may employ.

<end quoted Section 10>

Ed  and Joel