[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FW: draft-ietf-sigtran-sctp-mib-09.txt
Hi Bert,
We plan to have a new version by mid this week, Thursday as maximum.
br,
MCarmen
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: lunes, 02 de junio de 2003 12:05
To: Javier Pastor-Balbas (ECE); Maria-Carmen Belinchon-Vergara (ECE)
Cc: Mreview (E-mail); LyOng@ciena.com; mankin@psg.com;
jon.peterson@neustar.biz; shawn.routhier@windriver.com; C. M. Heard;
'Wijnen, Bert (Bert)'
Subject: RE: FW: draft-ietf-sigtran-sctp-mib-09.txt
Any idea when we can expect the new revision?
I will go on vacation next week... and probably for 3 weeks.
Thanks,
Bert
> -----Original Message-----
> From: Javier Pastor-Balbas (ECE)
> [mailto:javier.pastor-balbas@ece.ericsson.se]
> Sent: maandag 26 mei 2003 9:14
> To: 'Wijnen, Bert (Bert)'; C. M. Heard
> Cc: Mreview (E-mail); LyOng@ciena.com; mankin@psg.com;
> jon.peterson@neustar.biz; shawn.routhier@windriver.com; Maria-Carmen
> Belinchon-Vergara (ECE)
> Subject: 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
> > >
> >
>