Minutes of RSVP Admission Policy (rap) Working Group meeting
43rd IETF, Orlando, FL, 9th December 1998

Recorded by Andrew Smith

----------------------------------------

Summary

Set of 6 documents, 1 informational describing RAP framework, 5 standards'
track protocol specs for COPS base protocol and its use with RSVP. Editorial
and minor technical issues need to be resolved on 3 of these documents -
expect to have new versions of these 3 for WG last call in early January
1999. This document set fulfills current RAP charter. Strong support within
WG for a new work item to define COPS usage in DiffServ environments. This
requires action from area directors and coordination with other WG chairs.

Charter: http://www.ietf.org/html.charters/rap-charter.html

Agenda

1. Agenda bashing, WG scope statement etc. - Chairs - 5 mins
2. RAP Framework updates - Raj Yavatkar - 10 mins
3. COPS Protocol updates/changes  - Dave Durham - 20 mins
4. COPS for RSVP updates - Shai Herzog - 15 mins
5. Policy Extensions for RSVP - Shai Herzog - 15 mins
6. Priority policy objects for RSVP - Shai Herzog - 10 mins
7. Identity representation for RSVP - Satyendra Yadav - 15 mins
8. Last-call/standards'-track discussion - Chairs - 10 mins
9. Expanded charter discussion - Chairs - 15 mins
10. COPS for DiffServ - ?? - MAYBE

Updates to the RAP framework - Raj Yavatkar: draft-ietf-rap-framework-01.txt

No open issues.

COPS-03 draft - David Durham: draft-ietf-rap-cops-03.txt

Issues:
1. Who owns PEPID - writable? Open.
2. Keepalive per client-type or per-TCP connection? This is really a
transport issue but there is not a fast enough notification from TCP. Open
issue.
3. IANA client-type admin? Yes, but is there internal structure? Some
feeling that this should be a flat space.
4. Is context needed for LocalPDP decisions? Probably not.
5. PDP Redirect to alternate port numbers? Probably not needed.

What are the implications of choosing TCP as  the transport (c.f. RUTS BoF)?
Should we define our own ordering mechanisms just in case we choose non-TCP
in future? No.
Does TCP's tendency to stall get in the way? Yes but ...
Smith: we could redefine COPS to have an abstracted transport service
interface? No.
Bradner: don't change anything at this point.

COPS-RSVP usage - Shai Herzog: draft-ietf-rap-cops-rsvp-01.txt

Presented motivation for allowing multiple contexts for each decision
returned from PDP. No known open issues.

RSVP Extensions for Policy - Shai Herzog: draft-ietf-rap-rsvp-ext-01.txt

Defines RSVP rules for handling policy objects in policy-capable and
policy-ignorant nodes (PINs).
Flag to indicate "this is a refresh of earlier policy data" - optimisation.
Option list: can indicate which FilterSpecs in the reservation this policy
applies to, can indicate which originator or destination it applies to.
Integrity object to prevent replay attacks.
Refresh Multiplier object: allows some control over how often these policy
elements will be included in refresh RSVP messages e.g. every 'n' refresh
cycles. Discussion: a time-based object would be more useful; what if
intermediate routers use different refresh timers? What about route
changes/network errors? General feeling that this needs some more discussion
or else removing - open issue.
Fragmentation - not addressed: this is a potential RSVP problem although
policy objects make it worse - certificates can be big. Hopefully there will
not be too many PINs in between ones that are actually merging/compressing
these objects. General feeling that this does not need solution as part of
this work item.
Policy element number space: do we need IANA to allocate these? Yes - needs
description in the draft.

RSVP Preemption priority - Shai Herzog: draft-ietf-rap-priority-00.txt

Priority assigned by PDPs, simple to use by PEPs.
Merging: cannot define a single algorithm suitable for all intended uses
that solves free-rider, denial-of-service and instability problems. The
object itself therefore defines one of 3 different algorithms. Examples of
merging scenarios. Stability is ensured by a concept of a "defending
priority" vs. new priority (hysteresis). No known open issues.

COPS-RSVP Policy data for User Identity - Satyendra Yadav:
draft-ietf-rap-rsvp-identity-00.txt

Added encodings for "application name".
Should we create a registry for user/string encodings (currently has ASCII
and Unicode, Encrypted and Plain)? Should these be IANA assigned? Open
issue.
Issue raised later on mailing list: make sure that the RAP WG is aware of
the
work done in the ROAMOPS area: standard way to present a user identifier
(NAI). This may be accomplished by registering NAI as a subtype through
IANA - IANA considerations sections still need to be finalised.

Next Steps & Timetable - chair (Smith)

Documents on the agenda right now: only editorial and minor technical issues
outstanding - propose to issue WG last call on all of these after spinning
several drafts, hopefully early in January 1999.
1. COPS Framework - Informational
2. COPS protocol (needs spin) - Standards' track
3. COPS-RSVP - Standards' track
4. Policy Extensions for RSVP  (needs spin) - Standards' track
5. Policy Extensions for preemption priority - Standards' track
6. Policy Extensions for identity (needs spin) - Standards' track
Publication of these would fulfill existing RAP charter.

Charter extensions? - chair (Smith) + area director (Bradner)

Bradner: issue needs to be resolved by ADs and WG chairs about possible
overlap with Policy WG and AAA BoF.
Concerns raised by multiple people in discussion about there being
significant multi-vendor momentum to extend COPS for, in particular,
DiffServ control (there is existing draft but this is currently considered
out of WG scope).
Concern that AAA work will be long in coming.
Should any DiffServ work be just a framework mechanism for transporting
arbitrary DiffServ information or should it be morenarrowly defined
(specific objects etc.)?
Elleson - strong desire to coordinate closely between policy WG and any
potential-RAP work item.