Re: guidelines section 3.7 (disposition of IANA MIB modules)

["Randy Presuhn" <randy_presuhn@mindspring.com>]

Hi -

> From: "C. M. Heard" <heard@pobox.com>
> To: "Mreview (E-mail)" <mreview@ops.ietf.org>
> Sent: Tuesday, February 11, 2003 2:20 PM
> Subject: Re: guidelines section 3.7 (disposition of IANA MIB modules)
>
> On Tue, 11 Feb 2003, Randy Presuhn wrote:
> > If the IANA URL and "health warning" are provided, those who
> > fail to follow it to get the current version of a MIB module have
> > only themselves to blame if they use an earlier version from an
> > RFC or I-D.
>
> True, but we don't need to encourage such behaviour.

What are we doing to encourge it?

> > I think the initial version of such a MIB *should* be published in
> > an RFC.  As an example, I'd cite the "probable cause" stuff in
> > the disman alarm work.  The benefits to publication of the initial
> > revision in this case include:
> >     1) "seeding" the initial set of supported values (which in this
> >          case is quite large);
> >     2) ensuring that the DESCRIPTION semantics are available
> >          in the same document as their (primary) user;
>
> And for the same reasons, you would presumably advocate putting a
> snapshot of the then-current IANA MIB in updated RFCs?

Especially if the WG is tweaking the DESCRIPTION or adding another
block of WG-approved values.

> >      3) making sure that it is all seen during the WG and
> >          IETF last calls.
>
> Having the IANA MIB in a removable appendix in the I-D (as
> recommended in the current guidelines draft) will ensure
> that this happens.  Leaving it the published RFC has no
> bearing on last calls, since they will have long-since passed.

Removing it from the published RFC means there is no archival
record of what has actually been approved.  I-Ds evaporate.

> > Whether it should go into an appendix or not depends on the
> > logical structure of the specification, something which we shouldn't
> > be second-guessing here [ ... ]
>
> If it's going to be removed in subsequent versions of the RFC (as
> was done for the IF-MIB), it is not unreasonable to require (or at
> least to recommend) that document authors plan for it.  Having such
> requirements/recommendation is not new;  the guidelines for RFC
> authors (2223bis) and the I-D nits document have several requirements
> of that nature.
...

Moving sections around is the least of an editor's worries, at least
if using nroff or XML.  I'd rather we trusted editors to do their
jobs, and focused on guidlines that would make specifications easier
to read, understand, and perhaps even write.

Randy