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

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

Hi -

If one were to take this line of argumentation to its logical conclusion,
the conclusion would be that we shouldn't put any MIB modules (or any
other machine-readable specifications, for that matter) in RFCs.
Though I can understand its perverse appeal, particularly in light of the
loss of versioning information that came about when SMIv2 prohibited
identification of MIB modules using OIDs, I think this will make progression
of interdependent specifications even more of a sleight-of-hand exercise
than it already is.  (E.g, a standards-track document IMPORTs the
ever-changing IANA module, but the "Normative References" section
points to the "immutable" RFC that was the vehicle for the publication
of some version of that module.)   I know this is necessary to shoehorn
extensible protocols into the IETF standardization process, but let's not
get carried away.

Randy

P.S.  Being "superceded" does not transform "normative" text into
"non-normative" text.  In the case of these pointers to the IANA site,
they must be considered normative references, since they are
an integral part of the specification and it won't "work" without them.

One important consequence of this is what references sections for
dependent specifications should provide as their normative references:
the IANA site or the RFC?

> From: "C. M. Heard" <heard@pobox.com>
> To: "Mreview (E-mail)" <mreview@ops.ietf.org>
> Sent: Tuesday, February 11, 2003 3:26 PM
> Subject: Re: guidelines section 3.7 (disposition of IANA MIB modules)
>

> On Tue, 11 Feb 2003, Randy Presuhn wrote:
> > > On Tue, 11 Feb 2003, Randy Presuhn wrote:
> > > > [ ... ] but it should certainly be normative.
> > >
> > > No, it _cannot_ be normative, because the version maintained by IANA
> > > is.  There are never two normative version of the same thing.
> >
> > No.  It *is* normative.  If it were not, we couldn't make
> > normative references (e.g. IMPORTS) from other standards.  It
> > will superceded if/when the IANA copy is updated.  That's what
> > the "health warning" and IANA pointer are for.
> >
> > If we label something as "non-normative", it means that the technical
> > effect of the specification would be unchanged if that material had never
> > existed, which is clearly not the case here.
>
> But the effect of the technical specification IS unchanged if the
> unauthoritative copies of the IANA-maintained MIBs are omitted from
> the specification and the IANA pointer is all that is given.  Both
> RFC 2932 or RFC 2863 do exactly that:  the IANA-maintained MIB modules
> that they reference (IANA-RTPROTO-MIB and IANAifType-MIB respectively)
> are absent from those documents.  Instead, they refer you to the
> IANA web pages where you will find the mib modules (the URLS are
> http://www.iana.org/assignments/ianaiprouteprotocol-mib and
> http://www.iana.org/assignments/ianaiftype-mib respectively).
>
> > > > (If it's non-normative, what's the point of publishing it?)
> > >
> > > My point exactly.
> >
> > Perhaps I'm not being clear: marking something as "non-
> > normative" means it is *NOT* part of the specification.
>
> That's right.  We are completely in sync up to this point.
>
> > Non-normative material is typically examples, use cases,
> > and other "stuff" to help readers understand how to
> > apply a standard.  These MIB modules are much more
> > than "examples".
>
> It's also used in certain specifications (IEEE 802.3ae is
> an example) where that specification makes a normative
> reference to some other specification (ANSI T1.416-1999, in
> this case) as an authoritative source (in this case, for
> definitions of fields in SONET frames) but includes in
> informative text definitions found in the normative
> references.  That, precisely, is what we are doing when we
> provide a pointer to an IANA-maintained MIB module (which
> is the authoritative version) and also put a copy of that
> MIB module into our specification.
>
> Readers of the RFC do NOT need to have a copy of the
> IANA-maintained MIB module in the RFC because they can
> always get the "real" one from the IANA web site.
>
> If you are concerned with the procedures for "seeding"
> the IANA-maintained MIB module, do please note that
> Section 3.7 of the guidelines tell you how to do that:
> put it in an appendix, with a note to the RFC Editor
> that the appendix is to be removed upon publication
> (when the IANA module goes on-line).
>
> As is obvious from the way I have been arguing, I happen
> to deplore the practice of having informative text in
> one spec that is a (possibly imperfect) copy of some
> text that appears normatively in something else.  I tend
> to believe that it's always better to have "one version
> of the truth".
>
> For whatever it is worth, the way that I prepared Section
> 3.7 was to look at some cases of recent practice and
> document what I found.  It's possible that I stopped
> looking before I should have because the practices that
> I found happened to agree with my prejudices.
>
> Regards,
>
> Mike
>
>