RE: Telechat agenda topic: Does an IANA maintained MIB require an RFC ?

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

WFM

Thanks,
Bert 

> -----Original Message-----
> From: C. M. Heard [mailto:heard@pobox.com]
> Sent: vrijdag 21 februari 2003 8:44
> To: Mreview (E-mail)
> Subject: Re: Telechat agenda topic: Does an IANA maintained 
> MIB require
> an RFC ?
> 
> 
> On Thu, 20 Feb 2003, Wijnen, Bert (Bert) wrote:
> > The IESG today (and in email) discussed these 3 options.
> > 
> > 1. require the initial version to be in an RFC. Make sure that
> >    some statement is made that the authoritative version is
> >    at the IANA web pages.
> > 2. require initial version to be in an I-D for normal IETF
> >    approval process, but to be removed just before RFC gets
> >    published. It would be replaced with a ptr to the web
> >    page that contains the authoritative IANA mantained module
> > 3. leave it up to a WG how to do it.
> > 
> > 
> > The consensus in the IESG is that option 1 is prefered with
> > indeed a very clear statement (possibly in the Module
> > DESCRIPTION clause) that the authorirtative version is
> > on the iana web pages.
> 
> I can live with this.  The changes that I propose to make to bring
> the guidelines doc into compliance with this ruling are as follows:
> 
> 1.)  In Section 3.5, "References Sections", change the second
> paragraph as follows:
> 
> ***************
> *** 227,233 ****
>      The standard MIB boilerplate available at
>      http://www.ops.ietf.org/mib-boilerplate.html includes lists of
>      normative and informative references that MUST appear in all
>      specifications that contain MIB modules.  If items from other MIB
>      modules appear in an IMPORTS statement in the 
> Definitions section,
>      then the specifications containing those other MIB 
> modules MUST be
> !    included in the list of normative references.
> --- 227,236 ----
>      The standard MIB boilerplate available at
>      http://www.ops.ietf.org/mib-boilerplate.html includes lists of
>      normative and informative references that MUST appear in all
>      specifications that contain MIB modules.  If items from other MIB
>      modules appear in an IMPORTS statement in the 
> Definitions section,
>      then the specifications containing those other MIB 
> modules MUST be
> !    included in the list of normative references.  When items are
> !    imported from an IANA-mainained MIB module the corresponding
> !    normative reference SHALL point to the on-line version of that
> !    MIB module.
> 
> 
> 2.) In Section 3.7, "IANA Considerations Section", change the
> third paragraph as follows:
> 
> ***************
> *** 282,294 ****
>      The current practice for such cases is to include a detailed IANA
>      Considerations section complying with [RFC2434] in the 
> DESCRIPTION
>      clause of the MODULE-IDENTITY invocation in each 
> IANA-maintained MIB
>      module and for the IANA Considerations section of the 
> MIB document
> !    that defines the name space to refer to the URLs for the relevant
>      modules.  See RFC 2932 [RFC2932] for an example.  This creates a
>      chicken-and-egg problem for MIB documents that have not yet been
>      published as RFCs because the relevant IANA-maintained 
> MIB modules
>      will not yet exist.  The accepted way out of this dilemma is to
> !    include the initial content of the proposed IANA-maintained MIB
> !    modules in appendices of the Internet Draft with a note 
> to the RFC
> !    Editor that those appendices are to be removed upon 
> publication, when
> !    the IANA-maintained modules go on-line.
> --- 285,299 ----
>      The current practice for such cases is to include a detailed IANA
>      Considerations section complying with [RFC2434] in the 
> DESCRIPTION
>      clause of the MODULE-IDENTITY invocation in each 
> IANA-maintained MIB
>      module and for the IANA Considerations section of the 
> MIB document
> !    that defines the name spaces to refer to the URLs for 
> the relevant
>      modules.  See RFC 2932 [RFC2932] for an example.  This creates a
>      chicken-and-egg problem for MIB documents that have not yet been
>      published as RFCs because the relevant IANA-maintained 
> MIB modules
>      will not yet exist.  The accepted way out of this dilemma is to
> !    include the initial content of each IANA-maintained MIB 
> module in a
> !    non-normative section of the initial issue of the document that
> !    defines the name space;  for an example see [RFC1573], which
> !    documents the initial version of the IANAifType-MIB.  
> That material
> !    is usually omitted from subsequent updates to the 
> document since the
> !    IANA-maintained modules are then available on-line (cf. 
> [RFC2863]).
> 
> 
> 3.) Add the following informative reference:
> 
> [RFC1573]   McCloghrie, K. and F. Kastenholz, "Evolution of the
>             Interfaces Group of MIB-II", RFC 1573, January 1994.
> 
> 
> Feedback is requested.
> 
> //cmh
> 
>