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

MIB review guidelines proof approved by editor

FYI, I just gave the go-ahead to the RFC Editor to publish the
document.  The announcement should appear soon.  //cmh

---------- Forwarded message ----------
Date: Thu, 22 Sep 2005 12:43:13 -0700 (PDT)
From: C. M. Heard <heard@pobox.com>
To: Alice Hagens <hagens@ISI.EDU>
Cc: bwijnen@lucent.com, david.kessens@nokia.com, rfc-editor@rfc-editor.org
Subject: Re: authors 48 hours: BCP 111,
     RFC 4181 <draft-ietf-ops-mib-review-guidelines-04.txt> NOW AVAILABLE

Alice,

Thank you for making the corrections that I requested.  As far as I
am concerned the document is ready to go.

Regards,

Mike Heard


On Thu, 22 Sep 2005, Alice Hagens wrote:

>Mike,
>
>We have corrected the text as requested and posted the revised version
>of the document at:
>
>   ftp://ftp.rfc-editor.org/in-notes/authors/rfc4181.txt
>
>
>We have placed a new diff file at:
>
>   ftp://ftp.rfc-editor.org/in-notes/authors/rfc4181-diff.html
>
>Please be sure to review the document again to ensure satisfaction as
>we do not make changes once the draft has been published as an RFC.
>
>Note that it may be necessary for you to refresh your browser to view
>the most up-to-date version of the document.
>
>We will wait to hear from you again before continuing on with the
>publication process.
>
>Thank you.
>
>RFC Editor/ah
>
>>X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs
>>Date: Wed, 21 Sep 2005 20:07:58 -0700 (PDT)
>>From: "C. M. Heard" <heard@pobox.com>
>>X-Sender: heard@shell4.bayarea.net
>>To: RFC Editor <rfc-editor@rfc-editor.org>
>>cc: Bert Wijnen <bwijnen@lucent.com>, "Kessens, David" 
><david.kessens@nokia.com>
>>Subject: Re: authors 48 hours: BCP 111, RFC 4181 
><draft-ietf-ops-mib-review-guidelines-04.txt> NOW AVAILABLE
>>MIME-Version: 1.0
>>X-ISI-4-43-8-MailScanner: Found to be clean, Found to be clean
>>X-MailScanner-From: rfc-ed
>>X-Spam-Checker-Version: SpamAssassin 2.64 (2004-01-11) on boreas.isi.edu
>>X-Spam-Level: 
>>X-Spam-Status: No, hits=0.1 required=5.0 tests=AWL autolearn=ham version=2.64
>>
>>Greetings,
>>
>>In reviewing the proof of RFC 4181 that was posted on 19 Sept 2005
>>I found the following minor errors:
>>
>>In the first paragraph of Section 3.2, near the top of p. 5, there
>>is an extra blank line:
>>
>>OLD:
>>   The narrative part MUST include an overview section that describes
>>   the scope and field of application of the MIB modules defined by the
>>
>>   specification and that specifies the relationship (if any) of these
>>   MIB modules to other standards, particularly to standards containing
>>   other MIB modules.  The narrative part SHOULD include one or more
>>   sections to briefly describe the structure of the MIB modules defined
>>   in the specification.
>>
>>NEW:
>>   The narrative part MUST include an overview section that describes
>>   the scope and field of application of the MIB modules defined by the
>>   specification and that specifies the relationship (if any) of these
>>   MIB modules to other standards, particularly to standards containing
>>   other MIB modules.  The narrative part SHOULD include one or more
>>   sections to briefly describe the structure of the MIB modules defined
>>   in the specification.
>>
>>
>>In Section 4.5, there is a formatting problem in last paragraph on
>>p. 13:
>>
>>OLD:
>>   When the initial version of a MIB module is under development, the
>>   value assigned to the MODULE-IDENTITY descriptor will be unknown if
>>   an IANA-assigned value is used, because the assignment is made just
>>   prior to publication as an RFC.  The accepted form for the MODULE-
>>   IDENTITY statement in draft versions of such a module is something
>>   along the following lines:
>>
>>      <descriptor> MODULE-IDENTITY
>>
>>          [ ... ]
>>
>>          ::= { <subtree> XXX } -- RFC Ed.: replace XXX with IANA-
>>   assigned number & remove this note where <descriptor> is whatever
>>   descriptor has been selected for the module and <subtree> is the
>>   subtree under which the module is to be registered (e.g., mib-2 or
>>   transmission).  Note that XXX must be temporarily replaced by a
>>   number in order for the module to compile.
>>
>>NEW:
>>   When the initial version of a MIB module is under development, the
>>   value assigned to the MODULE-IDENTITY descriptor will be unknown if
>>   an IANA-assigned value is used, because the assignment is made just
>>   prior to publication as an RFC.  The accepted form for the
>>   MODULE-IDENTITY statement in draft versions of such a module is
>>   something along the following lines:
>>
>>      <descriptor> MODULE-IDENTITY
>>
>>          [ ... ]
>>
>>          ::= { <subtree> XXX }
>>   -- RFC Ed.: replace XXX with IANA-assigned number & remove this note
>>
>>   where <descriptor> is whatever descriptor has been selected for the
>>   module and <subtree> is the subtree under which the module is to be
>>   registered (e.g., mib-2 or transmission).  Note that XXX must be
>>   temporarily replaced by a number in order for the module to compile.
>>
>>
>>In the last paragraph of Section 4.6.1.1, at the top of p. 16, an
>>ASN.1 module name has been mangled by an inappropriate acronym
>>expansion:
>>
>>OLD:
>>   Note that INTEGER is a predefined ASN.1 type and MUST NOT be present
>>   in a module's IMPORTS statement, whereas Integer32, Gauge32, and
>>   Unsigned32 are defined by Simple Network Management Protocol Version
>>   2 (SNMPv2)-SMI and MUST be imported from that module if used.
>>
>>NEW:
>>   Note that INTEGER is a predefined ASN.1 type and MUST NOT be present
>>   in a module's IMPORTS statement, whereas Integer32, Gauge32, and
>>   Unsigned32 are defined by SNMPv2-SMI and MUST be imported from that
>>   module if used.
>>
>>The issue here is that "SNMPv2-SMI" is an ASN.1 module name, NOT an
>>acronym, and it must not be expanded (it must be used as-is in an
>>IMPORTS clause).
>>
>>
>>In Section 4.6.4, an editorial change to the has altered the meaning
>>of the second bullet item in the first bullet list near the middle
>>of p. 21.  It is requested that the original text be restored.
>>
>>OLD:
>>     - If the row is an element of an expansion table -- that is, if
>>       multiple-row instances correspond to a single-row instance in
>>       some other table -- then an INDEX clause MUST be used, and the
>>       first-mentioned elements SHOULD be the indices of that other
>>       table, listed in the same order.
>>
>>ORIGINAL TEXT:
>>     - If the row is an element of an expansion table -- that is, if
>>       multiple row instances correspond to a single row instance in
>>       some other table -- then an INDEX clause MUST be used, and the
>>       first-mentioned elements SHOULD be the indices of that other
>>       table, listed in the same order.
>>
>>The issue here is that there is no such thing as a multiple-row
>>instance or a single-row instance.  The phrase "multiple row
>>instances" was intended to mean "more than one row instance" or
>>"several row instances" (in the expansion table), and the phrase "a
>>single row instance" was intended to mean "exactly one row instance"
>>(in the other table).  If it is in line with RFC style guidelines to
>>use the hyphenated term "row-instance" in place of "row instance" I
>>would be OK with that, as it would preserve my intended meaning.
>>
>>
>>In Section 4.9, there is a typo in the first sentence of second
>>paragraph on p. 31:
>>
>>OLD:
>>
>>   In certain exceptional situations, the cost of strictly following the
>>   SMIv2 rules governing MIB modules revisions may exceed the benefit.
>>_____________________________^^^^^^^
>>
>>NEW:
>>   In certain exceptional situations, the cost of strictly following the
>>   SMIv2 rules governing MIB module revisions may exceed the benefit.
>>_____________________________^^^^^^
>>
>>That, by the way, was the only typo in the original draft that was
>>reported to me that the RFC Editor did not catch.  Kudos for a job
>>well done.
>>
>>Regards,
>>
>>Mike Heard
>>
>>
>>On Mon, 19 Sep 2005, RFC Editor wrote:
>>
>>> ****IMPORTANT*****
>>> 
>>> Updated 2005/09/19
>>> 
>>> RFC AUTHOR(S):
>>> --------------
>>> 
>>> This is your LAST CHANCE to make changes to your RFC to be:
>>> draft-ietf-ops-mib-review-guidelines-04.txt, once the document is
>>> published as an RFC we *WILL NOT* make any changes.  
>>> 
>>> Please check your document at
>>> 
>>>    ftp://ftp.rfc-editor.org/in-notes/authors/rfc4181.txt
>>> 
>>> ATTENTION: The editing process occasionally introduces errors that
>>> were not in the Internet Draft.  Although the RFC Editor tries very
>>> hard to catch all errors, proofreading the text at least twice, typos
>>> can slip through.  You, as an author of the RFC, are taking
>>> responsibility for the correctness of the final product when you OK
>>> publication.  You should therefore proofread the entire RFC carefully
>>> and without assumptions.  Errors in RFCs last forever.  
>>> 
>>> NOTE: We have run a diff tool that compares the approved internet-draft
>>> against our edited RFC version of the document.  Please review this
>>> file at:
>>> 
>>>    ftp://ftp.rfc-editor.org/in-notes/authors/rfc4181-diff.html
>>> 
>>> The document will NOT BE PUBLISHED until ALL of the authors listed in
>>> the RFC have affirmed that the document is ready to be
>>> published, as ALL of the authors are equally responsible for verifying
>>> the documents readiness for publication.
>>> 
>>> ** Please send us a list of suitable keywords for this document, over
>>> and above those which appear in the title.  
>>> 
>>> 	Frequently INCORRECT information includes
>>> 
>>> 	- Contact Information
>>> 	- References (are they up to date)
>>> 	- Section Numbers
>>> 	  (especially if you originally put the copyright somewhere 
>>> 	  other than the VERY end of the document, or if you numbered
>>> 	  the "Status of the Memo" field)
>>> 
>>> Please send us the changes, *DO NOT* send a new document with the
>>> changes made.  (If we think that the changes might be more than
>>> editorial we will contact the AD or the IESG to confirm that the
>>> changes do not require review.)
>>> 
>>> Send us the changes in THIS format.
>>> 
>>> 	1)*** SECTION #'s***  [i.e. Section 5, 2nd paragraph] 
>>> 	2) the text you want changed, 
>>> 	3) the new correct text and 
>>> 	4) if the changes are spacing or indentation than please note 
>>> 	   that.
>>> 
>>> FOR EXAMPLE:
>>> 
>>> 	Section 5.6, 3rd paragraph
>>> 
>>>  	OLD: 
>>> 		The quick brown fox jumped over the lazy dog.
>>> 
>>> 	NEW: 
>>> 		The quick brown dog jumps over the lazy fox.
>>> 				^^^     ^               ^^^
>>> 
>>> If you have a whole paragraph to replace you do not need to use
>>> the arrow to point out the differences
>>> 
>>> 	INTRODUCTION, 2nd paragraph
>>> 
>>> 	Replace OLD:
>>> 
>>> 		alsdfja;sldjf;lajsd;fljas;dlfj;
>>> 
>>> 	With NEW:
>>> 		
>>> 		nv;alkjd;lsf;aoisj;ltjka;sldkjf	
>>> 
>>> 
>>> Spacing or indentation problems...
>>> 
>>> 	Section 10, 1st paragraph (remove spaces between bit 
>>> 	and of, add space after butter)
>>> 
>>> 	OLD:
>>> 
>>> 	Better botter bought a bit
>>> 		of bitter butterMary mary quite contrary
>>> 
>>> 	NEW:
>>> 
>>> 	Better botter bought a bit of bitter butter
>>> 
>>> 	Mary mary quite contrary
>>> 
>>> 
>>> This document will NOT be published until we receive agreement, from
>>> ALL listed authors, that the document is ready for publication.
>>> 
>>> Thanks for your cooperation,
>>> 
>>> 
>>> -RFC Editor
>>> 
>>
>