WG Review: Recharter of Resource Allocation Protocol (rap)

The IESG <iesg-secretary@ietf.org> Fri, 06 April 2001 18:00 UTC

Received: from loki.ietf.org (loki [10.27.2.29]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15828; Fri, 6 Apr 2001 14:00:48 -0400 (EDT)
Received: (from adm@localhost) by loki.ietf.org (8.9.1b+Sun/8.9.1) id NAA25462 for ietf-123-outbound.10@ietf.org; Fri, 6 Apr 2001 13:55:02 -0400 (EDT)
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 NAA25412 for <all-ietf@loki.ietf.org>; Fri, 6 Apr 2001 13:46:10 -0400 (EDT)
Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15437; Fri, 6 Apr 2001 13:45:59 -0400 (EDT)
Message-Id: <200104061745.NAA15437@ietf.org>
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce:;
cc: new-work@ietf.org
Subject: WG Review: Recharter of Resource Allocation Protocol (rap)
Date: Fri, 06 Apr 2001 13:45:59 -0400
Sender: scoya@cnri.reston.va.us

The IESG is considering rechartering the Resource Allocation Protocol (rap)
working group. The IESG has not made any determination as yet. 

The following Description was submitted, and is provided for
informational purposes only:


Resource Allocation Protocol (rap)
-----------------------------------

Description of Working Group:

Recent works in the IETF have led to the development and
standardization of enhanced network services such as QoS and traffic
engineering. The complexity of these services and the variations in the
capabilities of the devices implementing these services provide a
challenge to anyone trying to configure services within medium- and
large-scale networks.

The working group will define general-purpose objects that facilitate
the manipulation of policies and provisioned objects available through
COPS and COPS-PR.  Where appropriate, these will include frameworks
clarifying the applicability of COPS objects and the best practices for
the definition of additional objects defined in other working groups.

In particular, the group will address the following work items:

 - A standards track framework document describing the usage of COPS
   in carrying usage reporting and unsolicited state change 
   information between a PDP and a PEP [FEEDBACKFRWK].  

 - A standards track document describing an accounting PIB to be used
   to carry accounting information from the PEP to the PDP [PIB].

 - Complete work on the standards track documents for (a) the data 
   definition language for COPS-PR [SPPI] and (b) the set of core
   data definitions for QoS provisioning [FRWKPIB].

 - A standards track document describing a modular architecture for a
   COPS based Management Framework. The document will address the COPS
   message processing, security and access control and may specify
   examples of how the framework may be implemented.  [COPSFRWK]

 - A standards track document describing a framework or PIB to enable
   the explicit binding of QoS to to authenticated agents, such as 
   corporate entities or individual users. This implies that this 
   framework and/or PIB supports the proxying of authentication 
   requests [BINDFRWK].

 - An informational document describing the use of COPS over TLS.
   [COPSTLS]

 The working group will continue to document changes to COPS objects
 needed to support any extensions to RSVP and extensions to RVSP
 directly related to usage control. Specifically the working group will
 pursue:

       - A version of draft-ietf-rap-rsvp-newidentity that addresses
          security shortcomings with the current document
          [NEWIDENTITY].

       - A standards track document defining new ErrorValues for the
         RSVP Policy Error Object [RSVPERRVAL].

       - A standards track document defining the framework and
         mechanism for authorizing of RSVP sessions [SESSIONAUTH].

       - A standards track document defining an RSVP Local Policy
         Control Criteria PIB [RSVPPIB].

Documents produced by the working group must fully address all the
security aspects of this type of protocol. In particular, theft and
denial of service threats must be minimized.