[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Test, please ignore

To: "Mreview (E-mail)" <mreview@ops.ietf.org>
Subject: Test, please ignore
From: "C. M. Heard" <heard@pobox.com>
Date: Sat, 1 Jan 2005 22:07:49 -0800 (PST)

[ testing fix for problem with extra line breaks in attachments --
  please delete ]

***************

*** 1,21 ****

  

  INTERNET-DRAFT                                       C. M. Heard, 
Editor

!                                                                June 
2004

  

           Guidelines for Authors and Reviewers of MIB Documents

  

!              <draft-ietf-ops-mib-review-guidelines-03.txt>

  

  Status of this Memo

  

!    This document is an Internet-Draft and is subject to all 
provisions

!    of Section 3 of RFC 3667.

  

-    By submitting this Internet-Draft, I certify that any applicable

-    patent or other IPR claims of which I am aware have been 
disclosed,

-    and any of which I become aware will be disclosed, in accordance 
with

-    RFC 3668.

- 

     Internet-Drafts are draft documents valid for a maximum of six 
months

     and may be updated, replaced, or obsoleted by other documents at 
any

     time.  It is inappropriate to use Internet-Drafts as reference

--- 1,23 ----

  

  INTERNET-DRAFT                                       C. M. Heard, 
Editor

!                                                             January 
2005

  

           Guidelines for Authors and Reviewers of MIB Documents

  

!              <draft-ietf-ops-mib-review-guidelines-04.txt>

  

  Status of this Memo

  

!    By submitting this Internet-Draft, each author represents that any

!    applicable patents or other IPR claims of which he or she is aware

!    have been or will be disclosed, and any of which he or she becomes

!    aware will be disclosed, in accordance with Section 6 of BCP 79.

! 

!    Internet-Drafts are working documents of the Internet Engineering

!    Task Force (IETF), its areas, and its working groups.  Note that

!    other groups may also distribute working documents as Internet-

!    Drafts.

  

     Internet-Drafts are draft documents valid for a maximum of six 
months

     and may be updated, replaced, or obsoleted by other documents at 
any

     time.  It is inappropriate to use Internet-Drafts as reference

***************

*** 34,40 ****

  

  Copyright Notice

  

!    Copyright (C) The Internet Society (2004).  All Rights Reserved.

  

  Abstract

  

--- 36,42 ----

  

  Copyright Notice

  

!    Copyright (C) The Internet Society (2005).  All Rights Reserved.

  

  Abstract

  

***************

*** 98,114 ****

  3.  General Documentation Guidelines

  

     In general, IETF standards-track specifications containing MIB

!    modules MUST conform to the requirements for IETF standards-track

!    RFCs documented in [RFC2223bis].  Because the version under review

!    will be an Internet-Draft, the notices on the front page will 
comply

!    with the requirements of 
http://www.ietf.org/ietf/1id-guidelines.txt

!    and not with those of [RFC2223bis].  The rest of the requirements 
in

!    [RFC2223bis], however, do apply (see http://www.ietf.org/ID-

!    Checklist.html for additional details).

  

     Section 4 of [RFC2223bis] lists the sections that may exist in an

!    RFC.  The "body of memo" part of an RFC in general contains 
multiple

!    sections, and in a MIB document MUST contain at least the 
following:

  

      o MIB boilerplate section

  

--- 100,119 ----

  3.  General Documentation Guidelines

  

     In general, IETF standards-track specifications containing MIB

!    modules are subject to the same requirements as IETF 
standards-track

!    RFCs (see [RFC2223bis]), although there are some differences.  In

!    particular, since the version under review will be an 
Internet-Draft,

!    the notices on the front page MUST comply with the requirements of

!    http://www.ietf.org/ietf/1id-guidelines.txt and not with those of

!    [RFC2223bis].  In addition, since the specification under review 
is

!    expected to be submitted to the IESG, it MUST comply with certain

!    requirements that do not necessarily apply to RFCs;  see

!    http://www.ietf.org/ID-Checklist.html for details.

  

     Section 4 of [RFC2223bis] lists the sections that may exist in an

!    RFC.  Sections from the abstract onward may also be present in an

!    Internet-Draft.  The "body of memo" is always required, and in a 
MIB

!    document MUST contain at least the following:

  

      o MIB boilerplate section

  

***************

*** 116,122 ****

  

      o Definitions section

  

!     o Intellectual Property section

  

     Section-by-section guidelines follow.

  

--- 121,131 ----

  

      o Definitions section

  

!     o Security Considerations section

! 

!     o IANA Considerations section

! 

!     o References section.

  

     Section-by-section guidelines follow.

  

***************

*** 333,339 ****

!  3.8.  Copyright Notices

  

     IETF MIB documents MUST contain the copyright notices and 
disclaimer

!    specified in Sections 5.4 and 5.5 of RFC 3667 [RFC3667].  Authors 
and

     reviewers MUST check to make sure that the correct year is 
inserted

     into these notices.  In addition, the DESCRIPTION clause of the

     MODULE-IDENTITY invocation of each MIB module that will appear in 
the

--- 342,348 ----

! 3.7.  Copyright Notices

  

     IETF MIB documents MUST contain the copyright notices and 
disclaimer

!    specified in Sections 5.4 and 5.5 of RFC 3907 [RFC3907].  Authors 
and

     reviewers MUST check to make sure that the correct year is 
inserted

     into these notices.  In addition, the DESCRIPTION clause of the

     MODULE-IDENTITY invocation of each MIB module that will appear in 
the

***************

*** 359,365 ****

              Copyright (C) The Internet Society (date).  The initial

              version of this MIB module was published in RFC yyyy;

              for full legal notices see the RFC itself.  Supplementary

!             information may be available on

              http://www.ietf.org/copyrights/ianamib.html.";

     -- RFC Ed.: replace yyyy with actual RFC number & remove this note

  

--- 368,374 ----

              Copyright (C) The Internet Society (date).  The initial

              version of this MIB module was published in RFC yyyy;

              for full legal notices see the RFC itself.  Supplementary

!             information may be available at:

              http://www.ietf.org/copyrights/ianamib.html.";

     -- RFC Ed.: replace yyyy with actual RFC number & remove this note

  

***************

*** 368,377 ****

  

! 3.4.  Intellectual Property Section

  

!    Section 5 of RFC 3668 [RFC3668] contains a notice regarding

     intellectual property rights or other rights that must appear in 
all

!    IETF RFCs.  A verbatim copy of that notice MUST appear in every 
IETF

!    MIB document.

  

  4.  SMIv2 Usage Guidelines

  

--- 377,386 ----

  

! 3.8.  Intellectual Property Section

  

!    Section 5 of RFC 3908 [RFC3908] contains a notice regarding

     intellectual property rights or other rights that must appear in 
all

!    IETF RFCs.  A verbatim copy of that notice SHOULD appear in every

!    IETF MIB document.

  

  4.  SMIv2 Usage Guidelines

  

***************

*** 693,699 ****

     this restriction.  Henceforth "standard" MIB modules MAY use the

     Counter64 type when it makes sense to do so, and MUST use 
Counter64

     if the information being modelled would wrap in less than one hour 
if

!    the Counter32 type was used instead.

  

     There also exist closely-related textual conventions

     ZeroBasedCounter32 and ZeroBasedCounter64 defined in RMON2-MIB

--- 702,710 ----

     this restriction.  Henceforth "standard" MIB modules MAY use the

     Counter64 type when it makes sense to do so, and MUST use 
Counter64

     if the information being modelled would wrap in less than one hour 
if

!    the Counter32 type was used instead.  Note also that there is no

!    longer a requirement to define Counter32 counterparts for each

!    Counter64 object, although one is still allowed to do so.

  

     There also exist closely-related textual conventions

     ZeroBasedCounter32 and ZeroBasedCounter64 defined in RMON2-MIB

***************

*** 701,707 ****

  

     The only difference between ZeroBasedCounter32/64 TCs and

     Counter32/64 is their starting value;  at time=X, where X is 
their

!    minimum-wrap-time after they were created, the behaviour of

     ZeroBasedCounter32/64 becomes exactly the same as Counter32/64.

     Thus, the preceding paragraphs/rules apply not only to 
Counter32/64,

     but also to ZeroBasedCounter32/64 TCs.

--- 712,718 ----

  

     The only difference between ZeroBasedCounter32/64 TCs and

     Counter32/64 is their starting value;  at time=X, where X is 
their

!    minimum-wrap-time after they were created, the behavior of

     ZeroBasedCounter32/64 becomes exactly the same as Counter32/64.

     Thus, the preceding paragraphs/rules apply not only to 
Counter32/64,

     but also to ZeroBasedCounter32/64 TCs.

***************

*** 1360,1366 ****

     the differences between two revisions of a MIB module.  Please see

     http://www.ops.ietf.org/mib-review-tools.html for more 
information.

  

! Acknowledgments

  

     Most of the material on usage of data types was based on input

     provided by Bert Wijnen with assistance from Keith McCloghrie, 
David

--- 1371,1377 ----

     the differences between two revisions of a MIB module.  Please see

     http://www.ops.ietf.org/mib-review-tools.html for more 
information.

  

! 5.  Acknowledgments

  

     Most of the material on usage of data types was based on input

     provided by Bert Wijnen with assistance from Keith McCloghrie, 
David

***************

*** 1373,1384 ****

     and to the contributors who supplied the material for that list.

     Finally, thanks are due to the following individuals whose 
comments

     on earlier versions of this memo contained many valuable 
suggestions

!    for additions, clarifications, and corrections:  Andy Bierman, 
David

!    Harrington, Harrie Hazewinkel, Michael Kirkham, Keith McCloghrie,

!    David T. Perkins, Randy Presuhn, Dan Romascanu, Juergen

!    Schoenwaelder, Frank Strauss, Dave Thaler, and Bert Wijnen.

  

! Security Considerations

  

     Implementation and deployment of a MIB module in a system may 
result

     in security risks that would not otherwise exist.  It is important

--- 1384,1396 ----

     and to the contributors who supplied the material for that list.

     Finally, thanks are due to the following individuals whose 
comments

     on earlier versions of this memo contained many valuable 
suggestions

!    for additions, clarifications, and corrections:  Andy Bierman, Bob

!    Braden, Michelle Cotton, Joseph Dinakaran, David Harrington, 
Harrie

!    Hazewinkel, Michael Kirkham, Keith McCloghrie, David T. Perkins,

!    Randy Presuhn, Dan Romascanu, Juergen Schoenwaelder, Frank 
Strauss,

!    Dave Thaler, and Bert Wijnen.

  

! 6.  Security Considerations

  

     Implementation and deployment of a MIB module in a system may 
result

     in security risks that would not otherwise exist.  It is important

***************

*** 1387,1402 ****

     http://www.ops.ietf.org/mib-security.html so that all such risks 
are

     adequately disclosed.

  

! IANA Considerations

! 

!    NOTE TO RFC Editor:  this section is to be removed prior to

!    publication as an RFC.

! 

!    The IANA is requested to review the portions of this memo dealing

!    IANA Considerations sections in MIB documents to make sure that 
the

!    proposed guidelines are acceptable.

  

!    This document does not require that the IANA update any existing

     registry or create any new registry.

  

  Appendix A:  MIB Review Checklist

--- 1399,1409 ----

     http://www.ops.ietf.org/mib-security.html so that all such risks 
are

     adequately disclosed.

  

! 7.  IANA Considerations

  

!    This document affects the IANA to the extent that it describes 
what

!    is required to be present in the IANA Considerations Section of a 
MIB

!    document, but it does not require that the IANA update any 
existing

     registry or create any new registry.

  

  Appendix A:  MIB Review Checklist

***************

*** 1420,1449 ****

     approved SNMP Network Management Framework boilerplate from the 
OPS

     area web site (http://www.ops.ietf.org/mib-boilerplate.html).

  

!    4.) IPR Notice -- verify that the draft contains a verbatim copy 
of

!    the IPR notice specified in Section 5 of RFC 3668.

! 

!    5.) References -- verify that the references are properly divided

