Here is an Email sent by Andy, on the 7th of September, this year:
"Subject: [RMONMIB] WG Last Call : draft-ietf-rmonmib-dsmon-mib-02.txt
Hi,
The RMONMIB WG has completed work on the DIFFSERV Monitoring MIB (DSMON). This document contains new MIB objects and does not update or obsolete any previous standard.
The document 'draft-ietf-rmonmib-dsmon-mib-02.txt' is the final version of this document. Unless there are strong objections, published on the RMONMIB WG mailing list by September 28, 2000, this document will be forwarded to the OPS Area Directors for publication consideration as a Proposed Standard RFC.
Please send all comments to the WG mailing list at rmonmib@ietf.org.
Andy
"
According to this, the 02 version is the final version of the document. Does this mean anything? Should we disregard this announcement?
To make a very long story short, I don't think that the new behavior should apply to the DSMON draft. There are some vendors out there that took this announcement seriously, and started implementing this MIB.
Reagrds,
Embedded SW Team Leader
Email : ogoren@nortelnetworks.com
Phone number: +9723-6456023
Fax number : +9723-6479579
ESN : 826-6023
http://www.nortelnetworks.com
----------------------------------------------------
If you lend someone $20, and never see that person again,
it was probably worth the investment.
-----Original Message-----
From: massadb@netscout.com [mailto:massadb@netscout.com]
Sent: Wed, October 04, 2000 2:13 PM
To: Les Bell
Cc: Andy Bierman; rmonmib@ietf.org; mibs@ops.ietf.org
Subject: RE: [RMONMIB] comments on draft-ietf-rmonmib-dsmon-mib-02.txt
<< File: ATT1003614.txt >>
I think Andy's general premise is correct in wanting to reduce complexity
and encourage progress. Why is support for C64 not considered a new feature
among the "new features" to be implemented? DSMON is not finalized so
that's a good place to start.
I also agree with a previous email that suggests dropping the 32-bit
counter enitrely, not just the overflow. That would would make it even more
simple. Otherwise, how does the NMS know if 32 or 64 bit is supported.
Would we then need a capabilities indicator?
"Les Bell" <Les_Bell@eur.3com.com>@ietf.org on 10/03/2000 04:58:04 AM
Sent by: rmonmib-admin@ietf.org
To: Andy Bierman <abierman@cisco.com>
cc: rmonmib@ietf.org, mibs@ops.ietf.org
Subject: RE: [RMONMIB] comments on draft-ietf-rmonmib-dsmon-mib-02.txt
Hi Andy,
I agree with Ofer Goren that it is not a simple compile switch to support
SNMPv2C/v3 for the majority of implementations.
But I would go a bit further and suggest that you should continue to
support the
overflow counters in new MIBs. If you don't, then I believe they will be
defined in proprietary MIBs by the majority of vendors that cannot easily
support SNMPv2C/v3. This will make it more difficult for the NMS people
everywhere.
It is true that there are a few SNMPv2C/v3 implementations out there that
could
be used as a replacement for the many SNMPv1 implementations that are out
there.
However I would find it difficult to justify the cost of purchasing a third
party SNMPv2C/v3 implementation and porting it into an existing product.
Even
taking a 'free' implementation requires significant development effort to
port,
adapting it to interface to an existing product, or adapting the rest of
the
software to the new SNMP interface. Why should I have to divert resources
to
this work when I could implement new features instead, where the end-user
will
see as a more direct benefit.
If you have an agent and NMS that both support SNMPv2C/v3, then you always
have
the option of not implementing the overflow counters in your agent. The
MIB
compliance statements can make it clear that it is required to implement
either
the 64-bit counters or the 32-bit overflow counters, but it is not required
to
implement both.
We have an existing solution to the 64-bit counters that works well with
existing equipment. Let's not break it.
Les...
jay@netscout.com on 03/10/2000 07:53:47
Sent by: jay@netscout.com
To: "Ofer Goren" <ogoren@nortelnetworks.com>
cc: Andy Bierman <abierman@cisco.com>, rmonmib@ietf.org, "Ofer Goren"
<ogoren@nortelnetworks.com>, mibs@ops.ietf.org (Les Bell/GB/3Com)
Subject: RE: [RMONMIB] comments on draft-ietf-rmonmib-dsmon-mib-02.txt
Hi Andy,
It makes more sense to me that we propose this change for all new drafts
and let the old ones
stay as they are. Many vendors have already implemented existing drafts on
both the
agent side as well as the application side and to make such a fundamental
change at this
stage presents quite a bit of a problem. It may be as simple as recompiling
the code with a
v2-enabled stack for some but for some others it may be as complex as
rewriting the code.
One should also not forget the retesting involved so as to ensure that all
is well in terms of
functionality, compatibility with one's own application, compatibility
with third-party
applications etc. So, I would suggest that we leave the existing drafts as
they are (eg. DSMON)
and implement the new idea only for freshly proposed drafts.
Regards
Jay
"Ofer Goren" <ogoren@nortelnetworks.com>@ietf.org on 10/02/2000 04:26:33 AM
Sent by: rmonmib-admin@ietf.org
To: Andy Bierman <abierman@cisco.com>, rmonmib@ietf.org
cc: "Ofer Goren" <ogoren@nortelnetworks.com>
Subject: RE: [RMONMIB] comments on draft-ietf-rmonmib-dsmon-mib-02.txt
Hi.
The majority of the SNMP agents used today do not support SNMPv2C/v3. I can
tell you that our application uses the overflow counters for that reason.
It should take some time to upgrade the SNMP agent in use to the newer
version. Hence, I think that the WG should implement the new behavior only
for the next drafts, and not for the ones in progress (such as DSMON).
Regards,
Embedded SW Team Leader
Email