Subject: Retry: Draft Minutes from Policy WG Sessions in San Diego

From: [email-masked]
Date: Fri, 22 Dec 2000 21:46:47 -0500

Hi,

[The copy of this which I received on my first try did not include anything
beyond the first paragraph of item 1.4.  I don't know why.  Here is another
attempt at sending the whole thing.]

Section 1 is from the wrap-up charts which we discussed at the end of each
session, and combines the action items from both days.  Joel and I turned
in this summary section (just Section 1), as our report to Bert on the
results of our meetings.

Section 2 is from my notes for Monday's session.

Section 3 is from my notes for Wednesday's session.

I have not reviewed Sections 2 and 3 with anyone.

Fire away.  We need to turn these in with the the charts by the end of next
week.

I have everyone's charts.  Thank you for sending them to me.  I will submit
them with the revised minutes.

*************************************

Draft Summary and Minutes
Policy Framework Working Group Meeting
49th IETF, San Diego
Submitted by Ed Ellesson, December 22, 2000

1.   Summary and Action Items, combined from both wg sessions:

1.1   QDDIM: (QOS DiffServ Device Info Model, or QOS Datapath Device Info Model)

      -Differences with DiffServ are now resolved

      -Expect name change to the QDDIM draft to reflect generic qos datapath focus for
       traffic handling and conditioning (ie. not just diffserv), but qos signaling
       (control plane) will continue to be out of scope for this document.

       *  Action:  Bob Moore

      -Schedulers/Queues relationship: Expect co-author consensus to be posted on
       the policy mailing list, in approximately two weeks.

       *  Action:  Walter Weiss

1.2   QPIM:  (QOS Policy Information Model)

       *  Action:  QPIM Authors:

      -Overlap and linkage with QDDIM: Need added text/terminology to describe
       how/why policy objects are approached differently in QPIM, than from
       device level view in QDDIM.

      -Further clarification may be added to describe distinctions among the
       following functions:  Configuration, policy (operational behavior), and
       state.

      -QPIM continues to be device independent, and mechanism independent. Examples
       are needed that show the abstraction level for QPIM, including policy vs.
       mechanism.

      -A new PCIM extensions draft will be written, which describes generic PCIM
       functions that can be broken out separately from the current QPIM draft
       (ie. those that are not QOS-specific.  The first phase of this was agreed
       to be done by the current QPIM authors, themselves.

      -RSVP with diffserv in the same network. Positioning statement needed for
       this situation.

1.3   ICIM (IPSP Configuration Information Model):

      -The content of this document is owned by the IPSP working group.

      -Our liaison with IPSP (Lee Rafalow) will take a look at similarities with
       QPIM, to determine if there is any reason to recommend further harmonizing
       any of the functionality there with QDDIM or QPIM approaches, such as in
       the area of sequenced actions.

1.4   Packet classification work effort proposed:

      -Small design team will be formed to clearly document the motivations for the
       differing approaches to packet classification across QDDIM, QPIM and ICIM.
       This team will clearly express the design goals of each approach

---

From: "Ed Ellesson" <[email-masked]>
Date: Sat, 23 Dec 2000 10:24:40 -0500

I am going to try this one more time before I call the help desk about the
server not forwarding the whole note.  Sorry for filling up people's mail
boxes!
----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, December 22, 2000 9:46 PM
Subject: Retry: Draft Minutes from Policy WG Sessions in San Diego

Hi,

1.1   QDDIM: (QOS DiffServ Device Info Model, or QOS Datapath Device Info
Model)

      -Expect name change to the QDDIM draft to reflect generic qos datapath
focus for
       traffic handling and conditioning (ie. not just diffserv), but qos
signaling
       (control plane) will continue to be out of scope for this document.

       *  Action:  Bob Moore

      -Schedulers/Queues relationship: Expect co-author consensus to be
posted on
       the policy mailing list, in approximately two weeks.

       *  Action:  Walter Weiss

       *  Action:  QPIM Authors:

      -Overlap and linkage with QDDIM: Need added text/terminology to
describe
       how/why policy objects are approached differently in QPIM, than from
       device level view in QDDIM.

      -Further clarification may be added to describe distinctions among the
       following functions:  Configuration, policy (operational behavior),
and
       state.

      -QPIM continues to be device independent, and mechanism independent.
Examples
       are needed that show the abstraction level for QPIM, including policy
vs.
       mechanism.

      -A new PCIM extensions draft will be written, which describes generic
PCIM
       functions that can be broken out separately from the current QPIM
draft
       (ie. those that are not QOS-specific.  The first phase of this was
agreed
       to be done by the current QPIM authors, themselves.

      -RSVP with diffserv in the same network. Positioning statement needed
for
       this situation.

      -Our liaison with IPSP (Lee Rafalow) will take a look at similarities
with
       QPIM, to determine if there is any reason to recommend further
harmonizing
       any of the functionality there with QDDIM or QPIM approaches, such as
in
       the area of sequenced actions.

      -Small design team will be formed to clearly document the motivations
for the
       differing approaches to packet classification across QDDIM, QPIM and
ICIM.
       This team will clearly express the design goals of each approach.

       *Action:  Volunteers to contact WG chairs

      -Consideration will be given, to converge or not, the four approaches
to
       packet classification presented by Bob Moore:

       a) single field generic (filter entry)
       b) variables/operators/values (qpim)
       c) single field specific (ipsp's icim)
       d) multi-field specific (6-tuple)

      -Consideration will be given to documenting this in the separate,
