[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: draft-ietf-ipsec-policy-schema-00.txt



> Architectural Question:
> 	Where should "action" fit into the class hierarchy? My expectation
is
> that the general IETF Policy WG (different from the IPSec Policy WG)
> will be forming a generalized condition <-> action schema. Under that,
> IPSec would fit in as a particular instantiation of an 
> action.

Agreed.  It is our expectation that the policy WG will develop the core
schema necessary.  Other working groups would deveolop domain-dependent
conditions and actions as necessary.  In our particular schema, we don't
have any domain specific conditions, but obviously we have domain-specific
actions.

> Have you thought about merging your polices, rules, and conditions 
> work into the policy working group and then forming a draft to detail out
an
> instantiation of a particular (IPSec) policy action.

That is the direction we would like to see this go.  The reason for our
presenation at Minneapolis IETF and this draft is to stimulate discussion
about policy in general as well as policy for IPSEC.  It is our belief that
what you state is what will eventually transpire.

> 	What an IPSec proposal contains seems to have left out 
> compression...oversight?

Yes.  Our particular work didn't include compression, but to be complete it
should indeed include compression.

> In your draft you seem to imply that the absence of a Permit
> or Deny means Secure.

At this time, we have 4 unique IPSEC actions: (1) deny (or block), (2)
permit (or bypass), (3) tunnel action, or (4) transport action.  I agree
that there may be some ambiguity with the terms (as you may be able to tell,
my first experience in the industry was with firewalls) and will make a note
of it.  In our current system, there is a requirement that there be an
action object associated with the condition - so the absence of a permit or
deny action means that there is a transport or tunnel action (i.e., secure
action).  We could have been clearer about it, but if I were to draw the
permit and deny actions in the class diagram, they would derive from the
IPSecAction (in other words, peers to the secure actions).  I will make a
note for the next rev of the draft.

Jamie