RE: Last Call: Stream Control Transmission Protocol Management Information Base to Proposed Standard

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

Trying to come up with a resolution (between the MIB doctors first,
so I dropped IESG). 

Mike responded at some point:
> If this is seen as an issue, then the solution is to document the
> constraints that the index object lengths must satisfy through means
> other than explicit SIZE constraints.  Here was the language that
> was recently proposed for the InetAddress TC DESCRIPTION clause in
> RFC 3291bis:
> 
>        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 if there is no single DESCRIPTION
>        clause that is appropriate.
> 
> Note that draft-ietf-sigtran-sctp-mib-09.txt doesn't document the
> size constraints as suggested above;  it just documents the fact
> that MIB compiler warnings may appear, which is substantially less
> useful.
> 
Based on the above, I think the best thing to do is to propose
text for the various DESCRIPTION clauses that would address the issue.
(in fact I think the doc already has it, but maybe text can be
 improved).

We came to consensus (or so I thought) that people MUST do one
of two things (as per above new text for InetAddress):
  - Add a SIZE retriction, OR
  - DESCRIBE the applicable constraints in an appropriate place.

What I see is:

  - Page 8 talks about only IPv4/IPv6 and unknown addresses to be
    valid for the current MIB module. Maybe it needs to add some
    text for explaining SIZE constraints as well?

  - DESCRIPTION clauses of sctpAssocLocalAddr and sctpAssocRemAddr,
    and sctpLookupRemPrimIPAddrEntry contain a discussion on the
    SIZE constraints. We have clearly allowed for that in the
    proposed new text for InetAddress above and so I do not see
    why we need to force them to remove the text and use a SIZE
    clause instead (as Mike suggested).
    Is it that we feel the text is not clear enuf?

In other words, if we give people a choice of two options, why
would we enforce one of them?

Bert