common
       document, (see above) which defines general purpose mechanisms, or to
       document why general purpose approaches are not appropriate.  These
       guidelines will be intended to guide further application of our
models
       to other domains.

      -If multiple approaches continue to exist after this design team
effort,
       mapping the methods, one to the other, will need to be documented.

1.5   Terminology Draft:

      -Expect document rev in a few weeks, then working group Last Call.

       *  Action:  Andrea

1.6   PCLS (Policy Core LDAP Schema):

      -Expect another rev with recent input from mailing list, and a new
security
       considerations section.

      *Action:  Ryan Moats, Bob Moore and Ed Ellesson.

      -Expect this document to be ready for last call next month.

1.7   MPLS Policy:

      -Authors will discuss potential homes for this work with wg chairs,
and the
       appropriate AD's . The Policy Framework wg charter does not cover
this.  As
       a general rule, it is expected that further application of the policy
model,
       beyond qos, will be accomplished within technologly-specific working
groups,
       which is where the subject matter experts are for those technical
domains.
       This is similar to the way mibs/pibs are developed.

       *  Action:  Joel will help by discussing this with the chairs and/or
AD's
          for MPLS.

1.8   Charter Milestones:

      The co-chairs will work with Bert on a new set of wg
charter-milestones, now
      that our first document (PCIM) has been approved for advancement to
Proposed
      Standard.

      *   Action:  Joel and Ed

2.   Detailed Minutes from the Monday, December 11 Session:

      -The order of the minutes is in the order of the agenda topics.

2.1   Intro/Objectives/Milestones:  Joel Halpern:

      -Welcome.  Thanks to the many authors who have worked to get drafts
for this
       meeting.

      -However, we are WAY behind schedule.

      -Particular items of note that need to be worked on include:

       a) Framework
       b) Requirements
       c) Use Cases
       d) Terminology

      -The QPIM and QDIM work has made some significant progress.  Remember:
"A
       key part of demonstrating that this model can provide end-to-end
translation
       of high-level policy specifications to device configurations is to
ensure that
       the information model and schemata are compatible with and can use
the
       information contained in the PIB(s) and MIB(s) being developed in the
       Differentiated Services WG. To this end, the Policy Framework WG will
supply
       input to the development of the PIBs, and include all applicable PIBs
and MIBs
       in its development considerations for the framework, information
model, and
       schemata." So we need to get QPIM and QDIM aligned with each other
and with the
       diffserv work.   QDIM is now much more closely aligned with diffserv
than in the
       past.  Cooperation with DiffServ here is a key goal.

       -Similarly, we need to work with the IPSP folks to align the usage of
the model
        there.  We will work to put together a new schedule.  We will be
reluctant to
        take on any new work items until the backlog has cleared.  And even
then we
        would like to get this working group wrapped up rather than
perpetually adding
        work items.

2.2   Agenda Bash.  No changes for now.  (see later changes to second day's
agenda)

2.3   QDDIM Issues Presentation:  Bob Moore

      -Bob's charts were also presented in the DiffServ working group, just
prior to
       this Policy Framework meeting.  Some of the decisions on these issues
are
       DiffServ's to make, since they are the owners of the diffserv
