[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Telechat agenda topic: Does an IANA maintained MIB require anRFC ?
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