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

Re: FW: draft-ietf-sigtran-sctp-mib-09.txt



On Fri, 16 May 2003, Wijnen, Bert (Bert) wrote:
> Mike, do you have time to propose exact wording
> changes so that we would be happy.

OK, based on the following:

>    For now, only IPv4 and IPv6 need to be supported, but possibly
>    in the future we may also allow for IPv4z and IPv6z
> 
>    For now, only IPv4 and IPV6 need to be supported, but possibly
>    in the future other addresses may be supported.

and the fact that the conformance statements already require support
of IPv4z and IPv6z under certain circumstances, I've crafted the
following proposed wording changes.  For the benefit of the authors
and others who were not present when this was being discussed
off-line on the mreview list, the changes are intended to fix a few
perceived inaccuracies/inconsistencies and to get the MIB module to
conform to the following recommendation in Section 4.6.5 of
<draft-ietf-ops-mib-review-guidelines-01.txt>:

   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.

The option chosen in the proposed wording changes is to specify the
constraints in the relevant conceptual row DESCRIPTION clauses.  The
proposed changes apply to <draft-ietf-sigtran-sctp-mib-09.txt>.

========================================================

On page 8 (4th paragraph from the bottom) make the
following replacement:

OLD:

   Both sctpAssocLocalAddrTable and sctpAssocRemAddrTable are indexed by
   addresses. 'Addr' and 'AddrType' use the syntax InetAddress and
   InetAddressType defined in the Textual Conventions for Internet
   Network Address (RFC3291). In the general case this syntax is valid
   for Unknown IP addresses, IPv4, IPv6, non-global IPv4, non-global
   IPv6 address and DNS, but only the IPv4 and IPv6 address options are
   allowed in this MIB.

   DNS value is not used to identify an IP address since it is only
   valid during initialization (once this stage is finished, both sides
   only use IP addresses).

NEW:

   Both sctpAssocLocalAddrTable and sctpAssocRemAddrTable are indexed by
   addresses.  'Addr' and 'AddrType' objects use the syntax InetAddress
   and InetAddressType defined in the Textual Conventions for Internet
   Network Address (RFC 3291).  The InetAddressType TC has codepoints
   for unknown, IPv4, IPv6, non-global IPv4, non-global IPv6, and DNS
   addresses, but only the IPv4 and IPv6 address types are required to
   be supported by implementations of this MIB module.  Implementations
   that connect multiple zones are expected to support the non-global
   IPv4 and non-global IPv6 address types as well.

   Note that DNS addresses are not used in this MIB module.  They are
   always resolved to the on-the-wire form prior to connection setup,
   and the on-the-wire form is what appears in the MIB objects.

========================================================

On page 21:

- DELETE the following text from the DESCRIPTION clause
of sctpAssocRemPrimAddr:

          Only IPv4 and IPv6 addresses are expected.

========================================================

On pages 27, 28, and 29:

- DELETE the following text from the DESCRIPTION clauses
of sctpAssocLocalAddrType and sctpAssocRemAddrType:

          Only IPv4 and IPv6 addresses are expected.

- 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.

- INSERT the following text at the end of 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.

- INSERT the following text at the end of 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.

========================================================

On page 34:

- in the DESCRIPTION clause of sctpLookupRemPrimIPAddrEntry
make the following replacement:

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.

========================================================
On page 35:

- INSERT the following text at the end of 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.

========================================================

On page 40, update the text of Section 5 ("Compiling
Notes") as shown below:

OLD:

   When compiling the MIB the following type of warning can occur:

   . index of row 'sctpLookupRemPrimIPAddrEntry' can exceed OID size
      limit by 141 subidentifier(s)

   This is due to the fact that sctpAssocRemPrimAddr has the default
   InetAddress size of (0..255), which exceeds OID size limitations.
   Introducing a size restriction on sctpAssocRemPrimAddr would make the
   warning go away -                   - although it would be one of those arbitrary
   restrictions.

NEW:

   When compiling the MIB module warnings similar to the following may
   occur:

   warning: index of row `sctpAssocLocalAddrEntry' can exceed OID
      size limit by 141 subidentifier(s)
   warning: index of row `sctpAssocRemAddrEntry' can exceed OID
      size limit by 141 subidentifier(s)
   warning: index of row `sctpLookupRemPrimIPAddrEntry' can exceed OID
      size limit by 141 subidentifier(s)
   warning: index of row `sctpLookupRemIPAddrEntry' can exceed OID
      size limit by 141 subidentifier(s)

   These warnings are due to the fact that the row objects have index
   objects of type InetAddress whose size limit is 255 octets, and if
   that size limit were reached the names of column instances in those
   rows would exceed the 128 sub-identifier limit imposed by current
   versions of the SNMP.  Actual limitations for the index object sizes
   are noted in the conceptual row DESCRIPTION clauses, and will not be
   reached with any of the address types in current use.

========================================================

Notes:

The purpose in avoiding explicit mention of address types in the object
DESCRIPTION clauses is so that new address types that are introduced in
the future can be supported without having to make changes to the
DESCRIPTION clauses that would change the semantics of the objects.
Such changes are not allowed by the SMI.  The compliance statement
already make clear what is required to be supported by this version of
the MIB module, and new compliance statements can be written if future
developments warrant.

Finally, the proposed wording changes are NOT intended to change the
design, but only to clarify things for potential implementors.  If
the authors feel that something in the proposal is incorrect they
should push back.

Thanks,

Mike Heard