Re: clarifying the term "standard"

["C. M. Heard" <heard@pobox.com>]

[ in reply to comments/review <draft-ietf-ops-mib-review-guidelines-00.txt> ]

On Fri, 7 Feb 2003, Wijnen, Bert (Bert) wrote:
> - you talk about "standard" MIB  quite a few times.
>   maybe better to use "standards track" MIB, cause it is
>   true for all 3 levels on the stds track

The term "standard", where it appears in quotes, refers to
the usage in from RFCs 2578/2579/2580.  So I guess I should
clarify this.  To this end I propose is to add the following
paragraph at the end of Section 2, "Terminology":

+  The term "standard", when it appears in quotes, is used in the same
+  sense as in the SMIv2 documents [RFC2578] [RFC2579] [RFC2580].  In
+  particular, it is used to refer to the requirements that those
+  documents levy on "standard" modules or "standard" objects.

Note that replacing "standard" with "standards track" would NOT
serve this purpose, which is to refer to certain specific usage in
RFCs 2578/2579/2580.  For example, in Section 4, "SMIv2 Usage
Guidelines", the guidelines draft says:

   In general, MIB modules in IETF standards-track specifications MUST
   comply with all syntactic and semantic requirements of SMIv2
   [RFC2578] [RFC2579] [RFC2580] that apply to "standard" MIB modules
   and except as noted below SHOULD comply with SMIv2 recommendations.

What I mean by this is that standards-track specifications have to
comply both with the SMI general requirements plus the additional
requirements placed on "standard" information modules by the SMIv2
documents.

There is one place in the guidelines where I've used this term of
art incorrectly -- at the end of Section 4.4 -- and I'll make the
change s/"standard"/standards-track/ there.  But everywhere else I
think I've used it as described above, and I'd like to keep those
occurrences as they are.

Is this explanation, along with the the proposed addition to Section
2 and fix to Section 4.4, adequate to address your concerns?

Mike