Re: draft-ops-endpoint-mib-06.txt example syntax?

[Keith McCloghrie <kzm@cisco.com>]

Regarding the SMI,

> The funny thing here is that both compilers accept
> 
>     OBJECT  peerAddress
>     SYNTAX  InetAddress (SIZE(4|16))
> 
> as valid while
> 
>     OBJECT  peerAddressType
>     SYNTAX  InetAddressType { ipv4(1), ipv6(2) }
> 
> is rejected as invalid. That is, you can add a size restriction for a
> TC by using the TC name but you can't refine the list of enumerated
> values for a TC by using the TC name. Sounds a bit odd.

I agree that's odd.  There are SMI rules which are different for different
types of refinement.

> While writing a real MIB around the fragment in the ID, I also
> discovered another interesting question. The MIB suggests to define a
> refinement in a compliance statement for an INDEX object which has a
> max access of not-accessible. Using SMICng I did run into some trouble
> because
> 
> (a) it insists that the object to be refined is a member of an
>     OBJECT-GROUP (I guess because of RFC 2580 section 5.4.3),
>     and
> 
> (b) it does not allow to put a not-accessible object into an
>     OBJECT-GROUP (I guess because of RFC 2580 section 3.1).
> 
> Which basically means that the SMIv2 does not allow to refine the
> syntax for objects that are not-accessible because they are INDEX
> objects. I do not think this was the intention of the SMIv2. Looks
> like the rule in RFC 2580 section 3.1 is over ambitious.
> 
> Dave, Keith, any comments on this?

It is common practice that not-accessible objects are never put into an 
OBJECT-GROUP.  However, that's not what section 3.1 actually says:

   It is required that every object defined in an information module
   with a MAX-ACCESS clause other than "not-accessible" be contained in
   at least one object group.  This avoids the common error of adding a
   new object to an information module and forgetting to add the new
   object to a group.

Note that the rationale behind not putting not-accessible objects in an
OBJECT-GROUP is that you cannot Get/Set a not-accessible object, and so
compliance cannot require access to it, nor can compliance be verified,
at least not directly.  (It could be argued that an not-accessible
object can be accessed/verified indirectly through the columnar objects
in the table for which it is an INDEX, but those columnar objects need
to be in an OBJECT-GROUP anyway, and so indirect accessing/verifying is
redundant.)

Keith.