conceptual model,
       mib, and pib, with which we want to be consistent.

      -The word "device" was added to the title, to reflect the fact that
rsvp is no
       longer  included in the initial focus of this document.  (It proved
to be too
       hard to reach closure on both diffserv and rsvp at the same time.)

      -See the charts that Bob presented, for the details of each specific
issue.

       *   Issue 1: On whether the QDDIM Scheduler class is to be a subclass
of
           Condition:

           -It was decided that Scheduler is, indeed, to be a subclass of
            Condition.

       *   Issue 2: should scheduling disciplines be modeled as associations
or as classes?

           -Walter:  It turns out that the DiffServ MIB will not allow one
approach, but
            the conceptual model will support it.  The question  is:  should
we align with
            the mib or the informal conceptual model?

           -Andrea, Walter, John Strassner and Dave Durham all had opinions
on which was
            a better representation, and the vote among them was split.  The
decision was
            to revisit this...see the summary for the resolution.

       *   Issue 3:  How should the tail drop and head drop dropping
algorithms be
           represented?

           -The resolution is that the the DiffServ working group will
loosen the
            language in the conceptual model to allow for the dropper to be
represented
            either before or after the queue, and the MIB will be tightly
defined, as it
            is now, to include a property to describe a dropper as tail drop
or head drop.
            This leaves the policy working group clear to document the model
as we are
            doing it now.

       *   Issue 4:  Bob described a taxonomy for the four ways to represent
filters, used
           across multiple documents in our working group.

           -We will take up this topic for discussion in the Wednesday
session, after the
            ICIM presentation.

2.4   QPIM Issues Presentation:  Ron Cohen

      -QPIM includes PCIM extensions, including those that are QOS-specific
(both
       diffserv and intserv), as well as those that are useful beyond just
the QOS
       discipline.

      -See Ron's charts for a complete list of the changes from the last
draft of
       the QPIM document and for the generic and qos-specific extensions
included
       there.

      -Generic Extensions to PCIM include the modeling of variables and
values, which
       allows for the reuse of values, and for specifying value constraints,
and for
       adding new variables and values without changing the syntax.  See the
charts
       for other extensions.

      -Mapping to the DiffServ MIB is supported.

      -Reuse and "domain-wide" application of QPIM, are the primary drivers
for
       organizing the model the way it is currently.

      -Missing Pieces:

       *  a model of the "capabilities" functionality in the PIB

       *  an approach for binding roles to entities

      -Status of QPIM:  The last call on this document forced discussion,
and the
       feedback was valuable and incorporated into the current draft.

2.5   QPIM and QDDIM Compatibility with DiffServ Discussion
      Moderators:  Joel and Ed

      -On QPIM relationship to QDDIM:  This relationship is not formally
documented
       in the QPIM document.  John Strassner commented that this is a "works
with"
       relationship, rather than a "mapping" relationship, between QPIM and
QDDIM.

      -Bob Moore questioned the issue about DSCP markers not having two
values.  This
       may need to be clarified.  Also, Bob suggested not reusing the class
names
       from the QDDIM model, in the QPIM model, since that could cause
confusion.
       Ron accepted this last comment as a valid point.

      -Andrea expressed the opinion that a mapping from QPIM to QDDIM is,
indeed,
       required.  We also need to work on clarifying the "configuration" vs.
"state"
       issue.

      -It was agreed that a new PCIM extensions document would be created,
and the
       relevant parts of QPIM that are generically applicable, would be
pulled out
       and documented separately.  The QPIM authors will participate, as
well as
       volunteers, as they come forward.

       -Lee Rafalow:  Not convinced that the following aspects of QPIM are
justified:
        complexity of "atoms" approach, compound conditions, and Rules
within Rules.

       -Yoram Bernet requested that more attention be given to admission
control, and
        to those conditioning services that are in common to both intserv
and rsvp.

       -Shai Herzog questioned the level of the policy documented here...is
it
        "mechanism" or is it "policy"?

2.6   Monday's Session Wrap-up:

      -See Section 1, above, for the combined summary of both Monday and
Wednesday
       sessions

3.  Detailed Minutes from the Wednesday, December 13 Session:

3.1    Intro and News:  Changed the agenda to continue the discussion of
       Queues and Schedulers.  See the sixth item on the agenda (item 3.6,
below).

