[MIB-DOCTORS] MIB Doctor review: mib content: draft-ietf-ipsp-ikeaction-mib-02.txt

[I have copied Keith, because I understand he did partially 
review this MIB module].

I have included Keith's comments (some are generic, some 
are specific T11 or IETF IMSS WG requirements and desires,
yet I think they make a lot of sense) as well, 
so you have a complete set. 

Also, Keith and I are not (yet) in complete agreement on
some aspects of MIB modules. I know that Keith has written
to you about (for example) the IPSEC-SPD-MIB after I had
done MIB doctor (and I guess at the time OPS AD review).
These are the two issues:

- I have advised, for objects of SYNTAX STorageType,
  to use some tekst aka

     For a storage type of permanent, none of the columns have
     to be writable."

  That is, I had interpreted the DESCRIPTION clause of the
  StorageType TC in RFC2579 to mandate that the use of the TC
  requires to specify which writable objects in the associated
  row must be writable (if any).

  Keith thinks this belongs in the MODULE-COMPLIANCE. We are
  still discussing this and so I cannot give any new advise yet.
  This explanation is to warn that I may revise my earlier
  advise as a result of our discussions (OPS AD will be 
  consulted as well before I want to change my earlier advise.
  In fact, Dan is at least being copied on our email exhanges).

