FW: Re: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt

Has this got any impact on the policy config doc?  We need a response
on this issue.

Hilarie

  ---Forwarded Message Follows---
From: "C. M. Heard" <[email protected]>
To: IPsec WG <[email protected]>
cc: "Wijnen, Bert (Bert)" <[email protected]>
Subject: Re: Important question about draft-ietf-ipsec-doi-tc-mib-07.txt

[ authors of draft-ietf-ipsp-ipsec-conf-mib-06.txt bcc'd;  ]
[ please direct all discussion to [email protected]  ]

Summary of the discussion so far:  I have pointed out to the WG that
all of the enumerated INTEGER TCs in the IPSEC-ISAKMP-IKE-DOI-TC MIB
module in <draft-ietf-ipsec-doi-tc-mib-07.txt> (except for
IsakmpCertificateEncoding) are intended to represent data items that
have a certain range of values reserved for "private use amongst
cooperating systems."  Since values in these ranges are not subject
to standardization, there will be no enumerations for them.
However,  SMIv2 rules require (and MIB users/authors expect) that
objects defined with an enumerated INTEGER syntax will assume only
those values that are named in the enumeration list.  I have
therefore advised the WG (in my role as MIB reviewer) that the
SYNTAX value of all of the enumerated INTEGER TCs in the
IPSEC-ISAKMP-IKE-DOI-TC MIB module be changed to the appropriate
Unsigned32 subrange with the usages of the various ranges spelled
out in the DESCRIPTION clause (as is done now) and a pointer to the
IANA registry included.  This approach, which is the also used in
the SnmpSecurityModel TC from the SNMP-FRAMEWORK-MIB in RFC 3411,
has the added advantage of not imposing any extra workload on the
IANA to supplement or reorganize the existing IPsec and ISAKMP
registries.  The disadvantage of this approach is that applications
such as MIB browsers that don't have any built-in knowledge of the
underlying MIB objects can only display the integer value and not
the enumeration label, which makes the MIB modules harder to use.

This discussion has been dormant for about a week, and I do need to
proceed with finalization of my MIB review comments for the ADs.  So
unless I hear some very convincing arguments to the contrary before
Tuesday, 22 April 2003, my review comments will advise that all the
enumerated INTEGER TCs in the IPSEC-ISAKMP-IKE-DOI-TC have the
SYNTAX value changed to the appropriate Unsigned32 subrange, and
that the MIB module be maintained by the WG, not by IANA.

I am aware of the following Internet Drafts that contain MIB modules
which use one or more of the TCs defined in IPSEC-ISAKMP-IKE-DOI-TC:

draft-ietf-ipsec-ike-monitor-mib-04.txt
draft-ietf-ipsec-isakmp-di-mon-mib-05.txt
draft-ietf-ipsec-monitor-mib-06.txt
draft-ietf-ipsp-ipsec-conf-mib-06.txt

Of these, it appears that only the last one would be affected by
the changes I intend to recommend.  It would be necessary to
change the object definition

ipspSaPreActActionType OBJECT-TYPE
    SYNTAX      IpsecDoiEncapsulationMode
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "This object specifies the encapsulation mode to use for the
         preconfigured SA: tunnel or transport mode."
    DEFVAL { tunnel }
    ::= { ipspSaPreconfiguredActionEntry 9 }

to

ipspSaPreActActionType OBJECT-TYPE
    SYNTAX      IpsecDoiEncapsulationMode
    MAX-ACCESS  read-create
    STATUS      current
    DESCRIPTION
        "This object specifies the encapsulation mode to use for the
         preconfigured SA: tunnel or transport mode."
    DEFVAL { 1 } -- tunnel
    ::= { ipspSaPreconfiguredActionEntry 9 }

Regards,

Mike Heard