Subject: RE: Core Model Last Call Issue: Execution Semantics

From: [email-masked]
Date: Fri, 14 Apr 2000 15:36:48 -0400

> OK, but why on earth is the priority attribute optional? It's absence
should
> always be an "oops". I don't see why leaving it out, at the PDP-PEP
> boundary, is ever helpful - it is trivial to default it in an
implementation.

Making priority mandatory is at best a step towards addressing the problem
in the small.  Finishing the job entails requiring that all priorities are
unique -
the IPsec SPD does this by implicitly associating priority with the entry
position in the linear ordering - since no two entries can be in the same
position in a linear order, the desired result follows.  IMHO, requiring
that
each rule has a unique priority does not scale up well in the core model.

I can see two alternative approaches:
	(1) Adopt the Container construct from the QoS model, require
		unique priorities within each Container, and describe how
		to order nested priorities (it's like ordering words in a
		dictionary: albatross comes before alpha because b
		comes before p).
	(2) Use the corresponding lexical ordering of DNs to resolve ties
		that aren't resolved by priority.
Both of these approaches match the hierarchical structure of the policy
model in a fashion similar to linear search matching the linear ordering
of the IPsec SPD.

I'm disappointed that Bob has mischaracterized RFC 2401.  The second
piece of text that I quoted from RFC 2401 is an exact match to what I'm
advocating, specifically:
	- Consistent, predictable processing is required in all cases
(must).
	- Linear ordering of the SPD and search in that order has been
		chosen as the approach to meet that requirement (MUST).
To get that RFC 2401 text to match the approach proposed in the core model,
one would have to replace its MUSTs with MAYs, and remove the text
that requires "consistent, predictable processing".  The WG is free to
reject that requirement, but should only do so with a full understanding of'
why RFC 2401 did something fundamentally different.  IMHO, requirements
for "consistent, predictable processing" are not unique to security.

--David

---------------------------------------------------
David L. Black, Senior Technologist
EMC Corporation, 42 South St., Hopkinton, MA  01748
+1 (508) 435-1000 x75140, FAX: +1 (508) 497-6909
[email-masked]  Cellular: +1 (978) 394-7754
---------------------------------------------------

---

From: "John Strassner" <[email-masked]>
Date: Sat, 15 Apr 2000 19:00:23 -0700

Comments inline.

regards,
John

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Friday, April 14, 2000 12:36 PM
Subject: RE: Core Model Last Call Issue: Execution Semantics

...

> Making priority mandatory is at best a step towards
> addressing the problem in the small.  Finishing the
> job entails requiring that all priorities are
> unique - the IPsec SPD does this by implicitly
> associating priority with the entry
> position in the linear ordering...

You are comparing the operation of an algorithm with the
operation of a system. This is apples and oranges.

> IMHO, requiring that each rule has a unique
>priority does not scale up well in the core model.

I'm confused - it just seems that you just said that what
you really want - making all rule priorities unique -
doesn't scale. Please help me understand what you do want.
As far as your approaches:

> (1) Adopt the Container construct from the QoS model,
> require unique priorities within each Container, and
> describe how to order nested priorities (it's like
> ordering words in a dictionary: albatross comes
> before alpha because b comes before p).

This doesn't solve your problem, because this still allows
multiple objects to have the same priority. In fact, we
explicitly allow this, because sometimes the semantics "Do
this set of rules before this one and after that other one
in whatever order is convenient" is important.

> (2) Use the corresponding lexical ordering of DNs to
> resolve ties that aren't resolved by priority.
> Both of these approaches match the hierarchical structure
> of the policy model in a fashion similar to linear search
> matching the linear ordering of the IPsec SPD.

Please remember that we are talking about an information
model. An information model is by definition INDEPENDENT of
any one particular repository. So any talk of ordered DNs is
inappropriate for the core information model, and MUST ;-)
be delegated to one of the schema drafts.

...

---

From: "Yoram Snir" <[email-masked]>
Date: Sun, 16 Apr 2000 09:41:54 +0200

Making the rule priority mandatory solves some of the problems although I
think that uniqueness is not required.
To complete the picture and have a fully consistent model 2 other things are
required;
1. PolicyGroup priority.
2. Nested rules priority.
Both were defined as part of the QoS Policy information model.

Yoram Snir
Cisco Systems
Tel.   972-9-9700085
Mobile 972-54-970085

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of John Strassner
> Sent: Sunday, April 16, 2000 4:00 AM
> To: [email-masked]; Andrew Smith; [email-masked]
> Cc: [email-masked]; [email-masked]
> Subject: Re: Core Model Last Call Issue: Execution Semantics
>
>
> Comments inline.
>
> regards,
> John
>