[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Is enumeration syntax refinement legal with a TC?
Howdy,
Another issue has come up where it's not so clear to me what to
write in the MIB author's and reviewer's guide. Let me apologize
in advance if this topic has already been discussed in the past
and was already settled. I did look on the SMIv2 design team web
pages and in the mibs@ops.ietf.org archive, but all I found were
the following messages
http://ops.ietf.org/lists/mibs/mibs.2000/msg00057.html
http://ops.ietf.org/lists/mibs/mibs.2000/msg00059.html
http://ops.ietf.org/lists/mibs/mibs.2000/msg00060.html
http://ops.ietf.org/lists/mibs/mibs.2000/msg00061.html
http://ops.ietf.org/lists/mibs/mibs.2000/msg00062.html
and the discussion did not seem to be conclusive.
Anyway, I just recently noticed (because Mike Kirkham brought it
to my attention) that the refinement to ifStackStatus in RFC 2863
(IF-MIB) is written like this:
OBJECT ifStackStatus
SYNTAX INTEGER { active(1) } -- subset of RowStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and only one of the six
enumerated values for the RowStatus textual convention
need be supported, specifically: active(1)."
instead of like this:
OBJECT ifStackStatus
SYNTAX RowStatus { active(1) } -- subset of RowStatus
MIN-ACCESS read-only
DESCRIPTION
"Write access is not required, and only one of the six
enumerated values for the RowStatus textual convention need
be supported, specifically: active(1)."
The latter form is allowed by some MIB compilers, notably smilint,
but is treated as a syntax error by others, notably mosy and the
version of SMICng that I have available (2.2.07). mosy I'd write
off, but SMICng (even older versions) I take very seriously, so I
looked at the SMIv2 documents to see what they have to say about
this. Unfortunately this is one of the areas where those documents
are not as explicit as they should be.
As best I can determine, the only explicit rules governing such
usage are specified in RFC 2578 Section 9 (syntax refinements) and
Appendix A (sub-typing, which is a subset of syntax refinement).
These sections explicitly mention only the base types. RFC 2579
covers only what's allowed in the SYNTAX clause of a TC (in sections
3.5 and 4) and not how a the rules apply when a TC is used. RFC
2580 just points back to RFC 2578 Section 9.
Since the SMIv2 documents don't explicitly say what specific kinds
of syntax refinements are allowed with TCs one may reasonably
conclude that the rules incorporated by references from ASN.1 (1988)
would apply.
Now, the content of a SYNTAX clause for an OBJECT-TYPE, a
TEXTUAL-CONVENTION, an OBJECT clause in a MODULE-COMPLIANCE
statement, or a VARIATION clause in an AGENT-CAPABALITIES
statement is defined in all cases by the following ASN.1
productionreference sequence:
Syntax ::= -- Must be one of the following:
-- a base type (or its refinement), or except in TCs
-- a textual convention (or its refinement), or
-- a BITS pseudo-type
type
| "BITS" "{" NamedBits "}"
NamedBits ::= NamedBit
| NamedBits "," NamedBit
NamedBit ::= identifier "(" number ")" -- number is nonnegative
The text is the same in all of those MACROs except TEXTUAL-CONVENTION,
where a TC isn't allowed; I've indicated this in the ASN.1 comment.
One sees from this that the keyword "type" encompasses everything
other than the BITS construct. According to X.208, ``the keyword
"type" shall be used to specify that each instance of the new
notation contains at this point, using standard ASN.1 notation, some
"Type".'' "Type" is the ASN.1 production that covers what's allowed
in the standard ASN.1 notation for types.
Now, the only types for which ASN.1 allows the enumeration notation
are INTEGER, ENUMERATED, and BIT STRING, and of these only the
INTEGER type is allowed in SMI constructs. Note in particular that
this notation is not allowed with a DefinedType, of which a TC is
a particular case. Sub-typing is allowed, but it covers only size
and range refinements, and is limited to the extended subset defined
in Appendix A of RFC 2578. Thus, constructs such as
RowStatus { active(1) }
are not allowed under the ASN.1 rules that are incorporated into RFC
2578 by reference.
The point of bringing this is not to be pedantic -- the point is
that a careful implementor, by following the rules that either are
written down or incorporated by reference into the SMIv2 documents,
would treat such constructs as syntax errors. And there is a hint
in RFC 2578 Section 7.1.1 that this is indeed the correct treatment:
enumerations are allowed with INTEGER but not with Integer32.
The bottom line for me, of course, is what should be allowed in
MIB reviews. My point of view is that unless there is a compelling
reason to do otherwise, all IETF MIB modules should compile without
error when fed to a MIB compiler that is written according to the
rules in the IETF documents that define the SMI. So, if I saw a
construct like the one above, I would tell the author to change it
the form used in RFC 2863, viz.,
INTEGER { active(1) } -- subset of RowStatus
It seems, however, that there are experts who would not agree.
For instance, I happened to run across this in a message from
Bert to the ipcdn list, regarding an AD review of the DOCSIS
Subscriber Management MIB:
> - Why have you commented out (in the MODULE COMPLIANCE)
> -- SYNTAX InetAddressType { ipv4(1) }
> because if you only requite support for IPv4, then that is
> exactly how you specify it in the MIB. I know that some older
> version of SMICng complians about it... but you can ignore that
> error/warning. See for example RFC3289 that uses it too.
Evidently in response to that comment, the current version
of the DOCSIS Subscriber Management MIB that's in
draft-ietf-ipcdn-subscriber-mib-07.txt uses the construct
that I find questionable construct in three places:
1222: SYNTAX InetAddressType { ipv4(1) }
1234: SYNTAX InetAddressType { ipv4(1) }
1264: SYNTAX StorageType { nonVolatile(3) }
Similar usage exists in the MIB modules in RFC 3289, RFC 2925, and
possibly other RFCs, and is recommended in RFC 3291. So it seems
that a de-facto extension to the SMIv2 syntax rules has crept into
the existing MIB module base.
I am not comfortable with the idea of saying in the MIB review
guidelines that this practice is OK, because it does seem to violate
the SMIv2 specs (which we have no charter to extend), and there is
a simple alternative. On the other hand, other than causing MIB
compilation errors, the practice not only is benign, it probably
should have been explicitly allowed (and indeed, encouraged) by the
SMIv2 documents. So, I would like to hear the opinions of the
other people on this list.
Thanks for your patience.
Mike