!    between normative and informative references, that RFC 2119 is

!    included as a normative reference if the terminology defined 
therein

!    is used in the document, that all references required by the

!    boilerplate are present, that all MIB modules containing imported

!    items are cited as normative references, and that all citations 
point

!    to the most current RFCs unless there is a valid reason to do

!    otherwise (for example, it is OK to include an informative 
reference

!    to a previous version of a specification to help explain a feature

!    included for backward compatibility).

! 

!    6.) Security Considerations Section -- verify that the draft uses 
the

     latest approved template from the OPS area web site

     (http://www.ops.ietf.org/mib-security.html) and that the 
guidelines

     therein have been followed.

  

!    7.) IANA Considerations Section -- this section must always be

     present.  If the draft requires no action from the IANA, ensure 
that

     this is explicitly noted.  If the draft requires OID values to be

     assigned, ensure that the IANA Considerations section contains the

!    information specified in Section 3.7 of these guidelines.  If the

     draft contains the initial version of an IANA-maintained module,

     verify that the MODULE-IDENTITY invocation contains maintenance

     instructions that comply with the requirements in RFC 2434.  In 
the

--- 1427,1442 ----

     approved SNMP Network Management Framework boilerplate from the 
OPS

     area web site (http://www.ops.ietf.org/mib-boilerplate.html).

  

!    4.) Security Considerations Section -- verify that the draft uses 
the

     latest approved template from the OPS area web site

     (http://www.ops.ietf.org/mib-security.html) and that the 
guidelines

     therein have been followed.

  

!    5.) IANA Considerations Section -- this section must always be

     present.  If the draft requires no action from the IANA, ensure 
