[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: authors 48 hours: BCP 111, RFC 4181 <draft-ietf-ops-mib-review-guidelines-04.txt> NOW AVAILABLE (fwd)
On Mon, 19 Sep 2005, C. M. Heard wrote:
> I will be looking at the document tonight, and I intend (if all
> goes well) to give a response to the RFC Editor within 48 hours.
> If anyone else wishes to comment please send your comments to
> the mreview list before then. I'm mainly interested in knowing
> if any editorial errors that I introduced remain uncorrected, or
> if any new ones have crept in.
My list of errata is attached below my signature. I also noticed
several cases where hyphenated SMIv2 keywords (e.g., read-write and
MODULE-IDENTITY) were broken across lines, which is something that I
went out of my way to prevent when I prepared the draft. I have not
included that stuff in my errata list, but I could do so if it is
though to be sufficiently important. Opinions are solicited. If I
don't hear anything, I won't do anything.
Mike
--cut here--
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, a
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 a module name, NOT an
acronym, and it must not be expanded (it is used literally 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 top 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).
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.
_____________________________^^^^^^