Subject: RE: Draft charter agreed to at the Interim Meeting

From: Andrew Smith <[email-masked]>
Date: Mon, 7 Jun 1999 12:10:27 -0700

I don't see that the proposed new charter item 7 adds much useful guidance.
I also do not think that we need any explicit non-goals regarding "binding
of policy categories (conditions) to header information". But it would be
good to capture some of Lee's discussion/argument in the framework document.

Andrew

****************************************************************
Andrew Smith                              tel: +1 (408) 579-2821
Extreme Networks                          fax: +1 (408) 579-3000
3585 Monroe St.                   http://www.extremenetworks.com
Santa Clara CA 95051-1450        em:  [email-masked]
****************************************************************

> -----Original Message-----
> From: Raju Rajan [mailto:[email-masked]]
> Sent: Monday, June 07, 1999 7:51 AM
> To: John Strassner; [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: Draft charter agreed to at the Interim Meeting
> 
> 
> Hi,
> 
> I had a comment about the newly added item on the policy charter:
> 
> > // 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.
> 
> 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
> 
> 
> >
> > 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: "Stevens, Mark" <[email-masked]>
Date: Mon, 7 Jun 1999 17:16:42 -0400

I think that I may be inclined to agree with Andrew, but I would offer that
item number 7 seems to say,

Let's not bite off more than we can chew.
Let's define an vendor-independent way to express packet filters in a
directory.

Does anyone else see this subtext within item #7?

Below, I include the original item and what I see when a read it.

Item 7 from the charter:
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
state information in applying the policy rules.  

Item 7 seems to break down into:
 - Policies are expressions of device-independent
   configuration information.

 - Our existing information model and schema
   accommodates the expression of policy in terms
   of static rules.

 - Sophisticated rules that consider the state of
   the network should not be expressed in the
   existing schema unless or until protocols are
   modified to contain state information needed 
   to make the decision.

Am I reading too much, or perhaps too little into this item?

-Mark

> From:	Andrew Smith [SMTP:[email-masked]]
> Sent:	Monday, June 07, 1999 3:10 PM
> To:	'Raju Rajan'; [email-masked]
> Cc:	[email-masked]; [email-masked]; [email-masked]
> Subject:	RE: Draft charter agreed to at the Interim Meeting
> 
>

---

From: Andrew Smith <[email-masked]>
Date: Mon, 7 Jun 1999 14:45:00 -0700

Mark,

I think that is certainly a deliverable from this WG: but I would consider
it to be covered already by both the original and new charters' "...
provisioned and signaled QoS ... DiffServ, IntServ, RAP, and
ISSLL working groups ... to develop schemata for both IPv4 and IPv6 ...". I
guess it does not hurt to make it more explicit, although we ought to limit
the scope to include only those packet filters necessary for
IntServ/ISSLL/DiffServ sorts of things.

Andrew

> From: Stevens, Mark [mailto:[email-masked]]
> Sent: Monday, June 07, 1999 2:17 PM
> To: 'Andrew Smith'; 'Raju Rajan'; [email-masked]
...