that

     this is explicitly noted.  If the draft requires OID values to be

     assigned, ensure that the IANA Considerations section contains the

!    information specified in Section 3.5 of these guidelines.  If the

     draft contains the initial version of an IANA-maintained module,

     verify that the MODULE-IDENTITY invocation contains maintenance

     instructions that comply with the requirements in RFC 2434.  In 
the

***************

*** 1450,1464 ****

     latter case the IANA Considerations section that will appear in 
the

     RFC MUST contain a pointer to the actual IANA-maintained module.

  

!    8.) Copyrights -- verify that the draft contains a copyright 
notice

!    on the front page and in the DESCRIPTION clause of the MODULE-

!    IDENTITY invocation and there is a full copyright notice section 
with

!    text matching that in recently published RFCs.  Make sure that the

!    year is up-to-date in all three places.

  

     9.) Other issues -- check for any issues mentioned in

!    http://www.ietf.org/ID-Checklist.html (other than MIB compilation)

!    that are not covered above.

  

     10.) Technical content -- review the actual technical content for

     compliance with the guidelines in this document.  The use of a MIB

--- 1443,1472 ----

     latter case the IANA Considerations section that will appear in 
the

     RFC MUST contain a pointer to the actual IANA-maintained module.

  

!    6.) References -- verify that the references are properly divided

