[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

SIZE constraint language for InetAddress index objects indraft-ietf-ops-rfc3291bis-00.txt



Greetings,

I notice that the DESCRIPTION clause of the InetAddress textual
convention in the recently-posted draft-ietf-ops-rfc3291bis-00.txt
still has the following proviso:

         When this textual convention is used as the syntax of an
         index object, there may be issues with the limit of 128
         sub-identifiers specified in SMIv2, STD 58. In this case,
         the object definition MUST include a 'SIZE' clause to
         limit the number of potential instance sub-identifiers."

This conflicts with the advice in Section 4.6.5 of
draft-ietf-ops-mib-review-guidelines-01.txt ("OID Length
Limitations and Table Indexing"):

   It is RECOMMENDED that all MIB documents make explicit any
   limitations on index component lengths that management software
   must observe.  This may be done either by including SIZE
   constraints on the index components or by specifying applicable
   constraints in the conceptual row DESCRIPTION clause or in the
   surrounding documentation.

This somewhat less restrictive guideline was adopted after much
discussion among the MIB doctors because a blanket rule to include
SIZE constraints that guarantee that the 128 sub-identifier limit
is not breached is not always workable when there are multiple
variable-length index components.  So, I'd like to suggest that
the last paragraph of the DESCRIPTION clause of the InetAddress
textual convention be reworded as follows:

         When this textual convention is used as the syntax of an
         index object, there may be issues with the limit of 128
         sub-identifiers specified in SMIv2, STD 58. In this case,
         the object definition MUST include a 'SIZE' clause to
         limit the number of potential instance sub-identifiers
         or else the applicable constraints MUST be stated in the
         appropriate conceptual row DESCRIPTION clauses or in the
         surrounding documentation."

//cmh