Re: REQUIRED, MUST, etc...

["C. M. Heard" <heard@pobox.com>]

On Mon, 28 Apr 2003, Romascanu, Dan (Dan) wrote:
> While working on a MIB review and using the 'Guidelines...'
> document as a reference I ran over a few instances of key words
> which seem to be written with minuscules, contrary to the
> convention. See for example the second paragraph in Section 3.2.
> You might want to look at these, and correct if you agree.

Dan is quite correct, and I thank him for the heads-up.  After a
quick look at the document, I found some other stuff in sections
3.8, 4.9, and item #7 of the checklist (for which I had previously
posted a correction.  The context diff attached below shows the
proposed changes.

Note that there are many occurrences of "must", "required", and so
that are not capitalized because they are used in the ordinary way
(rather than the special sense defined in RFC 2119) and I haven't
proposed to change those.

Thanks,

Mike Heard

*** draft-ietf-ops-mib-review-guidelines-01.txt	Mon Feb 24 09:27:55 2003
--- draft-ietf-ops-mib-review-guidelines-XX.txt	Mon Apr 28 08:14:03 2003
***************
*** 285,295 ****
     MUST be noted in the overview section, as MUST any special
     interpretations of objects in other MIB modules.  For instance, so-
     called media-specific MIB modules are always implemented in
!    conjunction with the IF-MIB [RFC2863] and are required to document
     how certain objects in the IF-MIB are used.  In addition, media-
     specific MIB modules that rely on the ifStackTable [RFC2863] and the
     ifInvStackTable [RFC2864] to maintain information regarding
!    configuration and multiplexing of interface sublayers must contain a
     description of the layering model.
  
  3.3.  Definitions Section
--- 285,295 ----
     MUST be noted in the overview section, as MUST any special
     interpretations of objects in other MIB modules.  For instance, so-
     called media-specific MIB modules are always implemented in
!    conjunction with the IF-MIB [RFC2863] and are REQUIRED to document
     how certain objects in the IF-MIB are used.  In addition, media-
     specific MIB modules that rely on the ifStackTable [RFC2863] and the
     ifInvStackTable [RFC2864] to maintain information regarding
!    configuration and multiplexing of interface sublayers MUST contain a
     description of the layering model.
  
  3.3.  Definitions Section
***************
*** 424,438 ****
  3.8.  Copyright Notices
  
     IETF MIB documents MUST contain the copyright notices specified in
     Section 4.3 of RFC 2223bis [RFC2223bis] and Section 10.4 Bullet (C)
     of RFC 2026 [RFC2026].  Authors and reviewers MUST check 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 published RFC must contain a pointer
     to the copyright notices in the RFC.  A template suitable for
     inclusion in an Internet Draft is as follows:
  
            DESCRIPTION
              " [ ... ]
  
              Copyright (C) The Internet Society (date).  This version
--- 424,438 ----
  3.8.  Copyright Notices
  
     IETF MIB documents MUST contain the copyright notices specified in
     Section 4.3 of RFC 2223bis [RFC2223bis] and Section 10.4 Bullet (C)
     of RFC 2026 [RFC2026].  Authors and reviewers MUST check 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 published RFC MUST contain a pointer
     to the copyright notices in the RFC.  A template suitable for
     inclusion in an Internet Draft is as follows:
  
            DESCRIPTION
              " [ ... ]
  
              Copyright (C) The Internet Society (date).  This version
***************
*** 1405,1415 ****
  4.9.  Revisions to MIB Modules
  
     RFC 2578 Section 10 specifies general rules that apply any time a MIB
     module is revised.  Specifically:
  
!    - The MODULE-IDENTITY invocation must be updated to include
       information about the revision.  In particular, the LAST-UPDATED
       clause value MUST be set to the revision time, a REVISION clause
       with the same UTC time and an associated DESCRIPTION clause
       describing the changes MUST be added, and any obsolete information
       in the existing DESCRIPTION, ORGANIZATION, and CONTACT-INFO clauses
--- 1405,1415 ----
  4.9.  Revisions to MIB Modules
  
     RFC 2578 Section 10 specifies general rules that apply any time a MIB
     module is revised.  Specifically:
  
!    - The MODULE-IDENTITY invocation MUST be updated to include
       information about the revision.  In particular, the LAST-UPDATED
       clause value MUST be set to the revision time, a REVISION clause
       with the same UTC time and an associated DESCRIPTION clause
       describing the changes MUST be added, and any obsolete information
       in the existing DESCRIPTION, ORGANIZATION, and CONTACT-INFO clauses
***************
*** 1614,1622 ****
     7.) IANA Considerations Section -- if the draft contains the initial
     version of an IANA-maintained module, verify that the MODULE-IDENTITY
     invocation contains maintenance instructions that comply with RFC
!    2434.  Note that module itself must be in an appendix that will
!    disappear after publication and that the IANA Considerations section
!    that will appear in the RFC must contain a pointer to that module.
  
  
  
--- 1614,1622 ----
     7.) IANA Considerations Section -- if the draft contains the initial
     version of an IANA-maintained module, verify that the MODULE-IDENTITY
     invocation contains maintenance instructions that comply with RFC
!    2434.  Note that the IANA Considerations section that will appear in
!    the RFC MUST contain a pointer to that module.
!