[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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: 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
> >
> > 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