- I have advised to write text aka

     An attempt to set this object to a value that does not
     exist in the ipiaSaNegotiationParametersTable MUST result
     in an inconsistentValue error."

  Keith believes that this is incorrect, because sometimes an
  other error can be returned. That is if in the Elements of
  Procedure in RFC3416 (sect 4.2.5, page 19, but specifcally 
  pages 20 and 21) another error would be detected BEFORE you
  check the consistency of the value (i.e. step 10 on page 21).
  I had just assumed that that makes common sense (so if you 
  detect a noAccess as per step 1 on page 20), then OF COURSE
  you return a noAccess error. Again I am not sure that Keith
  and I yet agree on how to word this.

  There are also others in the MIB doctors team (I believe our
  current OPS AD is one of them) who think that we should NEVER
  list specific snmpErrorCodes in the DESCRIPTION clauses. This,
  because (at least in theory, we're not aware of any practice)
  a MIB could be used with non-SNMP management protocols.
  If that were the only issue, then we can solve it by using
  text aka

     An attempt to set this object to a value that does not
     exist in the ipiaSaNegotiationParametersTable would cause
     an inconsistency (and for example for SNMP could result
     in an inconsistentValue error)."

  Anyway, I again have to warn that I may change my earlier
  advise once this discussion closes on MIB doctors team.

General remark
I am not well enough versed/skilled in the security protocols
and mechanisms/algorithms that are being modeled in this MIB
module/document. So I have done a review with a SNMP/MIB view,
but I have not (and cannot) review it from a security-point
of view. In fact, after having spend more than a day on this
MIB module, I cannot say that I really understand it all.

So I am assuming that real security folk will do the securiy
review and check if this indeed correctly models the management
information as intended (or maybe already have done that). 
Also the grouping of Objects and the two MODULE-COMPLIANCE 
statements are outside my competency to determine if they 
make sense or not.

The MIB documents are nearly clean (from a SYNTAX point
of view) and also many of the issues I had brought up in 
the review if the IPSEC-SPD-MIB and also were rpesent in
an earlier version of this MIB document, have been resolved.
So a more detailed review made sense this time. Lots of
comments and questions still remain though.

Here are my comments on the IPSEC-IKEACTION-MIB module.

1. ipiaIkePhase1Filter and ipiaIkePhase2Filter
   are stated to be static filters. 
   So just by pointing to it the filter is activated?
   No matter what the value is?
   I see that in the IPSEC-SPD-MIB we made it a fixed
   value of 1. Would it be wise to be consistent and do
   that here as well?

   Same for ipiaRejectIKEAction and ipiaRejectIKEActionLog

2. I am confused by:

   ipiaCredFiltCredentialType OBJECT-TYPE
       SYNTAX      IpsaCredentialType
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The credential type that is expected for this filter to
            succeed."
       DEFVAL { x509 }
       ::= { ipiaCredentialFilterEntry 2 }

   The reason is that the IpsaCredentialType TC states:

   IpsaCredentialType ::= TEXTUAL-CONVENTION
       STATUS   current
       DESCRIPTION
           "IpsaCredentialType identifies the type of credential
            contained in a corresponding IpsaIdentityFilter object."
       SYNTAX      INTEGER { reserved(0),
                             unknown(1),
                             sharedSecret(2),
                             x509(3),
                             kerberos(4) }

   So I am left wondering how I find the corresponding 
   IpsaIdentityFilter object ??

3. I see:

   ipiaCredFiltMatchFieldName OBJECT-TYPE

       SYNTAX      OCTET STRING (SIZE(0..256))
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "The piece of the credential to match against.  Examples:
            serialNumber, signatureAlgorithm, issuerName or
            subjectName.

            For credential types without fields (e.g. shared secret),
            this field SHOULD be left empty, and the entire credential
            will be matched against the ipiaCredFiltMatchFieldValue."
       ::= { ipiaCredentialFilterEntry 3 }

   So I wonder about a few things.

   - What is an empty field? I guess you mean the zero-length string.
     Pls be specific
   - What happens if some-one does not live up to the SHOULD
     requirement for exampel for a shared secret Credential Type?

4. I see:

   ipiaCredFiltAcceptCredFrom OBJECT-TYPE
       SYNTAX      OCTET STRING(SIZE(1..117))
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This value is used to look up a row in the
            ipiaIpsecCredMngServiceTable for the Certificate Authority
            (CA) Information.  This value is empty if there is no CA
            used for this filter."
       ::= { ipiaCredentialFilterEntry 5 }

   And wonder what "empty" means here. Gievne the SIZE(1..117) it seems
   to me that it cannot mean zero-length string. So I have no idea
   how to determine if this "value" is "empty" ??

   I also wonder how to look up a row in the
ipiaIpsecCredMngServiceTable
   since in that table I see no column that has a similar SYNTAX. Well,
I
   see some of SYNTAX OCTET STRING, but they have different SIZE ranges.
   So I guess I am (at least) confused.

5. I see:

   ipiaCredFiltStorageType OBJECT-TYPE
       SYNTAX      StorageType
       MAX-ACCESS  read-create
       STATUS      current

       DESCRIPTION
           "The storage type for this row.  Rows in this table which
            were created through an external process MAY have a storage
            type of readOnly or permanent.

            For a storage type of permanent, none of the columns have
            to be writable."
       DEFVAL { nonVolatile }
       ::= { ipiaCredentialFilterEntry 7 }

  I do not see why you would use capitalized MAY. I assume one may also
  create readOnly or permanent rows via SNMP?
  This issue occurs in many (all) StorageType objects

  The last sentence in the DESCRIPTION clause probably better reads:

            For conceptual rows having the value of 'permanent', 
            none of the writable columns in the row need to allow 
            write-access."

  I.e. there is a difference of a column to has a MAX-ACCESS of 
  read-create and the "allowed to actually get write access to
  an instance".

  This issue occurs in many (all) StorageType objects

6. I see

  ipiaPeerIdFiltIdentityValue OBJECT-TYPE
      SYNTAX      IpsaIdentityFilter
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION
          "The string representation of the value that the peer ID
           payload value MUST match against. Wildcard mechanisms MUST
           be supported such that:

           - a ipiaPeerIdFiltIdentityValue of '*@example.com' will
             match a userFqdn ID payload of 'JDOE@EXAMPLE.COM'

           - a ipiaPeerIdFiltIdentityValue of '*.example.com' will
             match a fqdn ID payload of 'WWW.EXAMPLE.COM'

  So it seems that matching is case-insensitive?
  If so, pls be specific about that.
  Is it true for all IpsecDoiIdentTypes ??

7. Not sure I understand this:

   ipiaIkeActThresholdDerivedKeys OBJECT-TYPE
       SYNTAX           Integer32 (0..100)
       MAX-ACCESS       read-create
       STATUS           current
       DESCRIPTION
           "ipiaIkeActThresholdDerivedKeys specifies what percentage
            of the derived key limit (see the LifetimeDerivedKeys
            property of IKEProposal) can expire before IKE SHOULD
            attempt to renegotiate the IKE phase 1 security
            association."
       DEFVAL           { 100 }
       ::= { ipiaIkeActionEntry 3 }

   For example, is zero a valid value? If so, does that not mean that
   the system would always be renegotiating? 
   And is this not making the system overly complex?
   You can see I am not a security expert,
   based on the last question I guess

8. I see:
   ipiaIkeActIdentityType OBJECT-TYPE
       SYNTAX      IpsecDoiIdentType
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This column along with ipiaIkeActIdentityContext and

            endpoint information is used to refer an
            ipiaIkeIdentityEntry in the ipiaIkeIdentityTable."
       ::= { ipiaIkeActionEntry 6 }

   ipiaIkeActIdentityContext   OBJECT-TYPE
       SYNTAX           SnmpAdminString (SIZE(1..32))
       MAX-ACCESS       read-create
       STATUS           current
       DESCRIPTION
           "This column, along with ipiaIkeActIdentityType and endpoint
            information, is used to refer to an ipiaIkeIdentityEntry in
            the ipiaIkeIdentityTable."
       ::= { ipiaIkeActionEntry 7 }

   These two objects refer to the ipiaIkeIdentityTable, which I cannot
find.
   I do find a ipiaIkeIdentityTable (which I don't think is about
PEERs?)
   and a ipsaPeerIdentityTable (in the IPSEC-IPSECACTION-MIB). Possibly
the
   latter is intended? Pls correct or explain.

9. I see:
   ipiaIkeActPeerName OBJECT-TYPE
       SYNTAX      SnmpAdminString(SIZE(0..32))
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This object indicates the peer id name of the IKE peer.
            This object can be used to look up the peer id value,
            address, credentials and other values in the
            ipiaPeerIdentityTable."
       ::= { ipiaIkeActionEntry 8 }

  Is it valid to have a zero-length string?
  If so, what does a zero length string mean?

10. I see:
   ipiaIkeActVendorId    OBJECT-TYPE
       SYNTAX           OCTET STRING (SIZE(0..65535))

       MAX-ACCESS       read-create
       STATUS           current
       DESCRIPTION
           "Vendor ID Payload.  A value of NULL means that Vendor ID
            payload will be neither generated nor accepted.  A non-NULL
            value means that a Vendor ID payload will be generated
            (when acting as an initiator) or is expected (when acting
            as a responder)."
       DEFVAL { "" }
       ::= { ipiaIkeActionEntry 11 }

   I think I would rename this object to ipiaIkeActVendorIdPayload.
   I believe that VendorId is often understood to be an
enterprise-number
   and so the descriptor here may confuse people.

   More importantly, the "NULL" value is unclear to me. I think you
   mean "zero-length string" ??

   Similar suggestion to rename ipiaIpsecActVendorId to
   ipiaIpsecActVendorGroupId or some such.

   Similar issue with ipiaIkePropVendorId

11. I see:
   ipiaIpsecActPeerGatewayIdName OBJECT-TYPE
       SYNTAX      OCTET STRING (SIZE(0..116))
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This object indicates the peer id name of the peer
            gateway.  This object can be used to look up the peer id
            value, address and other values in the
            ipiaPeerIdentityTable.  This object is used when initiating
            a tunnel SA.  This object is not used for transport SAs.
            If no value is set and ipiaIpsecActMode is tunnel, the peer
            gateway is determined from the source or destination
            address of the packet."
       ::= { ipiaIpsecActionEntry 7 }

   Pls be specific in "If no value is set". I guess you mean the 
   zero-length octet string.

   It also mentions ipiaPeerIdentityTable, which I cannot find. 
   Which table is intended? Is it ipsaPeerIdentityTable ??

   Same for DESCRIPTION clause of ipiaIpsecActPeerGatewayIdName

12. In
   ipiaIpsecActGranularity OBJECT-TYPE
       SYNTAX      INTEGER { subnet(1), address(2), protocol(3),
                             port(4) }

       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This object specifies how the proposed selector for the
            security association will be created.  The selector is
            created by using the FilterList information.  The selector
            can be subnet, address, porotocol, or port."
       ::= { ipiaIpsecActionEntry 9 }

   You may want to be a bit more specific as to what comprises the
   "FilterList" !!??

13. For

   ipiaSaNegParamMinLifetimeSecs OBJECT-TYPE
       SYNTAX      Unsigned32
       UNITS       "seconds"
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "ipiaSaNegParamMinLifetimeSecs specifies the minimum seconds
            lifetime that will be accepted from the peer."
       ::= { ipiaSaNegotiationParametersEntry 2 }

   ipiaSaNegParamMinLifetimeKB OBJECT-TYPE
       SYNTAX      Unsigned32
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "ipiaSaNegParamMinLifetimeKB specifies the minimum kilobyte
            lifetime that will be accepted from the peer."
       ::= { ipiaSaNegotiationParametersEntry 3 }

  I wonder if the values zero mean anything special?
  Or are they not valid?

14. For
   ipiaIkePropCipherKeyLength OBJECT-TYPE
       SYNTAX      Unsigned32
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This object specifies, in bits, the key length for
            the cipher algorithm used in IKE Phase 1 negotiation."
       ::= { ipiaIkeProposalEntry 3 }

   Don't you want to say anything about KeyLength requirements?
   Is a value of zero valid at all? If so, what does that mean?

15. For ipiaIkePropCipherKeyRounds
   Is zero a valid value? Are there any other constraints?

16. For
   ipiaIkePropMaxLifetimeSecs OBJECT-TYPE
       SYNTAX      Unsigned32
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "ipiaIkePropMaxLifetimeSecs specifies the maximum amount of
            time to propose a security association remain valid.

            A value of 0 indicates that the default lifetime of
            8 hours SHOULD be used."
       ::= { ipiaIkeProposalEntry 10 }
   It would be good to add a UNIX clause "seconds" I guess.

   I am a bit surprised that if the default is 8 hours, why you would
   represent that by 0. But I can live with it. However is anything
   wrong using 
     DEFVAL { 0 }
   Or possibly even DEFVAL { 28880 } -- 8 hours

17. For ipiaIkePropMaxLifetimeKB, is a value of zero valid?
    If so what does it mean? Any other constraints?

18. For
   ipiaIpsecPropProtocolId OBJECT-TYPE
       SYNTAX      IpsecDoiSecProtocolId
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "The protocol Id for the transforms for this proposal.  The
            protoIsakmp(1) value is not valid for this object.  This
            object, along with the ipiaIpsecPropTransformsName, is the
            index into the ipiaIpsecTransformsTable."
       ::= { ipiaIpsecProposalsEntry 3 }

   I guess that the value zero is also no valid.
   In that case (assuming all other potential values are valid), one 
   could do a
       SYNTAX      IpsecDoiSecProtocolId(2..255)
   So that it is also machine-readable that protoIsakmp is not valid.
   If zero is also a valid value, then one can do
       SYNTAX      IpsecDoiSecProtocolId(0 | 2..255)

  Same for ipiaIpsecTranType

19. I see:
     ipiaAutoIkePriority  OBJECT-TYPE
       SYNTAX       Integer32 (0..65535)
    Since this is an INDEX object, I recommend to make it
       SYNTAX       Unsigned (0..65535)
20. For ipiaAutoIkeAddressType I wonder if DNS is a valid
     type. If so, then you MUST describe at what time name
     resolution is to take place. See RFC4001.
     Mmm... I see in the MODULE-COMPLIANCE that only IPv4/v6
     addresses need to be supported. But does that mean that
     dns cannot be supported?

21. When I see
   ipiaAutoIkeSourcePort OBJECT-TYPE
       SYNTAX        InetPortNumber
       MAX-ACCESS    read-create
       STATUS        current
       DESCRIPTION
           "The property ipiaAutoIkeSourcePort specifies the port
            number for the source port for auotstarting IKE SA's.

            The value of 0 for this object is illegal."
       ::= { ipiaAutostartIkeEntry 5 }

   Then I would use a SYNTAX InertPortNumber (1..65545)
   So that the illegal value is also detectable in machine
   readable form.

22. For 
 ipiaAutoIkeProtocol OBJECT-TYPE
     SYNTAX      Unsigned32 (0..255)
     MAX-ACCESS  read-create
     STATUS      current
     DESCRIPTION
         "The property Protocol specifies the protocol number used in
          comparing with policy filter entries and used in any phase
          2 negotiations."
     ::= { ipiaAutostartIkeEntry 8 }

  Are these protocol number maintained by IANA some place maybe?
  If so it woul dbe good to point to it.

23. I see
   ipiaIcmsPolicyStatement OBJECT-TYPE
       SYNTAX      OCTET STRING (SIZE(0..1024))
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This Value represents the Credential Management Service
            Policy Statement, or a reference describing how to obtain
            it (e.g., a URL).  If one doesn't exist, this value can be
            left blank"
       ::= { ipiaIpsecCredMngServiceEntry 3 }

  I am not sure what a 'blank value' is for an OCTET STRING.
  I could see/assume that it is the zero-length string. 
  If so, better be specific/explicit about it to avoid confusion.

  The use of 'empty' and 'blanl' for OCTET STRINGS (or TCs based
  on OCTET STRINGs) occurs many times. Pls check them all

24. So for
ipiaIcmsCredentialName OBJECT-TYPE
    SYNTAX      SnmpAdminString (SIZE(0..32))
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "This value is used as an index into the
         ipiaCredentialFilterTable to look up the actual credential
         value."
    ::= { ipiaIpsecCredMngServiceEntry 5 }

  what does a zero length string mean?
  Pls add that to the DESCRIPTION clause

25. I see:
   ipiaCmcDistributionPoint OBJECT-TYPE
       SYNTAX      OCTET STRING (SIZE(0..256))
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This Value represents a Distribution Point for a Credential
            Revocation List. It can be relative to the Credential
            Management Service or a full name (URL, e-mail, etc...)."

   So I wonder what a zero length string means in this object??

26. I see:
   ipiaCmcThisUpdate OBJECT-TYPE
       SYNTAX      OCTET STRING (SIZE(0..32))
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This value is the issue date of this CRL. This
            SHOULD be in utctime or generalizedtime."

   It would be good to have a REFERENCE clause to the
utctime/generalized
   time, and how you expect this OCTET-STRING to be formatted?
   This occurs multiple times in this MIB module.

27. Keith had asked:

   - ipiaIpsecCredMngServiceTable 
   - ipiaCredMngCRLTable 

   Please could they have consistent descriptors, i.e.,
   remove "Ipsec" from "ipiaIpsecCredMngServiceTable" 
   so that they are:

   - ipiaCredMngServiceTable 
   - ipiaCredMngCRLTable 

   I think that makes sense. I do not see why the string "Ipsec" 
   is needed in the ipiaIpsecCredMngServiceTable; But maybe I am
   missing something.

28. Keith had suggested (and for the IPSEC-SPD-MIB this have been
    applied) that

   xxxLastChanged OBJECT-TYPE
       SYNTAX      TimeStamp
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The value of sysUpTime when this row was last modified
            or created either through SNMP SETs or by some other
            external means."

   Would be changed to something like:

   xxxLastChanged OBJECT-TYPE
       SYNTAX      TimeStamp
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The value of sysUpTime when this row was last modified
            or created either through SNMP SETs or by some other
            external means.

            If this row has not been modified since the last
            re-initialization of the network management subsystem,
            this object SHOULD have a zero value."

   I think that makes sense, and so should be applid to the IKEACTION
   MIB as well. I would even change the SHOULD (you use that capitalize
   2119 termonolo0gy too often). SO I would even say:

   xxxLastChanged OBJECT-TYPE
       SYNTAX      TimeStamp
       MAX-ACCESS  read-only
       STATUS      current
       DESCRIPTION
           "The value of sysUpTime when this row was last modified
            or created either through SNMP SETs or by some other
            external means.

            If this row has not been modified since the last
            re-initialization of the network management subsystem,
            this object has a zero value."

29. Comments from Keith (he did send them to (at least a subset) of
    you all.
    I support these comments; I think I also have some of the
    same comments, either above, or below in my NITS section):

  Substantive Comments:

  1. None of the MODULE-COMPLIANCE statements apply to FC-SP, but that's
OK.
  Instead, FC-SP can specify its requirement for compliance to the 
  relevant subsets of both IPSP MIBs in the MODULE-COMPLIANCE statements

  in FC-SP's own MIB modules.  However, in order to do that, the IPSP 
  MIB modules need to define object groups with only the relevant 
  subsets, i.e., not containing other objects.  Specifically,

  a) the ipiaCredentialFilterGroup group, which contains the objects 
  from the ipiaIpsecCredMngServiceTable & ipiaCredMngCRLTable tables, 
  also contains objects from the ipiaCredentialFilterTable and 
  ipiaRevokedCertificateTable tables.  I request that the 
  ipiaCredentialFilterGroup be split up so that there is one object 
  group per table.

  b) the ipsaSharedGroup group which contains the objects in the 
  ipsaCredentialTable & ipsaCredentialSegmentTable tables also contains

  objects from the ipsaAhTransformTable, ipsaEspTransformTable, 
  ipsaIpcompTransformTable & ipsaPeerIdentityTable tables.  I request 
  that the ipsaSharedGroup be split up so that there is one object group

  per table.

  2. T11.5 has discussed the usefulness of a management application 
  being able to use managed objects in these MIB(s) to determine whether

  a CRL is still current, and that the simplest way to determine this is

  to compare the "CRL signature".  To facilitate this, I request that an

  object be added to the ipiaCredMngCRLTable to contain the 
  CRL-signature.  (Note that while such an extension could be defined in

  a FC-SP MIB module, it would seem wrong to do so because the extension

  is not specific to FC-SP.)

  3. It is necessary that the DESCRIPTION for the 
  ipiaIcmsPolicyStatement object explain how the value is formatted 
  within the OCTET STRING.

  4. A SIZE clause is needed on the SYNTAX of ipsaCredSegValue.

  Clarification/Editorial Comments

  5. It is helpful for a MIB module to contain REFERENCE clauses.
  These MIB modules contain REFERENCE clauses only for TC definitions, 
  none for any MIB objects.  To pick just one of many potential 
  examples, shouldn't ipiaIcmsPolicyStatement's definition have a 
  REFERENCE clause pointing to RFC 3280 ??

  6. ipiaCredMngCRLEntry's DECSRIPTION needs to specify (explicitly) 
  what is represented by the value of ipiaIcmsName in its INDEX clause.

  7. ipiaIpsecCredMngServiceTable's DESCRIPTION says that it is:

            "A table of Credential Management Service values.  This
             table is usually used for credential/certificate values
             that are used with a management service (e.g. Certificate
             Authorities)."

  it would be clearer if it explained (explicitly) that each row in this

  table represents one Credential Management Service.

  8. ipiaCmcDistributionPoint's DESCRIPTION says:

            "This Value represents a Distribution Point for a Credential
             Revocation List. It can be relative to the Credential
             Management Service or a full name (URL, e-mail, etc...)."

  a) the format needs to be specified,
  b) "it can be relative to ..." needs to be expanded to specify how to 
  determine if, and if so, to which of the cited examples it is
