Subject: Draft charter agreed to at the Interim Meeting

From: "John Strassner" <[email-masked]>
Date: Fri, 4 Jun 1999 18:10:49 -0700

Everyone,

below is the proposed draft charter that was agreed to by the
participants of the Interim Meeting. This draft modifies the
original draft sent earlier on this list.

Note that one new addition is item 7, proposed by Lee Rafalow as
promised at the interim meeting. Also note that the PIB is not
officially proposed as added to the charter yet, pending further
discussion.

regards,
John and Ed

-------------------------  begin new proposed charter
text -----------------------------

1. Identify a set of representative use cases to guide us in
defining a policy framework, information model, and schemata to
store, retrieve and process policies. These use cases should map
to a set of policy rules, and aid us in defining the composition
of policies.

2. Define a framework for intra-domain policy definition and
administration for a heterogeneous set of Policy Decision and
Enforcement Points. The framework will be shown to be able to
represent and manage policy information in an unambiguous,
interoperable manner in a single administrative domain. The
framework has the ability to store policy information in a policy
repository. This will be documented in the framework and
information model drafts. This framework will be applied to
network QoS. It is envisioned that this framework can also
support other network services based on protocols defined by the
IETF, such as IPSec, DHCP, and VPNs.

3. The main result of this work will be an LDAP schema for
storing policy information in a directory. This will be
documented in the core and network QoS schema drafts. Care will
be taken to ensure that this work is extensible to other types of
repositories, such as relational databases.

4. The schemata developed will focus on generic network policies
for both provisioned and signaled QoS services.

This working group will work with the DiffServ, IntServ, RAP, and
ISSLL working groups to ensure that the QoS schema meets their
technical needs, and is suitable for both IPv4 and IPv6 standards
track work.

5. To ensure that security issues are addressed, Russ Mundy will
serve as this working group's security adviser.

6. The charter specifically excludes:

  -protocol definition
  -schema attributes or classes that are vendor-specific
   (although the schema defined in this group will be defined in
    a way that is extensible by specific vendors)

// NEW ITEM - see discussion for this new item at the end
7. Because policy is a device-independent specification of
configuration
information, the policy information model and schema provide for
infrequently
changing declarative information that reflect network rules
rather than network
state.  The Policy Framework WG may request that other IETF
Working
Groups provide enhancements to protocols that they develop to
communicate
network state information (e.g., current network user
identification) so that
rules can be written to use additional dynamic stateinformation
in applying the
policy rules.

Goals and Milestones:

1. Policy terminology draft (Informational Track)
- Working Group Last Call just after Oslo IETF
2. Core information model draft (Informational Track?)
- Working group Last Call September 1999
3. Core LDAP schema draft (Standards Track)
- Working group Last Call September 1999
4. Framework draft (Informational Track)
- Working group Last Call, December 1999
5. QoS Schema draft(s) (Standards Track)
- First issuance, June, 1999
- Working group Last Call, just before Adelaide IETF, Spring 2000

-----------  end new proposed charter text, start discussion of
item 7 -----------

Some supporting discussion for item #7 (from Lee):

We need to be clearer about the difference between the
interpretation of policy rules and the data path execution logic
associated with the policy rules.
Policy rules specify the *configuration* of the network that is
required to meet
SLOs in a device-independent way.   Policy, then, is the source
language that is compiled (by the PDP) into a target language
specification (device
configuration) of the logic needed to implement those policies on
a particular
platform. I suspect we all agree, more or less, with these
statements.

Where clarity and consensus are replaced by confusion and
disagreement, I think, is that some of the data on which the
policy target language description
operates is not currently available to the PEPs using existing
protocols. Therefore, I think, people may be tempted to think of
dynamically changing the
existing configuration parameters to make up for this missing
state information and, thus, conclude that they are implementing
"dynamic policy" rather than providing data on which the policy
can operate through the same interfaces that the policy itself is
input into the target system.

The last point to make now is that providing this state data as
configuration
changes may be appealing (and may even be necessary in the
short-term) but it may be asking for trouble.  Whenever there are
two paths along which information about a flow and the flow
itself may traverse, there are potential race conditions.  To
solve these race conditions, one must either have a
synchronization mechanism or must be able to tolerate loose
consistency.  I'll
assert without defence that policies can live with loose
consistency (hence LDAP is an adequate choice for communicating
them) but network state information must be consistent in order
for the network to behave in a consistent and predictable
fashion.  Therefore, inline communication of applicable state
changes will normally be the better technical answer; i.e.,
protocols need to be enhanced to synchronize awareness of events
that are input to policy enforcement.

---

From: "Raju Rajan" <[email-masked]>
Date: Mon, 7 Jun 1999 10:50:35 -0400

Hi,

I had a comment about the newly added item on the policy charter:

> 7. Because policy is a device-independent specification of configuration
infrequently
> changing declarative information that reflect network rules rather than
network
> state.  The Policy Framework WG may request that other IETF Working
> Groups provide enhancements to protocols that they develop to communicate
> network state information (e.g., current network user identification) so
that
> rules can be written to use additional dynamic stateinformation in
applying the
> policy rules.

