Templates for Internet-Drafts Containing MIB Modules
RFC 5249

[Ballot discuss]
Dan explained the plan to move this forward and that sounded like it would resolve all my concerns. I expect to clear as soon as next revision arrives.

[Ballot discuss]
Duplicating the BCP 78,79 boiler plate in another BCP just seems like it could have serious confusion later about what version of the boiler plate applies.

[Ballot discuss]
This discuss is just a tickler:

The author has agreed to revisions in the security considerations section for his -05
draft.  (I suspect they could actually be achieved with a note to the RFC Editor.)

I just don't want the change to be forgotten.

[Further detail below, just so it is handy.]

From Steve Hanna's secdir review:

Section 3 of the document (the Security Considerations section)
says "This memo [...] has no impact on network security." In fact,
the document includes advice on how to write a Security Considerations
section of an Internet Draft that defines a MIB module. This advice
appears in section 8 of the template included in Appendix C. The
advice is good (at least, to the extent that I can determine, not
being an expert on SNMP security). However, it is not true that
the document has no impact on network security. It could well have
an indirect impact by guiding the development of the Security
Considerations sections of future RFCs. Therefore, I suggest that
section 3 of the main document (the Security Considerations section)
be revised to say that section 8 of Appendix C contains advice for
writing the Security Considerations section of an Internet Draft
that documents a MIB module.

[Ballot comment]
Comments from Gen-ART Review by Brian Carpenter.

  > Appendix A.  Change Log

  Presumably the Foreword to RFC Editor should request this to be
  removed. Ditto Appendix B, which appears to be empty.

  > Appendix C.  Text Template with Advice

  There should be advice that the I-D header and trailer boilerplate
  texts were current at the time of publication of the template, but
  must be checked for currency when the template is used. Like
  [[anchor6]].

  Is there a plan to maintain a template with current boilerplate, or
  do we just hope everyone uses xml2rfc?

[Ballot comment]
Christian Vogt's review:

This document defines a template for Internet drafts that specify new MIBs, and provides guidelines for filling it out.

The document is well written.  It is a good idea to create a template for documents of a kind that are structured in a very similar way.  This makes these documents faster to write, easier to read and review, and more consistent.  Three things that should be addressed, however:

(1)  I would suggest removing the specific boilerplate from the template.  Hard-coding the boilerplate into the template necessitates an update of the template whenever the boilerplate changes.  This is bound to happen occasionally.

It would be more appropriate to describe where the current boilerplate can be found without explicitly re-printing it.  The 2nd paragraph in section 2 ("Overview") already provides an appropriate reference to the current boilerplate, so the boilerplate re-print later in the template is not necessary.

(2)  Editorial:  Initializing the intended status of the MIB document to "historic" in the template is confusion.  Suggestion:  Use a more obvious placeholder such as "STATUS".

(3)  Suggestion for further work:  Update RFC 4181 ("Guidelines for Authors and Reviewers of MIB Documents") to reference this MIB template and suggest using it where possible.

[Ballot comment]
I am sympathetic with Ron's question regarding whether this should be something other BCP (perhaps informational?). However, I will defer to Ron, Dan, the MIB doctor's, and others, since I am not an expert in this area.

[Ballot discuss]
I think this would be better as an ION.

Duplicating the BCP 78,79 boiler plate in another BCP just seems like it could have serious confusion later about what version of the boiler plate applies.

[Ballot discuss]
Does this need to be a BCP?

Maybe it should be a web page, accessible from
http://www.ietf.org/ID.html, just like http://www.ietf.org/ietf/1id-guidelines.html.

                            Ron

IANA Last Call Comment:

This document is a template for future documents that may be
approved by the IESG for the definitions of MIBs. We understand
this document to have NO IANA Actions.

There should be a reference to RFC2434 which describes IANA
Considerations sections.

request to be considered for BCP, on AD-sponsored track received from the author:

Hi Dan,

I would like to officially submit this MIB Template to you for advancement to a BCP.

The -00- draft is
http://www.ietf.org/internet-drafts/draft-harrington-text-mib-doc-temp
late-00.txt
I just sent in a -01- that differs only in that it has been processed by the new xml2rfc which has the IETF Trust boilerplate changes. The RFC publication process itself should cause such changes to occur anyway.

Thanks,
dbh