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

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

Thanks Mike. I think those are reasonable (and also to my
undertsanding) only clarifying editorial changes. So once these
are done, I think they will address the comments that were raised
during IETF Last Call.

Let me also remind the authors, that we had agreed that
   sctpAssocRemHostName OBJECT-TYPE
     SYNTAX         OCTET STRING (SIZE(0..115))
     MAX-ACCESS     read-only
     STATUS         current
     DESCRIPTION
          "The peer's DNS name. This object needs to have the same
          format as the encoding in the DNS protocol. This implies that
          the domain name can be up to 255 octets long, each octet being
          0<=x<=255 as value with US-ASCII A-Z having a case insensitive
          matching.

Needed to be changed to allow for a size of (0..255). And I think
this raises another issue that the index in sctpLookupRemHostNameTable
will possibly go over 128 subIDs, so there should be some text in there
that explains that users should be carefull not to use hostnames that
are longer than 115 for now (e.g. while using SNMPv1/v2c or v3).

Mike, is that OK with you too?

Thanks,
Bert 

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: vrijdag 16 mei 2003 18:43
> To: Wijnen, Bert (Bert)
> Cc: Mreview (E-mail); LyOng@ciena.com; mankin@psg.com;
> jon.peterson@neustar.biz; shawn.routhier@windriver.com;
> maria-carmen.belinchon-vergara@ece.ericsson.se;
> javier.pastor-balbas@ece.ericsson.se
> Subject: 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
>