!    between normative and informative references, that RFC 2119 is

!    included as a normative reference if the terminology defined 
therein

!    is used in the document, that all references required by the

!    boilerplate are present, that all MIB modules containing imported

!    items are cited as normative references, and that all citations 
point

!    to the most current RFCs unless there is a valid reason to do

!    otherwise (for example, it is OK to include an informative 
reference

!    to a previous version of a specification to help explain a feature

!    included for backward compatibility).

! 

!    7.) Copyright Notices -- verify that the draft contains an

!    abbreviated copyright notice in the DESCRIPTION clause of each

!    MODULE-IDENTITY invocation and that it contains the full copyright

!    notice and disclaimer specified in Sections 5.4 and 5.5 of RFC 
3907

!    at the end of the document.  Make sure that the correct year is 
used

!    in all copyright dates.

! 

!    8.) IPR Notice -- if the draft does not contains a verbatim copy 
of

!    the IPR notice specified in Section 5 of RFC 3908, recommend that 
the

!    IPR notice be included.

  

     9.) Other issues -- check for any issues mentioned in

!    http://www.ietf.org/ID-Checklist.html that are not covered 
elsewhere.

  

     10.) Technical content -- review the actual technical content for

     compliance with the guidelines in this document.  The use of a MIB

***************

*** 1512,1518 ****

  

     InetAddressType             enumerated INTEGER

     InetAddress                 OCTET STRING (SIZE (0..255))

