Protocol Action: COPS Usage for Policy Provisioning to Proposed Standard
The IESG <iesg@ietf.org> Fri, 02 February 2001 19:50 UTC
Received: from loki.ietf.org (loki [10.27.2.29]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24617; Fri, 2 Feb 2001 14:50:53 -0500 (EST)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id OAA03930 for ietf-123-outbound.10@ietf.org; Fri, 2 Feb 2001 14:35:01 -0500 (EST)
Received: from ietf.org (odin.ietf.org [10.27.2.28]) by loki.ietf.org (8.9.1b+Sun/8.9.1) with ESMTP id OAA03909 for <all-ietf@loki.ietf.org>; Fri, 2 Feb 2001 14:34:37 -0500 (EST)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23817; Fri, 2 Feb 2001 14:34:36 -0500 (EST)
Message-Id: <200102021934.OAA23817@ietf.org>
To: IETF-Announce:;
Cc: RFC Editor <rfc-editor@isi.edu>, IANA <iana@iana.org>
Cc: Internet Architecture Board <iab@isi.edu>
Cc: rap@ops.ietf.org
From: The IESG <iesg@ietf.org>
Subject: Protocol Action: COPS Usage for Policy Provisioning to Proposed Standard
Date: Fri, 02 Feb 2001 14:34:36 -0500
Sender: scoya@cnri.reston.va.us
The IESG has approved the Internet-Draft 'COPS Usage for Policy Provisioning' <draft-ietf-rap-pr-05.txt> as a Proposed Standard. This document is the product of the Resource Allocation Protocol Working Group. The IESG contact persons are Bert Wijnen and Randy Bush. Technical Summary This document describes the use of the COPS protocol [COPS] for support of policy provisioning (COPS-PR). This specification is independent of the type of policy being provisioned (QoS, Security, etc.), but rather focuses on the mechanisms and conventions used to communicate provisioned information between PDPs and PEPs. The protocol extensions described in this document do not make assumptions about the policy data model being communicated, but describe the message formats and objects that carry the modeled policy data. Working Group Summary The RAP WG has consensus on publication of this document as a Proposed Standard. Protocol Quality The specification has been reviewed for the IESG by Bert Wijnen. Notes to RFC-Editor: 1.Please in section 1.1, remove the last 2 paragraphs. So section 1.1 should read: 1.1. Why COPS for Provisioning? COPS-PR has been designed within a framework that is optimized for efficiently provisioning policies across devices, based on the requirements defined in [RAP]. First, COPS-PR allows for efficient transport of attributes, large atomic transactions of data, and efficient and flexible error reporting. Second, as it has a single connection between the policy client and server per area of policy control identified by a COPS Client-Type, it guarantees only one server updates a particular policy configuration at any given time. Such a policy configuration is effectively locked, even from local console configuration, while the PEP is connected to a PDP via COPS. COPS uses reliable TCP transport and, thus, uses a state sharing/synchronization mechanism and exchanges differential updates only. If either the server or client are rebooted (or restarted) the other would know about it quickly. Last, it is defined as a real-time event-driven communications mechanism, never requiring polling between the PEP and PDP. 2.Pls replace the security section with this text: 8. Security Considerations The COPS protocol [COPS], from which this document derives, describes the mandatory security mechanisms that MUST be supported by all COPS implementations. These mandatory security mechanisms are used by the COPS protocol to transfer opaque information from PEP to PDP and vice versa in an authenticated and secure manner. COPS for Policy Provisioning simply defines a structure for this opaque information already carried by the COPS protocol. As such, the security mechanisms described for the COPS protocol will also be deployed in a COPS-PR environment, thereby ensuring the integrity of the COPS-PR information being communicated. Furthermore, in order to fully describe a practical set of structured data for use with COPS-PR, a PIB (Policy Information Base) will likely be written in a separate document. The authors of such a PIB document need to be aware of the security concerns associated with the specific data they have defined. These concerns MUST be fully specified in the security considerations section of the PIB document along with the required security mechanisms for transporting this newly defined data.