Re: comment on IPsecPolicyGroup

["Lee Rafalow" <rafalow@xxxxxxxxxxxxxxx>]

I'm concerned about building too much future into todays model.

The requirements we've been trying to address are for IKE.  If we do as you
suggest, should we also add superclasses for key management action and
proposal?  Are there abstractions for key management conditions that may be
needed?  What properties go in these superclasses and what properties stay
in the IKE subclasses?  What associations go on the superclasses and what
associations stay on the IKE subclasses?

The rules for inserting a new class into inheritance trees vary; for
example, LDAP doesn't formally permit it (i.e., X.500 doesn't permit it and
LDAP is silent), but it's done anyway and there's been discussion in ldapext
about fixing the formal rules.  But in the information model I think we can
insert classes as needed as long as they don't break the subclasses (e.g.,
introduce a property that has an inconsistent definition).  It's certainly
permitted in the CIM schemata to insert new superclasses. If, at some point
in the future, there's a need for some other key exchange protocol, a new
superclass for IKERule can be inserted into the inheritance tree and the
additional requirement can be addressed at that time when there's full
knowledge of the requirement.

On the other hand, if this is for a known function, by all means let's
discuss the requirements and see if we agree to add it to the requirements
for the current draft.

Lee  (in my technical advisor capacity)


----- Original Message -----
From: "Ricky Charlet" <rcharlet@xxxxxxxxxxxx>
To: ".ipsec-policy" <ipsec-policy@xxxxxxxx>
Sent: Tuesday, January 09, 2001 7:38 PM
Subject: ICIM: comment on IPsecPolicyGroup


> Howdy,
>
> IPsecPolciyGroup binds together an IKERule and and IPsecRule. I'd like
> to see a layer of abstraction introduced, namely a KeyManagementRule.
> Then under keyManagementRule, we could use IKE for KM services if we
> wanted, but we could also use kerberose, or son-of-ike or manually
> entered keys, or....
>
> --
>   Ricky Charlet   : Redcreek Communications   : usa (510) 795-6903