relative.
  c) the DESCRIPTION also needs to explain what it means to have the 
  zero-length string as the value of this object.

  9. ipiaCmcNextUpdate's DESCRIPTION says:

            "This value indicates the date the next version of this CRL
             will be issued. This SHOULD be in utctime or
             generalizedtime."

  a) REFERENCEs are needed for "utctime" and "generalizedtime",
  b) how is it determined which format is being used: utctime or
     generalizedtime?
  c) perhaps, it would be better to use the IETF-standardized
DateAndTime
     as the syntax ??  
  d) similarly for ipiaCmcThisUpdate.

  10. Several DESCRIPTIONs use the ambiguous terms: "blank", "null
string"
  and "empty".  One use of "empty" is clarified by appending "(0
length)".
  One use of "null string" is also clarified by appending "(0 length)".
  If "(0 length)" is the intended meaning for all such cases, then *all*

  such usages should be changed to be "zero-length string" (with the 
  words "blank", "null" and "empty" deleted).

  11. ipiaIcmsCredentialName's DESCRIPTION defines only how its value is

  used.  From this descripiton of its usage, the definition of what the 
  value actually means has to be infered.  This needsx to be changed so 
  that both the definition of what the value means and how it can be 
  used are explicitly defined.  Further, its syntax allows the value to 
  be the zero-length string which cannot be used in the prescribed
