[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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:bwijnen@xxxxxxxxxx]
> Sent: March 12, 2004 01:20 PM
> To: Li Man.M (Nokia-NRC/Boston); bwijnen@xxxxxxxxxx
> Cc: smb@xxxxxxxxxxxxxxxx; ho@xxxxxxxxxxxx; lsanchez@xxxxxxxxxxx;
> avri@xxxxxxxxxxxxxx; ipsec-policy@xxxxxxxx
> 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: Man.M.Li@xxxxxxxxx [mailto:Man.M.Li@xxxxxxxxx]
> > Sent: vrijdag 21 november 2003 23:25
> > To: bwijnen@xxxxxxxxxx
> > Cc: smb@xxxxxxxxxxxxxxxx; ho@xxxxxxxxxxxx; lsanchez@xxxxxxxxxxx;
> > avri@xxxxxxxxxxxxxx; ipsec-policy@xxxxxxxx
> > 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: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
> >
> 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
>