3.2   ICIM:  IPSP Policy Model Presentation, Lee Rafalow:

      -Lee suggests that we harmonize among the various document authors on
appropriate
       re-usable components for packet classification, across the several
documents
       which address this.

      -See Lee's charts for his review of the IPSP (ICIM) Model.

       *  Basic model structure

       *  Filter-based conditions

       *  Actions, Proposals, and Transforms

      -Discussion Points:

      -Differences between the multiple models that do packet classification
were
       reviewed.  Lee noted the different objectives for each model, which
motivated the
       different approaches.  See the charts.

      -Semantics of subclassed condition class, as used in the ipsp's icim
model, are
       specific to the ipsec negotiation, which can change from true to
false, as more
       info is received about the security association.  This is a different
semantic
       than in the case of QOS.

      -Grouping differences were also discussed.

      -Evaluation order is always determined ahead of time, in IPsec policy.
This is
       always mandatory, but the semantic is different from the mandatory
semantic in
       the rest of the policy model. The semantic is:  "Try this first, and
if it does
       not work try the next one."

      -Roles: As used in the policy model, roles represent a binding of
policy to
       interfaces.  This is not the appropriate semantic for IPsec, so the
PolicyRole
       object was not used.  Instead, the ipsp icim model uses
IdentityContexts.

      -The IPSP model is more oriented toward individual device policy, like
QDDIM,
       rather than the domain level, like QPIM, but the IPSP model derives
from the
       policy classes, like QPIM does.

      -Discussion:

       *  Strassner:  QPIM differences have to do with the reusability of
the classes,
          without binding to specific devices.

       *  Ron Cohen:  Sequenced actions:  There is a similar function in
QPIM, with a
          selector, for path messages.  Suggests we take a look at whether
we should
          have the same basic approach in both QPIM and IPSP's ICIM

       *  ICIM is a model for the PDP to PEP configuration function; it is
not a domain
          level model

       *  Rules are "leaf" objects in the IPSP's ICIM model

3.3  Applying and Linking Policy Discussion  (including the discussion about
packet
     classification)

     -Proposed objective:  Harmonize the reusable components across the
documents
      which describe how to represent policy for packet classification, or
clearly
      document why there are differences, due to different design points,
different
      disciplines, etc.  Are the semantics really different?

     -Walter Weiss:  Questions whether the IPSP's ICIM model should be
handling both
      levels in one model.  Conditions and Actions, can one thing be both?

     -A work effort is proposed:  mapping the different approaches, one to
the other.

     -Reuse of instances vs. reuse of classes:  this motivates some of the
differences
      in QPIM.

     -The usefulness of the QPIM "atoms" approach might drive the QPIM
method of
      representing filters, as being different from other models.  On the
other hand,
      maybe convergence of documentation is called for: perhaps a single
document which
      describes the generic approaches, and when each is called for:  single
field
      generic (filter entry), variables/operators/values (QPIM), single
field specific
      (ICIM), multi-field specific (6-tuple).

     -A separate document is proposed to split out the portion of QPIM that
documents
      functions, such as packet classification, that can be re-used across
multiple
      disciplines, with an explanation of the different approaches that
remain, if they
      do indeed remain after the attempt to harmonize them.  The current
authors of the
      QPIM document will take the lead with this effort, but volunteers are
encouraged,
      as well.  We may do this in a two-step process, with the current
authors taking
      the first shot at the generic document.

     -The MPLS needs for packet classification should also be taken into
account, since
      this is also valuable experience that we can learn from for the
purpose of coming
      up with a generic approach.

      -Example:  "Source Port = 80" appears to be in all the models.

      -There is controversy about this point:  The distinctions between QPIM
