rfc2768.txt

中、英文RFC文档大全打包下载完全版 .

   The data flow needs to be directly from the collection to the
   execution platform for efficiency.  At the same time, the procedure
   will need access permission to the data set while it is acting on
   behalf of the requestor.  How the authentication is done between the
   remote procedure and the remote data collection entities raises
   significant issues related to transitivity of trust, and will require
   establishment of a trust policy for third-party mechanisms. This is
   exacerbated when a collection of entities, such as is required for
   visualization applications, is involved.



Aiken, et al.                Informational                      [Page 9]

RFC 2768          A Report of a Workshop on Middleware     February 2000


7.0 Policy

   The IETF Policy Framework working group is addressing a policy
   framework definition language, a policy architecture model, policy
   terminology and, specifically, a policy model that can be used for
   signaled as well as provisioned QoS. The policy meta-model links
   high-level business requirements, such as those that can be specified
   in an SLA, to low-level device implementation mechanisms, ranging
   from specific access control and management of services, objects and
   other resources to configuration of mechanisms necessary to provide a
   given service.

   Polices are an integral component of all middleware services, and
   will be found within most middleware services in one form or another.
   Policies are often represented as an "if condition then action"
   tuple. Policies can be both complex and numerous; therefore, policy
   management services must be able to identify and resolve policy
   conflicts.  They also need to support both static (i.e. loaded at
   boot time via a configuration file) and dynamic (i.e. the
   configuration of a policy enforcing device may change based on an
   event) modes.

   A generalized policy management architecture (as suggested by the
   IETF policy architecture draft) includes a policy management service,
   a dedicated policy repository, at least one policy decision point
   (PDP), and at least one policy enforcement point (PEP). The policy
   management service supports the specification, editing, and
   administration of policy, through a graphical user interface as well
   as programmatically. The policy repository provides storage and
   retrieval of policies as well as policy components. These policy
   components contain definitional information, and may be used to build
   more complex policies, or may be used as part of the policy decision
   and/or enforcement process. The PDP (e.g. resource manager, such as a
   bandwidth broker or an intra-domain policy server) is responsible for
   handling events and making decisions based on those events (e.g., at
   time x do y) and updating the PEP configuration appropriately. In
   addition, it may be responsible for providing the initial
   configuration of the PEP. The PEP (e.g., router, firewall or host)
   enforces policy based on the "if condition then action" rule sets it
   has received from the PDP.

   Policy information may be communicated from the PDP to the PEP
   through a variety of protocols, such as COPS or DIAMETER. A proxy may
   be used to translate information contained in these protocols to
   forms that devices can consume (e.g., command line interface commands
   or SNMP sets). Additional information, contained in Policy
   Information Bases (PIBs), may also be used to translate from an
   intermediate specification to specific functions and capabilities of



Aiken, et al.                Informational                     [Page 10]

RFC 2768          A Report of a Workshop on Middleware     February 2000


   a device. For example, a policy may specify "if source IP address is
   198.10.20.132, then remark traffic with a DSCP of 5". The PIB would
   be used to translate the device-specific meaning of the conditioning
   specified by the DiffServ code point of 5 (e.g., a specific set of
   queue and threshold settings).

   Policy requires AAA functions, not only for access control, but also
   to establish the trust relationships that will enable distributed
   policy interactions.  PDPs may require the requesting end systems and
   applications to be authenticated before the PDP will honor any
   requests. The PDP and PEP must be authenticated to each other to
   reduce the probability of spoofing. This will be true whichever
   protocol is utilized for supporting communications between these
   entities. Audit trails are essential for all of these transactions.
   In addition, trust management policies will need to be developed as
   well as the supporting middleware mechanisms to enable inter-domain
   policy negotiation.

   Ultimately, many policy processes link entities to resources, And
   therefore require interactions with entity identification mechanisms,
   resource identification mechanisms, and allocation mechanisms. The
   distributed computing community has already started efforts
   developing policy definition languages and systems.  Globus uses its
   Resource Services Language (RSL) to define the resources and policies
   associated with them. Condor uses a matchmaking bidding technique to
   match those providing and those acquiring services. Similarly, the
   IETF has several policy definition languages in varying stages of
   development, including RPSL, RPCL, SPSL, PFDL, PAX, and Keynote.
   Ultimately, these efforts should be merged into a single
   specification (or at least a smaller group of specifications) to
   enable distributed computing applications to be able to effectively
   communicate and utilize network resources and services.

   Directories play a crucial role in policy systems. Directories are
   ideally suited for storing and retrieving policy information, due to
   their exceptionally high read rates, ability to intelligently
   replicate all or part of their information, per-attribute access
   control, and use of containment.  To this end, the IETF Policy
   Framework working group (in conjunction with the DMTF) is developing
   a core information model and LDAP schema that can be used to
   represent policy information that applications can use. This core
   model is used to provide common representation and structure of
   policy information. Applications can then subclass all or part of the
   classes in this core schema to meet their own specific needs, while
   retaining the ability to communicate and interoperate with each
   other.