manner.
  Presumably, having the zero-length string as its value is appropriate 
  when the value is not intended to be looked up, as will be the case 
  for FC=SP.  Thus, the DESCRIPTION needs to be expanded to define the 
  meaning of the value and explicitly describe the case where the value 
  is the zero-length string, e.g., similarly to how 
  ipiaIkeIdCredentialName's DESCRIPTION does (but with "blank" changed 
  to "zero-length string".)

  12. The DESCRIPTION of ipsaCredMngName says:

            "This value is used as an index into the
             ipsaIpsecCredMngServiceTable.  For IDs that have no
             credential management service, this value is left blank."

  Each row in this table is (I think) for a "credential" -- it would be 
  helpful to explain the relationship between "IDs" and a row's 
  credential.

  13. The DECSRIPTION of ipsaCredRemoteID says:

           "This object represents the Identification (e.g. user name)
            of the user of the key information on the remote site.  If
            there is no ID associated with this credential, the value
            of this object SHOULD be the null string."

  Is "ID" a reference to "the Identification (e.g. user name) ... on the

  remote site", or is it a reference to the same "IDs" as in
ipsaCredMngName ??

  14. "allowble" in ipiaIcmsMaxChainLength's DESCRIPTION has a typo.

  Other Comments

  15. ipiaCredFiltAcceptCredFrom's DESCRIPTION says:

     ... This value is empty if there is no CA used for this filter.

   but its syntax is:

      SYNTAX      OCTET STRING(SIZE(1..117))

  Assuming the word "empty" will be rephrased as "zero-length string", 
  then the SYNTAX needs to allow a length of zero.

