Hi,
I believe it should be moved under mib-2.
From RFC2026:
Non-standards track specifications may be published
directly as "Experimental" or "Informational" RFCs at the discretion
of the RFC Editor in consultation with the IESG (see section 4.2).
From RFC2026:
(d) Limited Use: The TS is considered to be appropriate for use
only in limited or unique circumstances. For example, the usage
of a protocol with the "Experimental" designation should generally
be limited to those actively involved with the experiment.
I believe mibs under the Experimental branch are very similar to protocols with an Experimental designation. If they are to become standards, they should be moved to the normal subtree for standard mibs.
I also concur with Juergen's comments regarding the three-year timeframe.
dbh
> -----Original Message-----
> From: Wijnen, Bert (Bert) [mailto:bwijnen@lucent.com]
> Sent: Sunday, October 20, 2002 9:55 AM
> To: Mreview (E-mail)
> Subject: What to do when moving from experimental to PS
>
>
> MIB reviewers/doctors:
>
> If you take a look at:
> http://www.ietf.org/internet-drafts/draft-ietf-ops-rfc2786std-00.txt
>
> then you can see that the author wants to keep the MIB under
> experimental, even when we were to approve it as PS.
> I think this is wrong... but author keeps pushing back
>
> Here is my comment to author and his response:
>
> >>- I think that when we move this MIB to stds track, that it SHOULD
> >> be moved from the experimental branch to the mib-2 branch.
> >> I know that that may cause incompatibilities, but that is exactly
> >> what the IESG note on RFC2786 warns for.
> >
> >Like I said - there are no substantive changes (and I'll
> deal with your
> >comments below in a minute) - why force people to make this
> change? Its
> >the biggest problem I've encountered with trying to get MIBs
> through the
> >process.....
> >
>
> I think my position is supported by RFC1155, section 3.1 and
> subsections,
> although it does not explicitly state that one could never have a stds
> track MIB Module under the experimental tree.
>
> Any supporters (with explanation why) for one or the other approach?
>
> Thanks,
> Bert
>