Subject: RE: draft-ietf-ipsp-config-policy-model comments

From: "Jason, Jamie" <[email-masked]>
Date: Tue, 6 Feb 2001 09:16:57 -0800

First, thanks for taking the time for reading the draft.

I'll answer your questions inline.

> 1) The definitions for SARule, SAAction, SAStaticAction,
>    SANegotiationAction and IPsecAction contain the following sentence:
> 
>      "Although the class is concrete, is MUST not be instantiated."
>
> 2) Regarding the above, why not just make the classes abstract to
>    ensure they're not instantiated?

The above mentioned classes are concrete in the DMTF version of the model,
which is used as the basis for the IETF model.  At this time, it escapes me
why this is so in the DMTF model - maybe Lee Rafalow can help me here and
jog my memory.

> 3) Some of the objects (EG, IKERuleOverridePoint) contain high to low
>    precedence (higher numbers have a larger precedence) and others
>    (EG, IPsecPolicyGroupInPolicyGroup's "Precedence" attribute) have
>    low to high precedence where lower numbers have a larger
>    precedence.  Although not important from a technical prospective,
>    it would make more sense to have this be consistent across the
>    entire document unless there is a reason its done like it is.

First, let me note that the rule override point attributes are gone.

I will go through the draft and find the areas where we have things like
order, precedence, and priority and determine if there is something we can
do about inconsistencies - some of the attributes are inherited from PCIM
and therefore we won't be able to change them.

> 4) Section 5.12 specifies the property of FQDNFilterEntry as "Name"
>    but section 5.12.1 which describes the property has a name of
>    "Address" instead of "Name".

Ooops...cut and paste error.

> 5) Section 6.2 which describes "The Class SAStaticAction" says that it
>    "serves as the base class for IKE and IPsec actions that
>    do not require negotiation.
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^
> 
>    But yet, section 6.2.1 "The property LifetimeSeconds" describes the
>    property value with "A non-zero value is typically used in
>    conjunction with fallback actions performed when there is a
>    negotiation failure of some sort."
>    ^^^^^^^^^^^^^^^^^^^

Another cut and paste error.  There should be no mention of negotiation,
either explicitly or implicitly in this section.

> 6) section 6.7.3, 6.7.4 and 6.11.1 say that "A random value may be
>    added...".  I think I'd suggest making that "may" be a "SHOULD" and
>    if not that then possibly a "MAY".

I will look at those sections and determine the intent and make the
appropriate change.

Thanks.
Jamie

---

From: "Lee Rafalow" <[email-masked]>
Date: Tue, 6 Feb 2001 13:54:19 -0500

> why this is so in the DMTF model - maybe Lee Rafalow can help me here and

Unfortunately, what I'm remembering and what I read in PCIM are two
different things.  What I remember is that the parent classes were concrete
and therefore they had to be concrete; but that's not completely true.

PolicyRule is concrete so SARule needs to be concrete.

PolicyAction is abstract so SARule can be made abstract as well.  That means
we can also make SAStaticAction, PreconfiguredSAAction, SANegotiationAction
and IPsecAction all abstract.  I think PolicyAction was concrete at some
point and then changed to abstract and we didn't update along with that
change.

Thanks for spotting this.

Lee M. Rafalow
Voice: 1-919-254-4455; Fax: 1-919-254-6243
IBM Internet Technology Management
IBM Corporation
P.O. Box 12195, BRQA/502
RTP, NC 27709 USA
Alternate email: [email-masked]
Home email: [email-masked]

---

From: Wes Hardaker <[email-masked]>
Date: 06 Feb 2001 11:24:03 -0800

>>>>> On Tue, 6 Feb 2001 09:16:57 -0800 , "Jason, Jamie" <[email-masked]> said:

Jason> The above mentioned classes are concrete in the DMTF version of
Jason> the model, which is used as the basis for the IETF model.  At
Jason> this time, it escapes me why this is so in the DMTF model -
Jason> maybe Lee Rafalow can help me here and jog my memory.

Is it a requirement that derived classes from concrete can't be abstract?

>> do not require negotiation.

Jason> Another cut and paste error.  There should be no mention of negotiation,
Jason> either explicitly or implicitly in this section.

I originally thought it was a cut-and-paste kind of error and
shouldn't be specified, but when I was writing the above note I
re-read it and wondered if you actually intended to say what my
re-phrasing attempted to clarify.  I'm actually much happier that
you'll be dropping that notion altogether.

-- 
Wes Hardaker
NAI Labs
Network Associates

---

From: Wes Hardaker <[email-masked]>
Date: 07 Feb 2001 06:48:05 -0800

>>>>> On Tue, 6 Feb 2001 13:54:19 -0500, "Lee Rafalow" <[email-masked]> said:

Lee> PolicyRule is concrete so SARule needs to be concrete.

Is this mandated by the definition language?

-- 
Wes Hardaker
NAI Labs
Network Associates

---

From: "Lee Rafalow" <[email-masked]>
Date: Wed, 7 Feb 2001 09:58:47 -0500

Yes, in CIM, which is our foundation for these classes, abstract can only
derive from abstract.  Lee