[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: FW: draft-ietf-sigtran-sctp-mib-09.txt - rev 10c included
Bert, regarding your first point, instead of adding the comment to sctpLookupRemHostNameEntry, I already added the following comment into sctpAssocRemHostName, what do you think?
"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. Anyway, while using SNMPv1/v2c or v3, users should be careful not to use hostnames that are longer than 115 since this object is used further as an index for the lookup tables"
br,
MCarmen
-----Original Message-----
From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
Sent: martes, 03 de junio de 2003 18:09
To: Maria-Carmen Belinchon-Vergara (ECE); Javier Pastor-Balbas (ECE)
Cc: 'Wijnen, Bert (Bert)'; 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 10c included
Mmmm....
You now must alsosay something in the DESCRIPTION clause
of sctpLookupRemHostNameEntry OBJECT-TYPE
About the fact that people should be carefull to not
create OIDs longer than 238 subids. I di mention that before
did I not? So how about:
DESCRIPTION
"This table is indexed by remote host name and association ID.
Specifying a host name we would get a list of the associations
specifying that host name as the remote one.
Implementors need to be aware that if the size of
sctpAssocRemHostName exceeds 115 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."
In your compiling notes, you must now also add
- warning: index of row 'sctpLookupRemHostNameEntry' can exceed
OID size limit with 140 subidentifier(s)
By the way, line 2483 still has a non-ASCII:
and peer\x92s IP addresses, the status of these associations and the
it is at top of page 43
Other than that :-( ... it seems OK to me.
Thanks,
Bert
> -----Original Message-----
> From: Maria-Carmen Belinchon-Vergara (ECE)
> [mailto:maria-carmen.belinchon-vergara@ece.ericsson.se]
> Sent: dinsdag 3 juni 2003 17:45
> To: 'Wijnen, Bert (Bert)'
> Cc: Javier Pastor-Balbas (ECE); 'Wijnen, Bert (Bert)';
> 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 10c included
>
>
> OK, I think we addressed all the comments, so here you have
> the revised version,
> br,
> Javier & MCarmen
>
>
>
> > > -----Original Message-----
> > > From: Javier Pastor-Balbas (ECE)
> > > [mailto:javier.pastor-balbas@ece.ericsson.se]
> > > Sent: dinsdag 3 juni 2003 14:58
> > > 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
> > >
> > >
> > > 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
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > >
> > >
> >
>
>