[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FW: draft-ietf-sigtran-sctp-mib-09.txt
Thanks guys,
We'll share with you the new version before submission to make sure you agree on the changes (esp. the security ones).
Thanks again // Javier.
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: sábado, 17 de mayo de 2003 0:14
> To: C. M. Heard; 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); Javier Pastor-Balbas (ECE)
> Subject: RE: FW: draft-ietf-sigtran-sctp-mib-09.txt
>
>
> 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
> >
>