[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FW: draft-ietf-sigtran-sctp-mib-09.txt - rev 10b included
Ok, no problem with that. We´ll include your wording.
Thanks // Javier.
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: martes, 03 de junio de 2003 14:35
> 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
> Subject: RE: FW: draft-ietf-sigtran-sctp-mib-09.txt - rev 10b included
>
>
> W.r.t. the security concerns, why would you not add to th securty
> considerations section
> The above objects also have privacy implications, i.e., they
> disclose who is connecting to what hosts. These are sensitive
> from a perspective of preventing traffic analysis, and also to
> protect individual privacy.
>
> You could add it after the 2 bullets, just before the para that
> starts with: SNMP versions prior to SNMPv3
> I am assuming here that it applies to all the tables, but maybe
> it only applies to one or two tables, in which case it might be good
> to be specific.
>
> I am checking the other changes.
>
> Thanks,
> Bert
>
> > -----Original Message-----
> > From: Javier Pastor-Balbas (ECE)
> > [mailto:javier.pastor-balbas@ece.ericsson.se]
> > Sent: dinsdag 3 juni 2003 12:00
> > To: 'Wijnen, Bert (Bert)'; 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
> > Subject: RE: FW: draft-ietf-sigtran-sctp-mib-09.txt - rev
> 10b included
> >
> >
> > Hi Bert et al.,
> >
> > All the changes in the mail below have been included in the MIB.
> >
> > Regarding the security concerns, we think that what you're
> > proposing is already stated in the MIB (see 3rd paragraph
> > within Sec. Cons. section). This was your comment:
> >
> >
> > *****start included text******
> >
> > Here is more input from IESG (assuming one more rev will
> > occur)... it is from one of the security ADs. You may want
> > to try and add some more explantion to the security considerations
> > section that tells about each object what exactly the concerns
> > or security and/or privacy aspects are. So that operators/users
> > do have proper information based on which they can decide how
> > to configure access control to those objects and tables.
> >
> > ***** end included text ****
> >
> > Pls, send us any further comments you have. We will very
> > pleased to address them.
> >
> > We're sending you attached the updated version. When
> > everything is OK, we'll send it out to the RFC-editor.
> >
> >
> > Thanks // Maria and Javier.
> >
> >
> > > -----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
> > > > > >
> > > > >
> > > >
> > >
> >
> >
>