I agree  with the first sentence. The second is a vague non-sequitur. Is it
intended to give us a mandate to *demand* or to *suggest* ? For the latter
we don't need a mandate. We *may* always ask another working group if
they'll do so and so for us. If the former, we pretty much allow ourselves
to improve any protocol in IETF. The example given (current network user
identification) is a part of the PDP decision making process. The PDP has to
bind policy categories -- user name, application name, interface type,
whatever -- with dynamic information -- user name to source address, for
instance. Then it may instruct the PEP to carry out the right operations on
the packet stream. If my understanding is in keeping with Lee's explanation
below (which I believe it is), then the protocol enhancements that could
potentially be requested are a very large set. We could impact protocols
between a route server--network devices, Kerberos authentication, Radius
server, billing servers, etc.

I would plead that we postpone this mandate till we have a clear idea of
which protocol/protocols will be impacted, what exactly we need, and how we
intend to achieve it. In other words, I request that we clearly state that
we will not be involved with binding of policy categories (conditions) to
header information as yet, and just drop the second sentence. Thanks for
your patience,

raju

---

From: Shai Herzog <[email-masked]>
Date: Mon, 07 Jun 1999 15:11:18 -0400

At 10:50 AM 6/7/99, Raju Rajan wrote:

>header information as yet, and just drop the second sentence. 

I am not sure if I misunderstand, or disagree with you, but let me
try to clarify it.

Are you saying that the WG should work on a schema that includes
dynamic binding (e.g., user name, path info, etc), but shouldn't 
worry about how this is done (COPS, etc.) for now? OR, are you saying
that we shouldn't allow dynamic binding criteria into the schema? (which
I don't think you meant to say).

Shai

>Thanks for your patience,

What patience???? ;-)

Shai

__________________________________________________________
Shai Herzog                  Founder & CTO, IPHighway Inc.         
Cell: (408) 390-3045       http://www.iphighway.com/herzog           
Tel : (201) 585-0800                  Fax : (212) 656-1006

---

From: "Raju Rajan" <[email-masked]>
Date: Mon, 7 Jun 1999 15:28:09 -0400

I'm saying that we should not put anything into the charter till we
understand what it entails. Otherwise we'll have a second PFDL disaster.

raju

----- Original Message -----
From: Shai Herzog <[email-masked]>
To: Raju Rajan <[email-masked]>; John Strassner
<[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Monday, June 07, 1999 3:11 PM
Subject: Re: Draft charter agreed to at the Interim Meeting

---

From: "John Strassner" <[email-masked]>
Date: Mon, 7 Jun 1999 12:58:08 -0700

Raju,

we agreed in the Interim meeting to the first 6 items, hence
their inclusion in the charter. We also agreed to let Lee suggest
his addition, which is why I included Lee's discussion that gave
his rationalization for requesting this addition to the charter.

I'll let Lee answer your non-sequitur issues. I think we can make
a decision to add or not add Lee's suggestion once feedback roles
in. Right now, this is the first message I've seen (though I'm on
travel with spotty Internet access, and am sure yours will
generate others).

regards,
John

----- Original Message -----
From: Raju Rajan <[email-masked]>
To: John Strassner <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Monday, June 07, 1999 7:50 AM
Subject: Re: Draft charter agreed to at the Interim Meeting

configuration
> > changing declarative information that reflect network rules
rather than
Working
communicate
> > network state information (e.g., current network user
identification) so
> header information as yet, and just drop the second sentence.
Thanks for

---

From: Shai Herzog <[email-masked]>
Date: Mon, 07 Jun 1999 16:14:08 -0400

It was my impression that the charter preceeds the development
of solutions, so by definition, it includes things we THINK we know
what to do with, but haven't done or fully understand yet.

However, I think the charter should describe a problem space
and not a solution. Solutions come later.

Shai

---

From: "John Strassner" <[email-masked]>
Date: Wed, 9 Jun 1999 23:14:04 -0700

I don't agree.

This working group is NOT solely concerned with producing an
optimized schema that can be implemented in a directory that uses
LDAPv3 as its access protocol. This working group IS concerned
with developing an information model, from which specific
schemata aimed at specific implementations can be derived. The
fact that we are spending a lot of time on a directory
implementation does not mean that the information model should
ignore dynamic information.

That being said, I think that we should walk before we run.
Certainly, focusing on non-dynamic information is simpler,
easier, and will lead to tangible results more quickly. I'm just
objecting to the black-and-white statement of "no, we should not
care about how the dynamic information (or network state) is
updated.

Could you please explain what you mean to being "able to bind a
policy to an object partially defined"? I can't parse this. Does
this mean I'm binding a policy to an object which is then going
to change? If it changes, how do I know that the binding is still
valid?

Finally, the examples you gave are LDAP-specific. Remember, we
have two work items for the core and QoS schemata: an information
model and an LDAP mapping of the information model. So yes, we
should consider all those, but we should ensure that the
information model is complete before we go off into a specific
implementation. Otherwise, we may never be able to get back to
the information model cleanly, which will then inhibit other
mappings (e.g., to an RDBMS).

John

----- Original Message -----
From: Jean Christophe Martin <[email-masked]>
To: Raju Rajan <[email-masked]>
Cc: John Strassner <[email-masked]>;
<[email-masked]>; <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Wednesday, June 09, 1999 6:58 AM
Subject: Re: Draft charter agreed to at the Interim Meeting

> Raju
>
> I agree with you that this group should not care about how the
> dynamic information (or network state) is updated, however,
> I think that this is important to be able to bind a policy
> to an object partially defined because some of its parameters
> are dynamically allocated.
> This group should define if the binding is done by DN pointers,
> by specific DIT, by specific attributes defined as placeholder
> for dynamic valus, or placeholder for pointers to the dynamic
> attributes.
>
> JC.
>
configuration
rather than
Working
identification) so
Thanks for