More comments as a result of comments I saw from Keith on the 
draft-ietf-ipsp-spd-mib-xx.txt, some of it has been applied
to rev 7 of that doc, some not. Anyway....

Keith worried about text in sect 4 (SPD MIB, also for sect 4
IKEACTION-MIB):

  This MIB module is a task specific derivation (i.e. an SMIv2
instantiation)
  of the IPCP's IPsec configuration model for use with SNMPv3.

I think it is better to 
   s/for use with SNMPv3/that can be used with SNMP/ 
Your security Considerations section takes care of any
possible use with SNMPv2c or SNMPv1, but certainly 
any future SNMPvx migth be able to support it (NO, I am not 
predicting or advocating an SNMPv4). Also an ISMS based usage
is foreseable. 

You may want to re-check the use of SYNTAX Integer32. According to
RFC4181 in several case use of Unsigned32 is recommended. I don't
think that your use of Integer32 is fatally flawed, but it is better
to follow the guidelines/recommendations.

-------- NITS and admins and questions

a. I see that the textual conventions are prefixed with Ike.
   I think I would prefer them to be prefixed with Ipia (same
   as mib module). But it is just a nit. I can live with it.
b. I see that IpsecDoiSecProtocolId TC does not follow the
   Ike prefix naming. Why is this TC not moved to the
   IPSEC-IPSECACTION-MIB so it sits together with the other 
   OpsecDoiXxx TCs?
