Re: WG last call: Coex draft

On Mon, 23 Dec 2002, Harrington, David wrote:
> We so far have had one person review the document for smilint
> cleanliness. Mike, did you review the document against "Guidelines for
> MIB Authors and Reviewers" in the process?

I've done through the checklist and attached the results below.  In
principle, this should cover not only MIB cleanliness but also the
documentation rules (i.e., 2026, 2223bis, ID-NITs, and so on).
It's still good if other volunteers will double-check.  And since
this only covers the MIB document aspects, other folks need to
check the protocol translation and SMI translation aspects.

//cmh

0.) Abstract -- references are not permitted in the abstract.
Please remove the "[21]" from the last sentence.

1.) MIB Boilerplate -- not applicable in this case, since the
material in Section 1 adequately covers what is needed.

2.) IPR Notices -- OK.  The draft contains the required copies
of the IPR notices specified by bullets (A) and (B) in Section
10.4 of RFC 2026.  Presumably bullet (D) is not required since
there are no known patents that are required to practice the
technology in the draft.  [COMMENT TO WG: please speak up if
you know of any such patents.  I believe that the IPR notice
rules in RFC 2026 should be followed as if this doc were on
the standards track even if it is submitted as BCP or
Informational, since it is IETF technology.]

3.) References -- please replace the references to RFCs 2570
through 2575 and 1905 through 1907 with references to RFCs
3410 through 3418 respectively, please follow the style of
recent RFCs (no company names, write RFC nnnn instead of
RFCnnnn), and please make separate lists of normative and
informative references.  I would nominate RFC 1303 [5],
RFC 1908 [13], RFC 2089 [14], and ISO 8824 [22] as
informative;  the rest are clearly normative.  (Note: it
has been checked that proposed list of normative references
does contain all MIB modules references in the IMPORTS
clause of the SNMP-COMMUNITY-MIB).

4.) Security Considerations Section -- looks OK to me;  given
the special purpose of this document, the standard template
used for MIB documents does not apply.

5.) IANA Considerations Section -- OK (none required since
no name space is created and no registries are updated).

6.) Copyrights -- please update the copyright dates to refer
to the current year [probably (2003) by the time these comments
are incorporated in a new draft].

7.) MIB compilation -- OK once the following typo in the
snmpCommunityTransportTag DESCRIPTION clause is corrected
(this was reported in a previous e-mail along with additional
details, but is repeated here for completeness).

*** draft-ietf-snmpv3-coex-v2-02.txt	Mon Dec 16 06:51:58 2002
--- draft-ietf-snmpv3-coex-v2-XX.txt	Wed Dec 18 10:36:38 2002
***************
*** 2289 ****
!                string, nor when generating notifications."
--- 2289 ----
!                string, nor when generating notifications.

8.) Technical content -- nothing found beyond previously-reported
errors.  They are repeated here for completeness:

a.)  The MODULE-IDENTITY DESCRIPTION clause needs to have a copyright
notice inserted.  The following is suggested:

              DESCRIPTION
                  "This MIB module defines objects to help support
                   coexistence between SNMPv1, SNMPv2c, and SNMPv3.

                   Copyright (C) The Internet Society (2002).  This
                   version of this MIB module is part of RFC xxxx;
                   see the RFC itself for full legal notices."
-- RFC-editor: replace xxxx with actual RFC number & remove this notice

b.)  The MODULE-IDENTITY REVISION clauses include information about
revisions that appeared only as Internet Drafts, which should not be
present, and the revision clause about the version published as RFC
2576 is missing.  It is suggested is to replace the entire set of
REVISION clauses with the following:

              REVISION "200212130000Z" -- 13 Dec 2002 (same as LAST-UPDATED)
              DESCRIPTION "Updated description of snmpCommunityTag to make
                           it consistent with the rest of the document.
                           This version published as RFC xxxx."
-- RFC-editor: replace xxxx with actual RFC number & remove this notice

              REVISION "200003060000Z" -- 6 Mar 2000
              DESCRIPTION "This version published as RFC 2576."

Note:  the date 200212130000Z should probably be updated to the current
date when these changes are incorporated.

c.)  The document change log does not document the changes since RFC 2576,
such as the one described in REVISION clause above.

9.) Typos and formatting -- the text in Section 5.1 is not properly
indented.