RE: clarifying the term "standard"

["Wijnen, Bert (Bert)" <bwijnen@lucent.com>]

Yes, that addresses my concerns, 

Thanks,
Bert 

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: maandag 10 februari 2003 23:37
> To: Mreview (E-mail)
> Subject: Re: clarifying the term "standard"
> 
> 
> [ 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
> 
>