c. I do not see why you would use capitalized MAY in the
   DESCRIPTION clause of ipiaCredentialFilterTable. A lower
   case "may" seems more than adequate to me.
d. In general I think the capitalize RFC2119 terms are OVERUSED 
   in various DESCRIPTION clauses.
e. For ipiaIkeActExchangeMode, I guess you could add some text
   (or better a REFERENCE clause to a document) explaining what
   'main' and 'aggressive' mean?
f. Various DESCRIPTION clause are "empty" or useless. For
   example:

   ipiaCredMngCRLEntry OBJECT-TYPE
       SYNTAX      IpiaCredMngCRLEntry
       MAX-ACCESS  not-accessible
       STATUS      current
       DESCRIPTION
           "A row in the ipiaCredMngCRLTable."

   Sure it is a row in this table. Can you say something about what
   sort of information is recorded/managed in such a row?

g. I see no need for the following. They are just empty placeholders
   --
   --
   -- Notification objects information
   --
   --

   ipiaNotificationVariables OBJECT IDENTIFIER ::=
      { ipiaNotificationObjects 1 }

   ipiaNotifications OBJECT IDENTIFIER ::=
      { ipiaNotificationObjects 0 }

   But... they do not harm, so if you want to keep them, fine.
   It just clutters the MIB module (which is big enough anyway).

