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

Please see inline for further modifications made according to the suggestions.

> -----Original Message-----
> From: ext Wijnen, Bert (Bert) [mailto:[email protected]]
> Sent: March 12, 2004 01:20 PM
> To: Li Man.M (Nokia-NRC/Boston); [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
> 
> 
> 
> 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

OK also added "It is a hash value as defined in [RFC2408]  Section 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.

OK. Added references to RFC3585 for all life time related attributes.

> 
> Bert
>