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

["C. M. Heard" <heard@pobox.com>]

On Fri, 18 Apr 2003, Wes Hardaker wrote:
> On Fri, 18 Apr 2003, C. M. Heard wrote:
> 
> Wes> In fact, the agent that receives a value outside the legal range
> Wes> of values will already have to return the exact same error to
> Wes> the management app that sent an illegal value in the first
> Wes> place.
> 
> C> Depending on what you mean by "the legal range of values" this can
> C> be a problem.  If you mean "the values in the enum list that are
> C> know to the agent" (which is the behaviour mandated by RFC 2578
> C> Section 7.1.1) then this IS a problem because for the DOI TCs the
> C> agent should ACCEPT any value that is within the range defined for
> C> the underlying protocol data item if (a) it does not require special
> C> knowledge on the part of the agent to process it or (b) it is in the
> C> "private use" range and the agent knows what to do with it.  Note
> C> that in the latter case in particular, the value is _valid_ even
> C> though it does not appear in the enum list.  Now, one could code
> C> around this problem, but that won't be conformant to RFC 2578
> C> Section 7.1.1, which says that "only those named-numbers so
> C> enumerated may be present as a value."
> 
> Ok, then how about changing my suggestion to:
> 
>   As described in RFC 2407 section 4.4.1, the range of values that
>   will be assigned by IANA for use in this TEXTUAL-CONVENTION and the
>   IPsec DOI will fall between 0 and 248, while legal values on the
>   wire may fall between 0 and 255.  Values in the range 249-255 will
>   not be utilized within IETF standardization documents as they have
>   been reserved by the IPsec DOI for private use by cooperating
>   devices.  All use of deviations from the standardized list of
>   enumerations, including those that fall in the 249-255 range, must
>   be documented within the appropriate AGENT-CAPABILITIES statements.
> 
> This documents that values from 249-255 won't be standardized, are
> intended for use by private organizations, and finally reminds the
> agent implementers that these other accepted/used values must be
> documented in the standard way in which all agents are supposed to
> document their deviation from a standardized SMIv2 document.

There are a couple of problem with this proposal that I'd like to
point out.  For concreteness, note that the specific TC to which
this suggestion pertains is IpsecDoiSecProtocolId, whose definition
is as follows:

 IpsecDoiSecProtocolId ::= TEXTUAL-CONVENTION
     STATUS      current
     DESCRIPTION "These are the IPsec DOI values for the Protocol-Id
                 field in an ISAKMP Proposal Payload, and in all
                 Notification Payloads.

                 They are also used as the Protocol-ID In the
                 Notification Payload and the Delete Payload.

                 The values 249-255 are reserved for private use
                 amongst cooperating systems."
     REFERENCE   "RFC 2407 section 4.4.1"
     SYNTAX      INTEGER {
                     reserved(0),        -- reserved in DOI
                     protoIsakmp(1),     -- message protection
                                         -- required during Phase I
                                         -- of the IKE protocol
                     protoIpsecAh(2),    -- IP packet authentication
                                         -- via Authentication Header
                     protoIpsecEsp(3),   -- IP packet confidentiality
                                         -- via Encapsulating
                                         -- Security Payload
                     protoIpcomp(4)      -- IP payload compression
                 }

Presumably, the proposed text is intended to replace the third
paragraph of the DESCRIPTION clause of this TC.  (As an aside, note
that the proposed text should point to RFC 2407 section 6.3 rather
than 4.4.1 and that the REFERENCE clause should mention section 6.3
as well as 4.4.1).

Observe that it is not permissible to specify something like this

         SYNTAX  IpsecDoiSecProtocolId {
                     protoIsakmp(1),
                     protoIpsecAh(2),
                     protoIpsecEsp(3),
                     protoIpcomp(4),
                     protoIpsecCompanyProprietary(249)
                 }

in a VARIATION clause of an AGENT-CAPABILITIES statement.  That is
an illegal refinement, and at least some MIB compilers (SMICng is
one) will reject it.  The same is true, of course, of WRITE-SYNTAX.
So the only way to document deviations from the standardized list of
enumerations within an AGENT-CAPABILITIES statement is to do it in a
DESCRIPTION clause.  That can be done in a VARIATION description for
objects that have a MAX-ACCESS value greater than not-accessible,
but must be done in the AGENT-CAPABILITIES description for index
objects that have a MAX-ACCESS value of not-accessible because
VARIATION clauses are not allowed for such objects.  As it turns
out, all but one of the uses of this TC in the three MIB modules
that use it (and both of the uses in the IPSEC-POLICY-MIB) are in
the definitions of inaccessible index objects, so the state of
affairs is not a very satisfactory one.

Very similar limitations apply to MODULE-COMPLIANCE statements.

My conclusion is still that use of enumerated INTEGER in a manner
that is inconsistent with the semantics defined in the SMIv2 RFCs
is something to be avoided.  Yes, it can probably be made to work
over the wire, but it messes up the meaning not only of object
definitions, but also of compliance statements and capabilities
statements.  It is hard to predict how it will interact with tools
such as automated code generators for method routines or indexing
routines that expect standards-compliant behaviour.  In my opinion,
such practices have no place in standards-track MIB modules;
implementors have a right to expect standards-compliant behaviour.

Regards,

//cmh