Hi,

I think in IPSEC-SPD-MIB (RFC 4807) there is a
SMI syntax error that is difficult to fix without
breaking existing implementations (or updating RFC 2578)
and which points to a general problem with the
VariablePointer TC and default values (DEFVAL clause)
in SMIv2.

The error in the extracted MIB file is:
"Illegal object identifier assignment of spdTrueFilterInstance at
line 1041, column 1 under spdTrueFilter
for the object ID 1.3.6.1.2.1.153.1.7.1.0 (RFC2578 §7.10 et al.)"

The corresponding definitions of IPSEC-SPD-MIB are:

spdTrueFilter OBJECT-TYPE
SYNTAX Integer32 (1)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This scalar indicates a (automatic) true result for
a filter. That is, this is a filter that is always
true; it is useful for adding as a default filter for a
default action or a set of actions."
::= { spdStaticFilters 1 }

spdTrueFilterInstance OBJECT IDENTIFIER ::= { spdTrueFilter 0 }

spdGroupContFilter OBJECT-TYPE
SYNTAX VariablePointer
MAX-ACCESS read-create
STATUS current
DESCRIPTION

"spdGroupContFilter points to a filter that is evaluated
....
packet MUST be dropped."
REFERENCE "RFC 3289"
DEFVAL { spdTrueFilterInstance }
::= { spdGroupContentsEntry 3 }


My understanding from RFC2578 §7.10 and §3.6(1-2) is that
the OBJECT IDENTIFIER assignment spdTrueFilterInstance is
illegal because of §7.10(3):

(3) Otherwise, no other OBJECT IDENTIFIERs which are subordinate to the
object may be assigned.

Here is §3.6(1-2):

3.6. OBJECT IDENTIFIER usage
OBJECT IDENTIFIERs are used in information modules in two ways:

(1) registration: the definition of a particular item is registered as
a particular OBJECT IDENTIFIER value, and associated with a
particular descriptor. After such a registration, the semantics
thereby associated with the value are not allowed to change, the
OBJECT IDENTIFIER can not be used for any other registration, and
the descriptor can not be changed nor associated with any other
registration. The following macros result in a registration:

OBJECT-TYPE, MODULE-IDENTITY, NOTIFICATION-TYPE, OBJECT-GROUP,
OBJECT-IDENTITY, NOTIFICATION-GROUP, MODULE-COMPLIANCE,
AGENT-CAPABILITIES.

(2) assignment: a descriptor can be assigned to a particular OBJECT
IDENTIFIER value. For this usage, the semantics associated with
the OBJECT IDENTIFIER value is not allowed to change, and a
descriptor assigned to a particular OBJECT IDENTIFIER value cannot
subsequently be assigned to another. However, multiple descriptors
can be assigned to the same OBJECT IDENTIFIER value. Such
assignments are specified in the following manner:

mib OBJECT IDENTIFIER ::= { mgmt 1 } -- from RFC1156
mib-2 OBJECT IDENTIFIER ::= { mgmt 1 } -- from RFC1213
fredRouter OBJECT IDENTIFIER ::= { flintStones 1 1 }
barneySwitch OBJECT IDENTIFIER ::= { flintStones bedrock(2) 1 }

Note while the above examples are legal, the following is not:

dinoHost OBJECT IDENTIFIER ::= { flintStones bedrock 2 }

A descriptor is allowed to be associated with both a registration and
an assignment, providing both are associated with the same OBJECT
IDENTIFIER value and semantics.


To solve the issue without changing implementations
of the IPSEC-SPD-MIB, I would relax rule RFC2578 §7.10(3)
to allow OBJECT IDENTIFIER assignments below an OBJECT-TYPE
definition while not allowing any object registrations
(RFC 2578 §3.6(1)) below a scalar OBJECT-TYPE.

Do I understand RFC 2578 correctly?

Regards,
Frank Fock