RE: [RMONMIB] comments on draft-ietf-rmonmib-dsmon-mib-02.txt

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Comments inline

> ----------
> From: 	Andy Bierman[SMTP:abierman@cisco.com]
> Sent: 	Wednesday, October 04, 2000 4:34 PM
> To: 	Ofer Goren
> Cc: 	massadb@netscout.com; Les Bell; rmonmib@ietf.org; mibs@ops.ietf.org
> Subject: 	Re: [RMONMIB] comments on
> draft-ietf-rmonmib-dsmon-mib-02.txt
> 
> > Ofer Goren wrote:
> > 
> > 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?
> 
> The WG Last Call is an appropriate time to raise issues with a document,
> before it goes to IETF Last Call. I think you misinterpreted the
> 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.
> > 
> 
> Every vendor knows there is risk implementing a draft before it is
> published as an RFC. Even so, the MIB objects do not have to be 
> renumbered after the overflow counters are removed. 
> 
Well spoken. This is certainly true for a Internet-Draft.
But even for an RFC at Proposed Standard, there is the risk that
incompatible changes occur later. See RFC2026 which describes
this process.

W.r.t. the MIB objects that already have been defined....
They could be deprecated first and then later be obsoleted.
That way, existing implementations are still fine.

Bert