[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: MIB OID assignement
From RFC2026:
4.2.1 Experimental
The "Experimental" designation typically denotes a specification that
is part of some research or development effort. Such a specification
is published for the general information of the Internet technical
community and as an archival record of the work, subject only to
editorial considerations and to verification that there has been
adequate coordination with the standards process (see below). An
Experimental specification may be the output of an organized Internet
research effort (e.g., a Research Group of the IRTF), an IETF Working
Group, or it may be an individual contribution.
So this draft-glenn-mo-aggr-mib-07.txt could fall in that category.
But, in IESG we also use the following:
The rules above are not terribly tight.
In particular, the reasons for declaring something "part of a research and
development effort" aren't clear, and the word "typically" allows a lot of
wiggle room.
So more guidelines can be needed.
The following set of guidelines seem to make sense.
The list is read from top to bottom; the first one that seems to apply is probably
the one that makes sense to follow.
- If it can't be practiced, it's Informational.
Unless it's a protocol, a procedure or a format, it is hard to see what kind
of experiment it can be.
Case in point: "Terminology for ATM ABR benchmarking" (RFC 3134).
- If it's not going to be changed no matter what the result is, it's Informational.
This is typically the case with vendor protocols; the vendor will publish it for
the good of the community, but retains full change control, and gives no promises
about listening to community feedback.
Case in point: "Microsoft Point-To-Point Encryption (MPPE) Protocol" (RFC 3078)
- If the IETF may publish something based on this on the standards track once we know
how well this one works, it's Experimental.
This is the typical case of not being able to decide which protocol is "better" before
we have experience of dealing with them from a stable specification.
Case in point: "PGM Reliable Transport Protocol Specification" (RFC 3208)
- If the document contains implicit or explicit success/failure criteria, and it's
clear that the outcome can be used as the basis for a recommendation to the IETF
community, it's Experimental.
Case in point: RFC 1797 "Class A Subnet Experiment"
which led to RFC 1879 "Class A Subnet Experiment Results and Recommendations"
Note that criterion 3 above is not intended to say that by publishing this, the IETF
is promising to do a followup; the IETF may later decide that the experiment failed, and may
sometimes believe this outcome to be very probable even when publishing the document.
Criterion 2 may be hard to evaluate, because it requires evaluating the intent of the
proposer; still, sometimes it is very easy, and nothing further needs to be said.
So the question we are faced with (I think) is if we stop at criterion 2 above,
or if we believe that ultimately something may get developed in IETF based on
experience with this doc, in case we are at criterion 3 above.
I think the doc does not provide the items listed in criterion 4.
I think I agree that if we stick to informational, then maybe the MIB module
should go under Gelnn's own companies vendor OID.
We can advise the RFC-Editor of this, if we agree.
Bert
> -----Original Message-----
> From: owner-mreview@ops.ietf.org [mailto:owner-mreview@ops.ietf.org]On
> Behalf Of David B Harrington
> Sent: Monday, November 28, 2005 00:42
> To: 'Romascanu, Dan (Dan)'; 'C. M. Heard'; 'Mreview (E-mail)'
> Subject: RE: MIB OID assignement
>
>
> I concur that this should be experimental if it rooted under
> experimental.
>
> dbh
>
> > -----Original Message-----
> > From: owner-mreview@ops.ietf.org
> > [mailto:owner-mreview@ops.ietf.org] On Behalf Of Romascanu, Dan
> (Dan)
> > Sent: Wednesday, November 23, 2005 10:13 AM
> > To: C. M. Heard; Mreview (E-mail)
> > Subject: RE: MIB OID assignement
> >
> > I agree with Mike. There seems to be a rule of thumb here about
> > documents defining MIB modules that seems rather trivial and there
> > should be some good arguments not to follow it:
> >
> > - if the MIB module is aimed to be rooted under mib-2 or
> transmission
> > for the older ones, the document should be Proposed or other
> standards
> > track
> > - if the MIB module is aimed to be rooted under experimental, that
> the
> > document should be Experimental
> > - if the MIB module belongs to some other organization OID space, it
> > should go Informational
> >
> > Regards,
> >
> > Dan
> >
> >
> >
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: owner-mreview@ops.ietf.org
> > > [mailto:owner-mreview@ops.ietf.org] On Behalf Of C. M. Heard
> > > Sent: Wednesday, November 23, 2005 4:52 PM
> > > To: Mreview (E-mail)
> > > Subject: Re: MIB OID assignement
> > >
> > > On Wed, 23 Nov 2005, Wijnen, Bert (Bert) wrote:
> > > > There is a document that has gone (as we agreed in SNMPEOS
> > > some years
> > > > ago) the "indivudual submission to RFC-Editor" route.
> > > >
> > > > The request is for publication as Informational RFC.
> > > >
> > > > The MIB author requests the two MIB modules to go under the
> > > > experimental OID branch.
> > > >
> > > > Do we see an issue with that?
> > > > I can live with it unless anyone sees a serious problem.
> > > > comments (if any) ASAP please.
> > > >
> > > > This is about document: draft-glenn-mo-aggr-mib-07.txt
> > >
> > > I do not see any showstopper issue with this, although given
> > > the nature of the subject matter in the RFC I would _suggest_
> > > to the author and the RFC Editor that Experimental would be a
> > > better category than Informational.
> > >
> > > > Glenn Waters has done MIB Doctor review for this document.
> > > > I trusts Glenn's review, and I have (recently) only done
> > a compile
> > > > check to ensure no SYNTAX errors. It says:
> > > > C:\bwijnen\smicng\work>smicng taggr.inc
> > > > E: f(aggr.mi2), (212,21) Default value for
> > > "aggrCtlCompressionAlgorithm"
> > > > must be a name and not a number
> > > > *** 1 error and 0 warnings in parsing and
> > > > C:\bwijnen\smicng\work>smicng aggr.inc
> > > > E: f(aggr.mi2), (212,21) Default value for
> > > "aggrCtlCompressionAlgorithm"
> > > > must be a name and not a number
> > > > *** 1 error and 0 warnings in parsing which I will pass to
> > > > RFC-Editor.
> > > > Technical flaws we can always point out to RFC-Editor.
> > >
> > > This is not really a technical flaw in the MIB module but a
> > > quirk in the tool. The MIB review guidelines Sec. 4.6.1.1.
> > says this:
> > >
> > > Although the SMI allows DEFVAL clauses for integer-valued
> > > enumerations to specify the default value either by label or by
> > > numeric value, the label form is preferred since all the
> > > examples in
> > > RFC 2578 are of that form and some tools do not accept
> > the numeric
> > > form.
> > >
> > > > It is going to be on IESG agenda for Dec 1st.
> > > > Basically we can only reject if it conflicts with ongoing
> > > or past IETF
> > > > work, but I do not think such is the case. the standard
> > > IESG note (as
> > > > per RFC3932):
> > > >
> > > > The content of this RFC was at one time considered
> > by the IETF,
> > > > and therefore it may resemble a current IETF work in
> > > progress or a
> > > > published IETF work. This RFC is not a candidate for
> > > any level of
> > > > Internet Standard. The IETF disclaims any knowledge of the
> > > > fitness of this RFC for any purpose and in particular
> > > notes that
> > > > the decision to publish is not based on IETF review for
> such
> > > > things as security, congestion control, or inappropriate
> > > > interaction with deployed protocols. The RFC Editor
> > > has chosen to
> > > > publish this document at its discretion. Readers of this
> RFC
> > > > should exercise caution in evaluating its value for
> > > implementation
> > > > and deployment. See RFC 3932 for more information.
> > >
> > > That sounds fine to me. All I would do is in addition is to
> > > _suggest_ Experimental in place of Informational.
> > >
> > > //cmh
> > >
> > >
> > >
> >
> >
>
>
>