RE: clarify that MIB review requirements are targeted at standard s-track documents

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

I do get the point (I think). At the other hand, I do 
want this doc to be considered seriously by other people
doing MIB work and when we get to review such other MIB
work, I think we'd still try to take these guidelines
(as you also say below). Can we add maybe something to the
abstract aka:

  Although some rules/guidelines may not be applicable to
  non-standards track or non-IETF MIB documents, a MIB
  review will still be done with most of these rules/guidelines
  as the starting point.

Thanks,
Bert 

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: dinsdag 11 februari 2003 18:58
> To: Mreview (E-mail)
> Subject: RE: clarify that MIB review requirements are targeted at
> standard s-track documents
> 
> 
> On Tue, 11 Feb 2003, Wijnen, Bert (Bert) wrote:
> > > There is one more place to be changed -- the abstract should 
> > > read:        
> > >   
> > >    This memo provides guidelines for authors and reviewers of IETF
> > >    standards-track specifications containing MIB modules.
> > >    
> > > (s/specifications/standards-track specifications/)
> > > 
> > > Agreed?
> > > 
> > Actually... we may be a bit more relaxed on non-stds track,
> > but we would use the same set of guidelines when reviewing
> > [Informational] MIB documents or MIB documents from other 
> > (standards) organisation. WOuld we not?
> 
> We would probably apply many of the guidelines, but certain of the
> MUSTs/REQUIREDs either wouldn't apply at all or would turn into
> SHOULDs/RECOMMENDEDs.  Details would depend on the situation.  For
> example, if a MIB doctor was reviewing a MIB module developed by
> another SDO that was intended to be published in a standard issued
> by that SDO (not as an RFC), then Section 3 would be irrelevant and
> some of the stuff in Section 4 would not apply.  If that SDO wanted
> to publish its MIB module as an informational RFC, then some of the
> stuff in Section 3 would be relevant.  If an IETF WG wanted to
> publish a MIB module that it developed in an Informational RFC or a
> BCP (which does sometimes happen), then we might well apply all of
> the stuff, including the requirement for an IPR section (yes, I know
> that RFC 2026 does not require it, but I suspect that the reason is
> that RFC 2026 takes the point of view that IETF technical
> specifications don't appear in Informational RFCs and BCPs).
> 
> The document, however, was not written with such distinctions in
> mind.  Its "official" scope is what has to be done for
> standards-track documents.  Here's how the intro now reads, with the
> latest proposed (and apparently agreed-to) changes included:
> 
>    Some time ago the IESG instituted a policy of requiring OPS area
>    review of all IETF standards-track specifications containing MIB
>    modules.  These reviews were established to ensure that such
>    specifications follow established IETF documentation practices and
>    that the MIB modules they contain meet certain generally accepted
>    standards of quality, including (but not limited to) 
> compliance with
>    all syntactic and semantic requirements of SMIv2 (STD 58) [RFC2578]
>    [RFC2579] [RFC2580] that are applicable to "standard" MIB modules.
>    The purpose of this memo is to document the guidelines that are
>    followed in such reviews.
> 
> The fix I proposed for the abstract was just to make it consistent
> with the introduction.  If it seems wrong, then maybe we want to
> re-think the scope of the document, e.g., we might want it to apply
> to all specifications that contain MIB modules developed in the
> IETF.  Frankly, I would prefer not to do that;  I'd prefer to have
> the document capture the review requirements that apply to IETF
> standards track documents and leave the other cases to the
> discretion of the parties involved (typically WG, AD, and reviewer).
> 
> Mike
> 
> 
> 
> 
> 
>