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

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