Aiken, et al.                Informational                     [Page 11]

RFC 2768          A Report of a Workshop on Middleware     February 2000


8.0 Directories

   Directories are critical resource components that provide support to
   many other elements in the middleware environment, especially policy.
   As network-based environment evolves, it will no longer be viable to
   encode policy information directly into each individual application.
   The prevailing model in use today is for each application to store
   its view of a device's data (e.g., configuration) in its own private
   data store.These data include relevant information concerning network
   resources and services as well as clients wanting to use those
   resources (e.g., people, processes, and applications). The same
   resource (or aspects of that resource, such as its physical vs.
   logical characteristics) may be represented in several data stores.
   Even if the device is modeled the same way in each data store, each
   application only has access to its own data. This leads to
   duplication of data and data synchronization problems.

   The promise of technologies like CIM and DEN is to enable each
   application to store data describing the resources that they manage
   in a single directory using a common format and access protocol. This
   results in the data describing the resource being represented only
   once. Defining a logically centralized common repository, where
   resources and services are represented in a common way, enables
   applications of different types to utilize and share information
   about resources and services that they use.

   Not only does this solve the data duplication and synchronization
   problems, it also provides inherent extensibility in describing the
   characteristics of an object - a single entity can be represented by
   multiple directory objects, each representing a different aspect of
   the entity. Different applications can be responsible for managing
   the different objects that together make up a higher-level object,
   even if the applications themselves can not communicate with each
   other. This enables these applications to effectively share and reuse
   data.  This provides significant benefits for users and applications.
   In the short term, users and applications will benefit from having
   all of the data in one place. In the long term, users and
   applications will be able to take advantage of data managed by other
   applications.

   Directories are key to supporting advanced network-based application
   environments. Directory purists say that the directory is not
   middleware; rather, it is a dumb storage device that is made into an
   intelligent repository by encapsulating it within middleware.
   Although a directory associates attributes with objects, what makes
   it different from a database are four key things:





Aiken, et al.                Informational                     [Page 12]

RFC 2768          A Report of a Workshop on Middleware     February 2000


   -  directory objects are essentially independent of each other,
      whereas database objects are related to each other (sometimes in
      very complex ways)
   -  directories organize their information using the notion of
      containment, which is not naturally implemented in databases
   -  directory objects can have specific access controls assigned to an
      object and even attributes of an object
   -  directories, unlike databases, are optimized to perform a high
      number of reads vs. writes.

   Directories use a common core schema, supporting a common set of
   syntaxes and matching rules, that defines the characteristics of
   their data. This enables a common access protocol to be used to store
   and retrieve data.

   Containment can be used for many purposes, including associating
   roles with objects. This is critical in order to support a real world
   environment, where people and elements may assume different roles
   based on time or other context.Containment may also be used to
   provide different naming scopes for a given set of data.

   Directories use attribute inheritance - subclasses inherit the
   attributes of their superclasses. This enables one to define
   generalized access control at a container (e.g., a group) and then
   refine the access control on an individual basis for objects that are
   inside that container (e.g., different objects have different access
   privileges).

   Currently, directories are used mostly to represent people, servers,
   printers, and other similar objects. CIM, DEN, and other similar
   efforts have encouraged directories to be used to contain common
   objects in a managed environment. For networked applications, this
   enables clients of the network (e.g., users and applications) to be
   bound to services available in the network in a transparent manner.
   The "Grid" community is making extensive use of directory services
   for this purpose, using them to maintain information about the
   structure and state of not only networks but also computers, storage
   systems, software, and people. The DMTF is using directories to
   contain CIM and DEN information, which enables a common information
   model to be applied to objects in a managed environment. The IETF is
   using directories for many different purposes, not the least of which
   is to contain common policy information for users and applications of
   an environment, as well as services and configuration information of
   network devices.







Aiken, et al.                Informational                     [Page 13]

RFC 2768          A Report of a Workshop on Middleware     February 2000


   CIM and DEN are conceptual information models for describing the
   management of entities ranging from network elements to protocols to
   hosts and services. CIM and DEN are platform- and technology-
   independent. DEN is an extension of CIM that, among other things,