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

Test, please ignore



[ testing fix for problem with extra line breaks in attachments --
   please ignore ] 
***************
*** 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.                *
        ************************************************************