NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00
Andrew Smith <email@example.com>
Mark Stevens <firstname.lastname@example.org>
Operations and Management Area Director(s):
Randy Bush <email@example.com>
Bert Wijnen <firstname.lastname@example.org>
Operations and Management Area Advisor:
Bert Wijnen <email@example.com>
To Subscribe: firstname.lastname@example.org
In Body: subscribe rap
Description of Working Group:
Recent work in the IETF has led to the development of standards for a QoS-enabled Internet. Through the efforts of the Integrated Services working group, data flows can describe their desired or required service to the network. RSVP carries the service requests into the network, where the acceptance of these QoS requests results in better network service to some flows, possibly at the expense of service to traditional best-effort flows.
In an open and public Internet (as well as large intranets), maintaining such service differentiation inherently depends on mechanisms capable of enforcing (or reporting) operational policy constraints. Towards this end, RSVP message formats contain a place-holder for policy data elements, which may contain information relevant to the network's decision to grant a reservation request.
Certain network elements may require assistance in the processing of these policy-data elements and, therefore, may communicate with one or more policy servers, entities which specialize in the making of policy decisions.
The purpose of the RAP working group is to establish a scalable policy control model for RSVP. The working group will specify a protocol for use among RSVP-capable network nodes and policy servers. This work will also require documentation of any extensions to RSVP which may be necessary in support of this policy control.
In addition, the working group will define usage directives for use of the COPS base protocol to support policy information exchange transactions within the framework being standardized in the Policy Framework Working Group. In particular, the group will address the following work items:
1. COPS usage for policy provisioning transactions ("COPS Usage"): The working group will produce a standards-track RFC that specifies usage of COPS for the support of policy information exchange transactions between a PDP and its PEPs.
2. Object syntax for carrying policy provisioning information ("Object Syntax"): The working group will produce a standards track RFC that specifies the syntax of objects and their contents for carrying policy information. The working group will specifically focus on the syntax of objects needed for carrying information related to QoS policy provisioning.
This work explicitly excludes definition of semantics of policy provisioning objects. Instead, it will rely on the definitions from the relevant working groups such as DiffServ and ISSLL.
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.
In pursuit of these goals, the working group must expressly avoid specifying policy behavior. The judgment of specific policies is similarly beyond the scope of the working group. The working group will, however, specify mechanisms that allow for a wide variety of possible policies to be carried out.
Goals and Milestones:
Submit I-D framework document for policy control for RSVP to IESG for publication as a RFC.
Submit I-D defining any necessary extensions to RSVP to support policy control to IESG for publication as a RFC
Submit I-D defining a standard protocol for the exchange of policy information between RSVP-capable network nodes and policy servers to IESG for publication as a RFC.
Submit Initial draft of document that specifies COPS usage for policy provisioning transactions
Submit initial ID on object syntax for carrying QoS policy provisioning information (dependent on progress in DiffServ and ISSLL working groups)
Working Group last call on revised version of COPS Usage document incorporating mailing list discussions
Submit COPS Usage document to IESG for publication as an RFC
Submit object syntax transport protocol ID
Submit object syntax transport protocol to IESG for consideration as a RFC.
Request For Comments:
Signaled Preemption Priority Policy Element
Identity Representation for RSVP
A Framework for Policy-based Admission Control
The COPS (Common Open Policy Service) Protocol
COPS usage for RSVP
RSVP Extensions for Policy Control
Application and Sub Application Identity Policy Element for Use with RSVP
Monday, July 31, 2000
RAP Working Group Meeting
48th IETF Meeting Pittsburgh, Pennsylvania
9:00 AM - 11:30 AM
Reported by Mark Stevens, Scott McManus and Diana Rawlins
David Durham on COPS-PR
After introductions and agenda bashing, Dave Durham gave the group an Update from David Durham on the COPS-PR draft.
Summarizing, COPS-PR draft is ready for working group last call. Clarifications have been made on synchronization behaviours. Clarifications have been made on responses to unsolicited messages. Error code descriptions have been improved. At least 6 Companies demonstrated interoperability. Last-call to begin at the end of IETF week which is Aug 4, 2000. Last-call to go for 2 weeks and then submit to IESG as a standards track document.
David Durham on COPS for AAA
David Durham also gave the group an update on draft-durham-aaa-cops-ext-00.txt, a draft that describes how COPS could meet the requirments described by the AAA requirements document.
A team formed in May 2000 used the evaluated the draft among others and issued a draft containing the team's findings. COPS scored higher than all but DIAMETER which scored nearly indistiguishably higher. In summary, COPS Acceptable meets most requirements.
There were no comments from attending participants.
Scott Hahn on the Framework PIB
Scott Hahn presented a status report on the Framework PIB draft
The draft defines basic and common classes for COPS. Capability classes define information enabling PDP to target policies. Both PDP to PEP and PEP to PDP initiated exchanges are supported. These are Basic classes for COPS. Capability classes define information enabling PDP to target policies. PDP to PEP and PEP to PDP initiations are supported.
- Defines common Policy Rule Classes useful for all potential client types
- Avoids redefinition. The base can be re-used
- term client type and subject category are equivalent
Are we ready for working group last-call? Response: Yes.
A suggestion was made that after September interoperabilty test, the group should ask for working group last call.
Fran Reichmeyer on COPS for MPLS
- PIB definition for MPLS
- Useful for both CCR-LDP and RSVP / TE
- Policy help define LSP tunnel setup
- Draft on MPLS WG agenda
Fran Reichmeyer on presented a draft descrinbing the use of COPS for MPLS. The draft is being worked in the mpls working group, rather than the RAP working group. Fran solicited input from RAP working group participants.
Joel Halpren expressed concerns on the decomposition of information in the method presented. Generally, COPS sends policy oriented, non-instance specific information. Two layers of dialog are coupled in this presentation.
This PIB doesn't seen to sliced in the right way. What goes in a PIB?
Policy control must be introduced.
Area Director, Bert Wijnen, indicated that the Traffic engineering working group is discussing MIB at high-level being presented. Fran indicated one of his co-authors, Steven Wright, would be participating in the TEWG and could receive that group's input.
Bert Wijnen also indicated that he felt that the group need to make up its mind on where ongoing COPS development would occur. Where do we do this work?
Joel Halpren responded with comments that indicate that he believed that the decomposition of information would go better in RAP.
Diana Rawlins on Accounting PIB
- Defines reporting structures commonly used by all client types
- Question from floor about impact on COPS-PR/Policy Framework PIB; response was semantics consistent with existing COPS work, there are some clarifications needed
- Suggestion that draft discuss alternatives and reasons COPS chosen for this
Diana asked that it become a working group item.
Dave Durham expressed that the framework for such a PIB is in place and that the the decription does not belong in COPS-PR document. He further indicated that there was no reason to bind it to framework PIB document and that indeed the accounting PIB work would fill a hole left in the COPS work done to date. It neeeds to be a wg work item.
Shai Herzog agreed. His comments summarized: Report accounting is needed and it needs to be a separate work item. COPS-PR draft needs examination to insure it does not get in the way.
In response, Diana Rawlins indicates that she did not anticipate any such conflicts.
Clarifications may be needed in the area of fail-over, but on the surface it seems to be straight-forward.
Area Director, Bert Wijnen, made comment to the effect of the following statements and query: I am not sure this be a new work item or not. I don't see evaluation of alternative approaches. Other protocols exist. Why is using a PIB so much better?
In response, Diana Rawlins made statements to the effect of the following: This approach affords a finer granulatrity of control. It enables users and applications to specifiy an interval and reduce unnecessary traffic. Traps have proved problematic. Other approaches have been examined.
Area Director, Bert Wijnen requested that the authors add summaries of their evaluation to the documnet.
Responding to the implication of a Bert's earlier question about the scope of accounting, Shai Herzog responded with a question and a statement to the effect of the following. Is this [accounting PIB] to be used for accounting in general or accounting for things using COPS for policy control specifically? If so, already developers have made the decision to use COPS, so this fits nicely.
Diana Rawlins reinforced by saying that her purpose was for accounting for policies installed by COPS.
David Durham provided additional supporting comments to the effect of the following. COPS accounting mechanisms are different. Look at the AAA evaluation committee requirements for batch accounting. It shows difference amoung a numnber of protocols. The accounting PIB is particularly suited to the purposes outlined today.
Kwok Chan further iterated: Policy accounting allows negotiation on how much info the network device delivers.
Keith McCloghrie on SPPI
See draft and presentation slides for information on Keith's presentation. In summary, SPPI constitutes the rules for defining PIBS and we have made some changes in repsonse to comments made at the previous IETF and mailing list activiites.
Juergen Schoenwaelder rasied a series of issues. Juergen indicated that he would forward his issues list to the mailing list immediately.
Keith pledged to update the draft as soon as he could incorporate new information (before August 31, 2000).
The intention is to make working group last-call at the August 2000.
The working group should note that future PIB drafts are dependent upon SPPI being complete.
Jesse Walker on COPS over TLS
- Propose using TLS to secure COPS
- TLS doesn't have the firewall issues that IPSec does
Deployment is problematic without a good security mechanism. COPS can be used for QoS, but can be used for many other purposes. Destibuting security policy is a problem that can be solved with COPS. No way to get the policies out to all of the millions of end systems.
Discussion After Presentations
Shai Herzog: PIB for Accounting already in the charter effectively.
After Jesse Walker's presentation, the co-chair and the area director looked for working group comments and participation with respect to making decisions on whether to go to last call on the mature documents presented in the meeting.
To spark discussion, Area Director, Bert Wijnen, suggested the remaining drafts go on the experimental track.
Dicussion was sparked, several disagreed.
To gleen the consensus of the room, the co-chair asked for a show of hands in support the actions listed below.
Go to last-call on COPS-PR draft Start August 4th, 2000 - 2 weeks
Go to last-call on Framework PIB Start August 31st, 2000 - 2 weeks
Go to last-call on SPPI draft Start August 31st, 2000 - 2 weeks
Virutally no one raise a hand against any of these actions.
A sufficient number of the participants present in the room raised a hand in support of these actions, although some participants did not raise a hand to indicate either perference.
The co-chair gauged sufficient consensus in the room and will attempt to gleen consensus on the list as well. With sufficient consensus, the working group will take the actions listed above.
In summary, a show of hands revealed sufficient consensus to warrant going to last call on the COPS-PR Framework PIB and the SPPI drafts.
After opening the second session of the RAP working group meeting, the co-chair yeilded the floor to the Area Director, Bert Wijnen.
Bert explained that his comments with regard to the remaining working group drafts and the appropriate track were personal opinions expressed with the intention of sparking discussion in a rather quiet working group meeting. He reiterated that he had not been speaking as Area Director and he reassured the working group that the working group, co-chairs, and area director make the decision of a draft's track together and that his personal opinion did not necessarily reflect the recommendation that he would make as area director.
Nasir Ghani COPS for ODSI - 10 minutes
- Optical network policy needed
- Uses outsourcing model
- Decisions based on user group, IP addresses, SLA and TOD
- Future work is to develop static policy model
Jesse Walker CMS over COPS - 15 minutes
- Proposal for end to end security in a proxy environment
- Based on the RFC 2630 CMS
- Comment from floor that Policy Framework could define common signature mechanism
Man Li IPSec Policy PIB - 15 minutes
- PIB for use by IPSEC
- IPSP work group item
Comments on IPSec Policy PIB:
Dave Durham asked if there was a format for the time delta being used. Man responded that the attribute comes from the core module ( including month of year, day of month, day of week and time of day ).
Dave Durham then followed up by asking if TLS is sufficient ( since IPSec is identified as one of the candidate security protocols in RFC 2748 and since there are no lower-level protocols identified ) and if the PEP-PDP communication would have to support it. Man responded that "it depends on requirement", and some may not be happy with TLS.
Someone in the audience asked if there was a possible past rejection of IPSec over COPS, and Dave responded by saying that COPS didn't include privacy considerations at the time.
Someone made the clarification that IPSP negotiation was involved on an interdomain level, and then asked if the proposal was on the intradomain level. Downloading policy information was more likely to be on an intradomain level for the proposal.
Shai Heraog asked if the proposal's concept was for one administrator on a single domain versus several different networks, and Man replied that this concept was correct.
Jesse commented that CMS describes how to encode end-to-end data transfers, but there are no known implementations.
Dinesh Dutt Ext for RSVP Rec Proxy - 10 minutes
- Is a RSVP work group item
- Outstanding item is the need a separate definition of the capability object from RSVP receiver proxy
- Request that draft becomes RAP work group item
Comments on the presentations were limited in the interest of time.
At the end of the meeting, the co-chair, Mark Stevens presented a strawman list of additional work items for the group.
Receiver Proxy Work
The co-chair asked for hands in support and hands against adding each item individually. Each time a sufficient number of hands indicated consensus for adding the work. Each time no one raised a hand against adding them.
To further gauge consensus, the co-chair asked for volunteers to work on each document. Each work item had between 3 and 5 volunteers.
The co-chair indicated that he would look for consensus on the mailing list to augment the mesaurement taken during the meeting.
The meeting closed.
CMS Over COPS
COPS Usage for MPLS/TE
Framework of COPS-PR Policy Information Base for Accounting Usage
COPS Extension For RSVP Receiver Proxy
COPS Over TLS
COPS Usage for ODSI
Proposed Extensions for Aplication Identitiy Policy Element
IPsec Policy Information Base