!    InetAddressPrefixLength     Unsigned32

     InetPortNumber              Unsigned32 (0..65535))

     InetAutonomousSystemNumber  Unsigned32

     InetScopeType               enumerated INTEGER

--- 1520,1526 ----

  

     InetAddressType             enumerated INTEGER

     InetAddress                 OCTET STRING (SIZE (0..255))

!    InetAddressPrefixLength     Unsigned32 (0..2040)

     InetPortNumber              Unsigned32 (0..65535))

     InetAutonomousSystemNumber  Unsigned32

     InetScopeType               enumerated INTEGER

***************

*** 1666,1672 ****

  [RFC2223bis]

              Reynolds, J., and R. Braden, "Instructions to Request for

              Comments (RFC) Authors", work in progress (currently 
<draft-

!             rfc-editor-rfc2223bis-07.txt>).

  

  [RFC2277]   Alvestrand, H., "IETF Policy on Character Sets and

              Languages", BCP 18, RFC 2277, January 1998.

--- 1674,1680 ----

  [RFC2223bis]

              Reynolds, J., and R. Braden, "Instructions to Request for

              Comments (RFC) Authors", work in progress (currently 
<draft-

!             rfc-editor-rfc2223bis-08.txt>).

  

  [RFC2277]   Alvestrand, H., "IETF Policy on Character Sets and

              Languages", BCP 18, RFC 2277, January 1998.

***************

*** 1681,1691 ****

  [RFC2864]   McCloghrie, K. and G. Hanson, "The Inverted Stack Table

              Extension to the Interfaces Group MIB", RFC 2864, June 
2000.

  

! [RFC3667]   Bradner, S., "IETF Rights in Contributions", BCP 78, RFC

!             3667 February 2004.

  

! [RFC3668]   Bradner, S., "Intellectual Property Rights in IETF

!             Technology", BCP 79, RFC 3668, February 2004.

  

  [RFC3593]   Tesink, K., "Textual Conventions for MIB Modules Using

              Performance History Based on 15 Minute Intervals", RFC 
3593,

--- 1689,1699 ----

  [RFC2864]   McCloghrie, K. and G. Hanson, "The Inverted Stack Table

              Extension to the Interfaces Group MIB", RFC 2864, June 
2000.

  

! [RFC3907]   Bradner, S., "IETF Rights in Contributions", BCP 78, RFC

!             3907, January 2005.

  

! [RFC3908]   Bradner, S., "Intellectual Property Rights in IETF

!             Technology", BCP 79, RFC 3908, January 2005.

  

  [RFC3593]   Tesink, K., "Textual Conventions for MIB Modules Using

              Performance History Based on 15 Minute Intervals", RFC 
3593,

***************

*** 1707,1713 ****

              Daniele, M., Haberman, B., Routhier, S. and J.

              Schoenwaelder, "Textual Conventions for Internet Network

              Addresses", work in progress (currently draft-ietf-ops-

!             rfc3291bis-05.txt).

  

  [RFC2287]   Krupczak, C. and J. Saperia, "Definitions of System-Level

              Managed Objects for Applications", RFC 2287, February 
