RE: SIZE constraint language for InetAddress index objects in draft-ietf-ops-rfc3291bis-00.txt

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Inline
Mike writes:
> 
> 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."
> 
I agree that a change makes sense. I think however that I would
remove "or in the surrounding documentation"

Mike, can you explain why you added that? 
I think I rather see it in the DESCRIPTION clause, so it does not
get lost when people extract the mib module from an RFC.

Bert