------------- TYPOs   
  (appology that they are not always in order as they appear
   in the MIB module; I entered them here as I ran into them
   while jumping around to find references/pointers etc.)

  ipiaAutostartIkeTable OBJECT-TYPE
      SYNTAX      SEQUENCE OF IpiaAutostartIkeEntry
      MAX-ACCESS  not-accessible
      STATUS      current
      DESCRIPTION
          "The parameters in the autostart IKE Table are used to
           automatically initiate IKE phaes I and II (i.e. IPsec)

s/phaes/phases/

   ipiaIcmsMaxChainLength OBJECT-TYPE
       SYNTAX      Integer32 (0..255)
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "This value is the maximum length of the chain allowble from

s/allowble/allowable/

   ipiaIKECompliance MODULE-COMPLIANCE
       STATUS      current
       DESCRIPTION
           "The compliance statement for SNMP entities that include an
            IPsec MIB implementation and supports IKE actions.

            -- OBJECT ipiaAutoIkeAddressType
            -- SYNTAX InetAddreessType { ipv4(1), ipv6(2) }

s/InetAddreessType/InetAddressType/

   ipiaIkeActAgressiveModeGroupId OBJECT-TYPE
       SYNTAX           IkeGroupDescription
       MAX-ACCESS       read-create
       STATUS           current
       DESCRIPTION
           "The values to be used for Diffie-Hellman exchange."
       ::= { ipiaIkeActionEntry 5 }

s/values/value/ ?? I think in the instantiation of one object,
it represents only one value, no?

  ipiaIpsecActDoPacketLogging OBJECT-TYPE
      SYNTAX      SpdIPPacketLogging
      MAX-ACCESS  read-create
      STATUS      current
      DESCRIPTION

          "ipiaIpsecActDoPacketLogging specifies whether or not an
           audit message SHOULD be logged and if there is logging, how
           many bytes of the packet to place in the notification."

s/notification/log record/ ??

   ipiaIkeActDoPacketLogging OBJECT-TYPE
       SYNTAX      SpdIPPacketLogging
       MAX-ACCESS  read-create
       STATUS      current
       DESCRIPTION
           "ikeDoPacketLogging specifies whether or not an audit
            message SHOULD be logged and if there is logging, how many
            bytes of the packet to place in the notification."

s/notification/log record/ ??

Bert

_______________________________________________
MIB-DOCTORS mailing list
MIB-DOCTORS@ietf.org
https://www1.ietf.org/mailman/listinfo/mib-doctors