1998.

--- 1715,1721 ----

              Daniele, M., Haberman, B., Routhier, S. and J.

              Schoenwaelder, "Textual Conventions for Internet Network

              Addresses", work in progress (currently draft-ietf-ops-

!             rfc3291bis-06.txt).

  

  [RFC2287]   Krupczak, C. and J. Saperia, "Definitions of System-Level

              Managed Objects for Applications", RFC 2287, February 
1998.

***************

*** 1731,1737 ****

  

  [RFC2737bis]

              McCloghrie, K. and A. Bierman, "Entity MIB (Version 3)",

!             work in progress (currently draft-ietf-entmib-v3-04.txt).

  

  Informative References

  

--- 1739,1745 ----

  

  [RFC2737bis]

              McCloghrie, K. and A. Bierman, "Entity MIB (Version 3)",

!             work in progress (currently draft-ietf-entmib-v3-05.txt).

  

  Informative References

  

***************

*** 1797,1806 ****

  

  Full Copyright Statement

  

!    Copyright (C) The Internet Society (2004).  This document is 
subject

!    to the rights, licenses and restrictions contained in BCP 78, and

!    except as set forth therein, the authors retain all their rights.

  

     This document and the information contained herein are provided on 
an

     "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
REPRESENTS

     OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, AND THE 
INTERNET

--- 1805,1816 ----

  

  Full Copyright Statement

  

!    Copyright (C) The Internet Society (2005).

  

+    This document is subject to the rights, licenses and restrictions

+    contained in BCP 78, and except as set forth therein, the authors

+    retain all their rights.

+ 

     This document and the information contained herein are provided on 
an

     "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 
REPRESENTS

     OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, AND THE 
INTERNET

***************

*** 2123,2129 ****

        from the modules defined in the SMIv2 documents.

  

        6.)  The instructions for IPR notices in Section 3.4 (and also

!       those in Appendix A) to refer to RFC 3668 instead of RFC 2026.

  

        7.)  In Section 3.5 the [RFC2223bis] section number reference 
was

        updated to match <draft-rfc-editor-rfc2223bis-07.txt>, and text

--- 2133,2139 ----

        from the modules defined in the SMIv2 documents.

  

        6.)  The instructions for IPR notices in Section 3.4 (and also

!       those in Appendix A) now refer to RFC 3668 instead of RFC 2026.

  

        7.)  In Section 3.5 the [RFC2223bis] section number reference 
was

        updated to match <draft-rfc-editor-rfc2223bis-07.txt>, and text

***************

*** 2169,2175 ****

        3667 and 3668, all references to I-Ds that have since been

        published have been changed to point to the RFCs, and the

        references to RFC 2737 and RFC 3291 were replaced by references 
to

!       the I-Ds that update those documents.  Note that RFC2373bis and

        RFC3291bis are both normative references since Appendix B lists

        some TCs from those drafts that are available nowhere else.

  

--- 2179,2185 ----

        3667 and 3668, all references to I-Ds that have since been

        published have been changed to point to the RFCs, and the

        references to RFC 2737 and RFC 3291 were replaced by references 
to

!       the I-Ds that update those documents.  Note that RFC2737bis and

        RFC3291bis are both normative references since Appendix B lists

        some TCs from those drafts that are available nowhere else.

  

***************

*** 2176,2181 ****

--- 2186,2258 ----

        17.) An IANA Considerations section (to be removed upon

        publication) was added, and the Open Issues section was removed.


  

+    The following changes were made to <draft-ietf-ops-mib-review-

+    guidelines-03.txt> to produce <draft-ietf-ops-mib-review-

+    guidelines-04.txt>:

+ 

+       1.)  The I-D boilerplate on the front page was updated to 
comply

+       with http://www.ietf.org/ietf/1id-guidelines.txt.

+ 

+       2.)  The introductory part of Section 3 has been wordsmithed to

