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

["Jason, Jamie" <jamie.jason@xxxxxxxxx>]

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