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

Re: snmpconf Comments on BCP-09




A couple of grammatical typos that I spotted in the new text:

> >24) Section 6.3, last sentence, repeats often incorrect
> >     security warning....
>    ......  Here it is (paragraph 2 of the section has turned into two 
> paragraphs now):
> 
>                                            ...... When notifications are
> sent in SNMPv1 trap PDUs, unsolicited packets to a device can causes one
> or more trap PDUs to be created......                     ^^^^^^^^^^
                                                            "can cause"
                   vv
>       .........  If it is bad enough that the system is having to
> respond to and recover from the invalid agent data accesses, but the
> problem will be compounded if a separate Autentication notification
> PDU is sent to each recipient on the management network.

Extraneous "If".


> >35) MIB module, object bldgHVACoolOrHeatMins.
>      bldgHVACDiscontinuityTime OBJECT-TYPE
>          DESCRIPTION
>              no such discontinuities have occurred since the last re-
>              initialization of the this row,....
                                 ^^^^^^^^
                               just "this"

> >6a) In section 3.3.1 ....

> The section now reads as follows....:

>    2)                      ........... *Restricting instance
>       modifiability like this, so that after a RowStatus object is
>       set to active(1) is in fact a reasonable limitation,...

This doesn't make sense (even in full).
Is there something missing after "set to active(1)" ?
Or perhaps it should read something like:

   "Restricting instance modifiability after a RowStatus object is
    set to active(1) is in fact a reasonable limitation...."

But the "like this, so that" clause throws things off somewhat.


---------------

And a couple of "understandability comments" from a lurker.
These may be unnecessary, or too late - so feel free to ignore them.

Still with the
> >6a) In section 3.3.1 ....
                                stuff

> The RowStatus textual convention specifies that, when used
> in a conceptual row, a description must define what can be modified.
                       ^^^^^^^^^^^^^

Is it worth specifying which description this should come in?
i.e. "the RowStatus object description must define...."

Because this could potentially be the description of the table, of the
row entry, of the writeable column object, or the RowStatus object.
(Unless the MIB designer has read the details of the RowStatus description
very carefully).
  I know you mention the later, after the example - but that's a little
way further on (and currently on the next page) so is easy to miss.


Also it's easy to misunderstand the two "wrong assumptions" being described
here as being discussions of "wrong implementation approaches" (i.e. the
exact opposite of what is intended).   Particularly with the discussion
of the second case as being a reasonable limitation - this detracts from
the fundamental point that this is an optional limitation, rather than
a mandatory requirement.
  This might be a bit clearer if the discussion of why you might want
to do this was detached from the basic "wrong assumption" description.
I.e:

>   ..... it is often wrongly assumed in some implementations
> that:
> 
>    1) objects either must all be presently set or none need be set
>       to make a conceptual RowStatus object transition to active(1)
>    2) objects in a conceptual row cannot be modified once a
>       RowStatus object is active(1).

  " Both of these are reasonable limitations, but need not necessarily
  hold true.  For example, a set of RowStatus may have agent system
  side-effects which depend on committed columnar object instance values,
  so restricting instance modifiability after a RowStatus object is
  set to active(1) may be appropriate.
    However, where this restriction exists...."




> >28) MIB module,                               .... There
> >     needs to be a REVISION clause that specifies when the
> >     module was created. And there may be a REVISION clause
> >     missing for the last update.

> Do you really want the back and forth of the working group review of this 
> *EXAMPLE* MIB module cluttering up the document?

It might be worth having "initial" and "first review" revision log entries,
in order to show the effect of a single revision cycle.  Anything more
would probably be unnecessary, but the fact that the original example
contained a mismatch between LAST-UPDATED and the (sole) REVISION datestamp
shows that even experienced MIB designers can get this wrong.



Dave