[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Missing normative references to modules containing importeditems (was: FW: Malloc MIB)



On Wed, 29 Jan 2003, David T. Perkins wrote:
> Many years ago, a similar issue came up. It was the practice of specifying
> in the text of DESCRIPTION or REFERENCE clauses item of the form
> "[<number>]" to refer to a document in the reference section.
> Well, because most MIB modules are extracted from the containing
> document, the "[<number>]" items were essentially "dangling pointers",
> and were use less.

That's a good point, and we should flag such stuff in MIB reviews when
we see it.  That tends to be a little less of a problem today because
most people seem to be switching to the [RFCxyzt] style.  That's still
not entirely right but it is at least comprehensible.

> This is not the same issue, but it is an issue that the reference
> needs to be made to the latest version of the document, and NOT
> the version that was current when the reference was specified.
> That is the hard problem to be solved. How to help the MIB module
> reader in the current, and help (without confusing) the MIB module
> reader in the future.

The problem is the same whether the mention of an RFC appears in an
ASN.1 comment, in a REFERENCE clause, or in the document's reference
list:  it's ALWAYS possible for a new version to supersede, and
all we can do when we write the document is to refer to the most
up-to-date version at that time.  Some other SDOs (ANSI is one)
have a disclaimer in their standards that says (in effect) that the
references could have been superseded, so please look for the latest
ones.  One very salutary side effect of the recent IESG directive to
put an abbreviated copyright notice in the MODULE-IDENTITY DESCRIPTION
clause is that it is now going to be apparent where an extracted MIB
module comes from, and one can tell if it's been superseded by looking
at ftp://ftp.isi.edu/in-notes/rfc-index.txt (or a mirrored equivalent).

But this still does not address the following question:  do we want
to have ASN.1 comments like this

    IMPORTS
      SnmpAdminString
        FROM SNMP-FRAMEWORK-MIB  -- RFC 3411

telling where we the imported symbols were coming from at the time
the MIB module was written?  If it gives the impression that one needs
to import symbols from that specific version of the SNMP-FRAMEWORK-MIB,
then it might well do more harm than good.

//cmh