RE: MIB/PIB doctor review for draft-ietf-ipsp-ipsecpib-09.txt - part 1

[<Man.M.Li@xxxxxxxxx>]

Hi Bert,

Thanks for your comments on the IPsec PIB draft v9. Modifications have been made to address your comments 1-7 and they are described below. Please also take a look at my reply to your comment #8, since any change will create a discrepancy with RFC 3585, I suggest to leave it as is unless you do not agree.

Please let me know if any of the modifications described are still not satisfactory. I look forward to hearing more comments from you on the rest of the draft. At which point, we'll submit a new version. Thanks.

Best regards
Man

> -----Original Message-----
> From: ext Wijnen, Bert (Bert) [mailto:bwijnen@xxxxxxxxxx]
> Sent: November 19, 2003 12:08 PM
> To: Li Man.M (NRC/Boston); 'ho@xxxxxxxxxxxx'; 'avri@xxxxxxxxxxxxxx';
> 'lsanchez@xxxxxxxxxxx'
> Cc: Steve Bellovin (E-mail); Wijnen, Bert (Bert)
> Subject: MIB/PIB doctor review for draft-ietf-ipsp-ipsecpib-09.txt -
> part 1
> 
> 
> Based on the revision 9 that I received privately:
> 
> 1. I see:
>    ipSecRuleIfName OBJECT-TYPE
>      SYNTAX SnmpAdminString
>      STATUS current
>      DESCRIPTION
>    "The interface capability set to which this IPsec rule applies.
>    The interface capability name specified by this attribute MUST
>    exist in the frwkCapabilitySetTable [9] prior to association with
>    an instance of this class."
>      ::= { ipSecRuleEntry  2 }
> 
>   So I wonder:
>   - would an attribute name of ipSecRuleIfCapSetName not be 
> better than
>     ipSecRuleIfName ??? When I see the latter I think of ifName in the
>     IF-MIB, when I see the former I am more inclined to think about
>     the capaibilty in the frwkCapabilitySetTable. The latter 
> would also
>     be more inline with what we see in other PIB docs (RFC3317 for
>     example)

OK. Name changed to ipSecRuleIfCapSetName.

>   - what kind of error must be returned when the entry in the 
>     frwkCapabilitySetTable does not yet exist?

Added description in the table that the ipSecRule table entry will not be installed if that happens.

>   - is it clear what values the OID pointers in the 
> frwkCapabilitySetTable
>     can/should take when they are associated with an entry in 
> this ipSec table?

Added "The frwkCapabilitySetCapability attribute of that entry shall in turn point to an entry in the ipSecIfCaps table." to make it clear.

> 
> 2. I see
>    ipSecRuleRoles OBJECT-TYPE
>      SYNTAX RoleCombination
>      STATUS current
>      DESCRIPTION
>    "Specifies the role combination of the interface to which this
>    IPsec rule should apply. There must exist an instance in the
>    frwkRoleComboTable [9] specifying this role combination, together
>    with the interface capability set specified by ipSecRuleIfName,
>    prior to association with an instance of this class."
>      ::= { ipSecRuleEntry  3 }
> 
>    - what error must be returned when the entry in frwkRoleComboTable
>      does not yet exist?

Added description in the table that the ipSecRule table entry will not be installed if that happens.

> 3. I see
>    ipSecRuleAutoStart OBJECT-TYPE
>      SYNTAX TruthValue
>      STATUS current
>      DESCRIPTION
>    "Indicates if this rule should be automatically executed."
>      ::= { ipSecRuleEntry  11 }
> 
>    The name "AutoStart" seems to tell me it needs to be activated when
>    the class is instantiated. Is that the same as "automatically
>    executed"? What if the value gets changed to false?

Changed to "Indicates if this rule shall be activated when it is instantiated, i.e., start negotiate or statically set security associations. If the value is changed to false later, there is no impact on the security associations that have already started." 

> 
> 4. May I assume that if either ipSecStaticActionLifetimeSeconds
>    or ipSecStaticActionLifetimeKilobytes indicates end of life time
>    that that indeed marks the end of life? It is not clear what
>    happens in that case. You may want to clarify.

Added the following in ALL lifetime attributes "When both the LifetimeSeconds and LifetimeKilobytes are used, the first lifetime to expire takes precedence."

> 
> 5. I see:
>    ipSecAssociationVendorId OBJECT-TYPE
>      SYNTAX OCTET STRING
>      STATUS current
>      DESCRIPTION
>    "Specifies the IKE Vendor ID. ....
>   
>     and wonder: what is an IKE Vendor ID? How is it formatted?
>     Where is that explained? Is a reference usefull? I think so.

Added a reference to RFC 2408. There are a couple more VendorId in the draft, will add references to them as well 

> 
> 6. WHen I see:
>    ipSecAssociationDhGroup OBJECT-TYPE
>      SYNTAX Unsigned16TC
>      STATUS current
>      DESCRIPTION
>    "Specifies the key exchange group to use for phase 2 when the
> 
>    I wonder... is that justa random value? Or does each value mean
>    something, and if so, where is that defined?

Added "reference to RFC 2409 for valid Dh group values" to both ipSecAssociationDhGroup and  ipSecIkeProposalIkeDhGroup.

> 
> 7. ipSecAssociationGranularity
>    when reading the DESCRIPTION clause, I wonder if a BITS syntax is
>    not better here

OK. Changed to BITS. 

> 
> 8. ipSecAhTransformMaxLifetimeSeconds
>    I find it strange that zero means a max lifetime of 8 hours here,
>    where as in an earlier xxxMaxLifeTimeSeconds object/attribute it
>    meand infinite ?? Is that logical? Does that make sense?

All the lifetime attributes and their default values are aligned with RFC 3585. All the maxLifeTimeSeconds seem to use 0 to indicate 8 hours. All other lifetime or minLifetime uses 0 to indicate infinite. We could make changes so that, for example, 0 indicates infinite in all the cases. But that will create discrepancy between this draft and RFC 3585.