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

Sorry that it took so (much too) long for my follow up.
Comments inline.

A separate email will contain additional new comments.

Thanks,
Bert 

> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: vrijdag 21 november 2003 23:25
> To: [email protected]
> Cc: [email protected]; [email protected]; [email protected];
> [email protected]; [email protected]
> Subject: RE: MIB/PIB doctor review for 
> draft-ietf-ipsp-ipsecpib-09.txt -
> part 1
> 
> 
> 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.
> 
OK, so I now have continued to review revision 9.
I expect to see a rev 10 after all changes have been made.

> Best regards
> Man
> 
> > -----Original Message-----
> > From: ext Wijnen, Bert (Bert) [mailto:[email protected]]
> > Sent: November 19, 2003 12:08 PM
> > To: Li Man.M (NRC/Boston); '[email protected]'; '[email protected]';
> > '[email protected]'
> > 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 
> 
OK, I see that it is a HASH. That explains it.
The reference helps. Might be good to also state that this is the
hash value as defined in RFC2408 sect 3.16

> > 
> > 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.
> 
If this PIB is to be modelling RFC3585, then pls do follow that document,
It just seemed weird to me. Adding the references, and may be a few lines
of explanantion will help people understand why the weirdness is in the
PIB.

Bert