and QDDIM
       may be defensible, given the difference in their scope (network
domain-wide scope,
       vs. device level scope), but what about ICIM (the IPSP's model),
which appears to
       be device-level?   But we should be able to articulate the reason
that any
       differences remain, if we can.

      -The topic of policy languages came up.   This is not in our charter,
but Andrea
       suggested we might want to look at the language constructs developed
by Morris
       Sloman at Imperial College in London.

      -There was also a question about how SNMP handles differences in mibs.
Does the
       SNMP area directorate push back on working groups that taken
different approaches
       to the same problem?

       Bert:  Yes, the Ops and Management area pushes back on working groups
that want
       to go a different way, but the AD's are not always successful in
pushing for
       common approaches.  Despite the best of intentions,  there are mibs
that provide
       duplicate function in different ways.

       (BTW:  Wasn't Policy supposed to solve this?)

3.4   PCLS Update: (Ryan Moats and Ed Ellesson)

      -Changes for the -08 version:   Please see Ryan's charts for details.

      -Ryan reviewed the syntax changes from the previous version, as well
as other
       changes, including an issue associated with matching rules, and the
fact that
       there will be a -09 version shortly, with new aux classes, and a new
security
       considerations section.

      -Security Considerations section:  Please see Ed's charts for details.

      -Ed reviewed the security considerations which will be re-written for
the next
       version.  The challenge is to make sure that all the necessary
security
       considerations are covered, across the multiple documents which
complete the
       standardized "policy package" of documents for any specific
discipline.

      -For example, the QOS group of policy documents will include the core
policy
       documents, PCIM and PCLS, as well as the QOS-specific policy info
model (QPIM),
       and the device level info model for QOS (QDDIM), plus whatever the
appropriate
       mapping of these QOS-specific models turn out to be,  to an
LDAP-accessible
       directory.

      -The security considerations sections of all these documents taken
together, have
       to cover all the appropriate issues for applying QOS policy in a real
world
       environment.  The security considerations section of PCLS is part of
this total
       coverage.

      -Please contact Ed if you want to contribute to this section.

3.5   Polterm Harmonization:  Andrea Westerinen

      -See Andrea's charts.

      -The team which created this draft was successful in achieving its
goal:  to
       finalize common policy terminology across multiple working groups,
without creating
       new terms.

      -The team resolved the conflicting use of the term Policy Rule in
different wg's

      -Polterm draft will be revised with changes discussed in presentation
and sent to
       last call.

      -References to I-D's will be removed and maintained separately in a
cross-reference
       table linked from the policy framework working group's home page.

3.6   Queues and Schedulers:  Walter Weiss

      -See Walter's charts.  This is meant to provide a context for
continuing the
       discussion from Monday on this topic.

      -In the current QDDIM model, we have greater flexibility in
representing queues and
       schedulers than is currently available in the DiffServ mib with
SMIv2.  This was
       accepted as not being a problem, since individual vendors may extend
the DiffServ
       mib in proprietary ways, and we want the QDDIM model to be able to
map to these
       extensions, if possible, to the extent that we can anticipate them.

      -Brian Carpenter stated that the DiffServ working group's criteria for
including
       something in the DiffServ mib is that it be expressible, and that
vendors want it
       there.  Further, it should be clear that QDDIM does not drive the
content of the
       DiffServ mib.

      -There was considerable discussion of the six charts which Walter
presented, which
       described the pro's and con's of different ways of representing
queues, schedulers,
       and their relationships to each other.  This presentation and
discussion further
       clarified the issues, and will be used to help the QDDIM authors come
to an
       agreement for finalizing how that model will represent queues and
schedulers and
       their relationships.

3.7   Use of Policy in AAA Architecture:  Cees de Laat

      -See charts from Cees de Laat, at:

       http://www.phys.uu.nl/~wwwfi/aaaarch/sandiego/delaat.htm

      -Cees presented the policy work that is going on in the IRTF, under
the AAA
       Architecture working group.

      -This working group has an inter-domain focus and an architectural
focus, which
       differentiates it from the work in the policy framework working
group, in addition
       to the fact that they are working on AAA.

3.8   Use of Policy in MPLS:  Ritu Chadha and Marcus Brunner

     -Ritu presented the changes and convergence from the first drafts which
dealt with
      MPLS policy.  The authors re-used a number of the ideas for packet
filtering, roles
      and other functions, from the QDDIM and QPIM drafts.

     -Marcus presented the open issues, including the fact that MPLS policy
has not been
      accepted as a charter item by any IETF working group, including policy
framework,
      mpls, and traffic engineering.

     -Joel committed to talking to the chairs of the mpls and tewg to help
determine the
      appropriate home for this work.  It seems appropriate to host this
work where the
      subject matter experts are (mpls or tewg), with help provided from
policy liaison
      people who have experience in applying the policy information model.

3.9   Wrap-up:  See Section 1 of these minutes for the combined summary for
both sessions.

Ed Ellesson

[email-masked]
Office at Tivoli:  919-224-2111
Office at home:  919-644-3977