[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Last Call: Stream Control Transmission Protocol Management Information Base to Proposed Standard
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
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
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?