+       align it with http://www.ietf.org/ietf/1id-guidelines.txt,

+       http://www.ietf.org/ID-Checklist.html, and RFC2223bis, and the

+       sub-sections have been re-ordered to match the order 
recommended

+       by RFC 2223bis for sections in an RFC.  As a result, the 
following

+       section numbers have changed:

+ 

+       -03 Section Number      -04 Section Number

+               3.4                     3.8

+               3.5                     3.6

+               3.6                     3.4

+               3.7                     3.5

+               3.8                     3.7

+ 

+       3.)  The instructions for copyright notices in Section 3.7 (and

+       also those in Appendix A) refer to RFC 3907 instead of RFC 
3667,

+       and the wording for the abbreviated notice used in 
IANA-maintained

+       was changed so that it agrees with RFC  3907.  In addition, the

+       requirement to check for the presence of a copyright notice on 
the

+       front page of a document has been deleted from Appendix A, 
since

+       Internet-Drafts no longer require such a notice.

+ 

+       4.)  The instructions for IPR notices in Section 3.8 (and also

+       those in Appendix A) now refer to RFC 3908 instead of RFC 3668.

+       In addition, these sections treat the notice as a SHOULD, since

+       the IPR notice is no longer required in Internet-Drafts 
(although

+       it is recommended)

+ 

+       5.)  Text has been added to Section 4.6.1.2 to clarify that 
there

+       is no longer a requirement to define a Counter32 counterpart 
for

+       each Counter64 object.

+ 

+       6.)  The Acknowledgments, Security Considerations, and IANA

+       Considerations sections have been relocated before the 
appendices,

+       as recommended by RFC 2223bis, and the Intellectual Property

+       Section has been relocated to the end of the document, as 
required

+       by RFC 2223bis (and in accordance with the practice in recent

+       RFCs).

+ 

+       7.)  Several previously unacknowledged individuals who have

+       provided helpful comments have been named in the 
Acknowledgments

+       section.

+ 

+       8.)  The IANA Considerations section is now non-null, and the

+       editor's note requesting that it be removed prior to 
publication

+       has been deleted.

+ 

+       9.)  The checklist items in Appendix A have been re-ordered to

+       match the order of presentation in Section 3.

+ 

+       10.) Appendix B now correctly lists the SYNTAX of

+       InetAddressPrefixLength as Unsigned32 (0..2040).

+ 

+       11.) The references to RFCs 3667 and 3668 were replaced by

+       references to RFCs 3907 and 3908, and the references to RFC

+       2223bis, RFC 2737bis and RFC 3291bis were updated to point to 
the

+       most current drafts.

+ 

+       12.) Several typos and spelling errors were corrected.

+ 

        ************************************************************

        * NOTES TO RFC Editor (to be removed prior to publication) *

        *                                                          *

***************

*** 2199,2204 ****

        * occurrences of "2737bis" with the number of that RFC.    *

        *                                                          *

        * 4.) The "Editor's Notes" and "Notes to RFC Editor" in    *

!       * Sections 3.7, 3.8, and 4.5 are examples to authors and   *

        * are intended to appear in the final text.                *

        ************************************************************

--- 2276,2281 ----

        * occurrences of "2737bis" with the number of that RFC.    *

        *                                                          *

        * 4.) The "Editor's Notes" and "Notes to RFC Editor" in    *

!       * Sections 3.5, 3.7, and 4.5 are examples to authors and   *

        * are intended to appear in the final text.                *

        ************************************************************

Follow-Ups:
- Test, please ignore
  - From: "C. M. Heard" <heard@pobox.com>

Prev by Date: Proposed "Last Call" version of draft-ietf-ops-mib-review-guidelines [ Corrected ]
Next by Date: Test, please ignore
Previous by thread: Proposed "Last Call" version of draft-ietf-ops-mib-review-guidelines [ Corrected ]
Next by thread: Test, please ignore
Index(es):
- Date
- Thread