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

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

On Mon, 12 May 2003, Wijnen, Bert (Bert) wrote:
> OK... what we need to do is this.
> 
> - Verify what they mean. I think they mean to say that for now
>   only IPv4 and IPv6 need to be supported (maybe also IPv4z
>   and IPv6z, we should check that).

Agreed.  My reading of the MIB module (as opposed to the text on
page 8) was that ipv4, ipv6, ipv4z, and ipv6z are valid but only
ipv4 and ipv6 are required;  unknown and dns are pretty clearly
considered invalid;  and it was unclear whether to-be-defined
address types are are excluded or not.  The following discussion
assumes that to-be-defined address types are not excluded.

> - If that is the case, then I would strongly suggest to NOT use
>   the SIZE (0..114) bur rather use some text in DESCRIPTION to
>   warn that current SNMP version do not support OIDs longer
>   than 128 subIDs, so one must take that into account.

OK, but I would be find it unsatisfactory if the descriptive text
(wherever it happened to be located) did not specifically state that
the size limit is 114 octets.  Our consensus text in Section 4.6.5
of the review guidelines draft says:

   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.

I take the word "explicit" mean that there should be enough
information in the document to compute the length limitations
without having to actually dissect the MIB module.  If one prefers
text in the conceptual row DESCRIPTIOn clauses, then the folowing
set of changes would be a way to do that in the present case:

- delete the following text from the DESCRIPTION clauses of
sctpAssocLocalAddr and sctpAssocRemAddr:

           Theoretically this could result in a more than 128 subid
          index, but that in practice it is only required to support
          IPv4 and IPv6 addresses, so it would never be more than 20
          octets.

- add the following text to the DESCRIPTION clause of
sctpAssocLocalAddrEntry:

          Implementors need to be aware that if the size
          of sctpAssocLocalAddr exceeds 114 octets then OIDs
          of column instances in this table will have more
          than 128 sub-identifiers and cannot be accessed
          using SNMPv1, SNMPv2c, or SNMPv3.

- add the following text to the DESCRIPTION clause of
sctpAssocRemAddrEntry:

          Implementors need to be aware that if the size
          of sctpAssocRemAddr exceeds 114 octets then OIDs
          of column instances in this table will have more
          than 128 sub-identifiers and cannot be accessed
          using SNMPv1, SNMPv2c, or SNMPv3.

- in the DESCRIPTION clause of sctpLookupRemPrimIPAddrEntry change
the following text:

OLD:
          Theoretically this could result in a more than 128 subid
          index, but that in practice it is only required to support
          IPv4 and IPv6 addresses, so it would be always below the
          limit.

NEW:
          Implementors need to be aware that if the size of
          sctpAssocRemPrimAddr exceeds 114 octets then OIDs
          of column instances in this table will have more
          than 128 sub-identifiers and cannot be accessed
          using SNMPv1, SNMPv2c, or SNMPv3.

Note in the last case that the index object sctpAssocRemPrimAddr
appears as a read-only column in a different table.

If one settles for descriptive text in lieu of SIZE constraints I
would be content to see something like this in the surrounding
documentation (with the vague "theoretically ..." stuff removed
from the three places indicated above):

   Implementors of this MIB module must to be aware that
   if the size of sctpAssocLocalAddr, sctpAssocRemAddr,
   or sctpAssocRemPrimAddr exceeds 114 octets, then OIDs
   of column instances in the sctpAssocLocalAddrTable,
   sctpAssocRemAddrTable, or sctpLookupRemPrimIPAddrTable
   respectively will have more than 128 sub-identifiers
   and cannot be accessed using SNMPv1, SNMPv2c, or SNMPv3.

> - The DESCRIPTION clauses also only say that currently only
>   IPv4/6 need to be supported.

Hmm, I would think that object DESCRIPTION clauses should NOT say
this if one wishes to allow for stronger compliance statements in
the future -- removing text from an object DESCRIPTION that says
only IPv4/6 need to be supported seems to me to be a semantic
change, and that should be avoided.  The compliance statement
DESCRIPTION clause and surrounding documentation already say this
and in my opinion that is enough.

> - The COMPLIANCE specifies exactly the types to be supported and
>   the proper SIZEs that go with that.

I think that has already been done.

> It is too bad, but it may very well be fastest if we check/verify
> the first sentence first, and then do exact proposals for text
> changes, aka
> 
> OLD
>   ....
> NEW
>   ....

I saw that you sent an e-mail yesterday to take care of the first
part, and I have tried here to get a head start on the second part
(anticipating a particular answer).  So now we wait, I guess.

Thanks,

Mike