Rptr MIB Edits

[John Flick <[e-mail]>]

Yesterday, I sent a list of issues raised by the review of the
VG Rptr MIB draft.  Some of these result in no-brainer edits to
the documents, and I will summarize those edits here.  For the
others, I will send out subsequent messages with the changed
text.

Again, I would like to come to consensus on this pretty quickly,
so please review and comment.

Issue 1:

>Front Matter
>
>    Missing an "Abstract" paragraph.

Seems like we can just rename the Introduction section to "Abstract",
and remove the section number.  This will renumber the subsequent
sections.


Issue 3:

>3.4. Structure of the MIB
>
>    Introducing the term "package" is unnecessary in my opinion (and
>may be confusing to those familiar with GDMO terminology). You could
>just say the OID subtrees are organized around basic and monitor
>objects and that there is no relation to the conformance groups.

Reword that section as follows:

   Objects in this MIB are arranged into OID subtrees, each of which
   contains a set of related objects within a broad functional category.
   These subtrees are intended for organizational convenience ONLY, and
   have no relation to the conformance groups defined later in the
   document.


Issue 4:

>3.5 Relationship to other MIBs
>3.5.1.1. Relationship to the 'system' group
>
>    Perhaps you should discuss the relationship to the Entity MIB. Or
>at least clarify that the implementor should support one instance of
>the objects in the system group regardless of how many repeaters
>(entries in the vgRptrInfoTable) there are.

Add the following paragraph to the end of the section:

   Note that all of the managed repeaters (i.e. entries in the
   vgRptrInfoTable) will normally exist within a single naming scope.
   Therefore, there will normally only be a single instance of each of
   the objects in the system group for the entire managed repeater
   system regardless of how many managed repeaters there are in the
   system.


Issue 6:

>vgRptrInfoTable DESCRIPTION
>
>    Curious what a "non-trivial" 802.12 repeater is. It's probably
>covered in a reference document, but it would hurt to explain it a bit
>in a parenthetical comment or some such.

The concept of a trivial repeater is somewhat confusing and not really
relevant to this MIB.  I am also not aware of any existing implementations
that support trivial repeaters (also known as isolated ports).  I suggest
just removing the term "non-trivial" from the descriptions of
vgRptrInfoTable and vgRptrInfoEntry.


Issue 7:

>vgRptrInfoDesiredFramingType DESCRIPTION
>
>    You explicitly say "The value of this object should be preserved
>across repeater resets and power failures" here, but you don't say
>that for other read-write objects in the MIB. Does this mean the
>others do not need to be preserved and the user has to reconfigure
>every time? 

The following writable objects should be preserved across reset:

    vgRptrInfoDesiredFramingType
    vgRptrGroupCablesBundled
    vgRptrPortAdminStatus
    vgRptrPortAllowedTrainType
    vgRptrPortPriorityEnable

Some of them said so explicitly.  Some did not.  Some had text buried
in the middle of the description that said so that you kind of had to
look for.  I will add, as a separate paragraph, the last paragraph in
each description, the following text:

          The value of this object should be preserved
          across repeater resets and power failures.

The following writable objects do not need to be preserved across reset:

    vgRptrInfoReset              - obviously
    vgRptrMgrDetectedDupAddress  - debatable, but I would say no



Issue 9:

>Compliances
>
>    Perhaps there should be a compliance statement that allows the
>Counter64s to be left out? 

Just move the Counter64s from vgRptrStatsGroup to a new
vgRptrStats64Group, and add the following to the compliance statement:

          GROUP        vgRptrStats64Group
          DESCRIPTION
                 "Implementation of this group is recommended
                 for systems which can support Counter64."


Issue 10:

>Compliance statement should allow vgRptrInfoDesiredFramingType
>to have a MIN-ACCESS of read-only, since it is perfectly
>legal to have a .12 repeater that supports only one frame type.

Add the following to the compliance statement:

          OBJECT       vgRptrInfoDesiredFramingType
          MIN-ACCESS   read-only
          DESCRIPTION
                  "Write access to this object is not required
                  in a repeater system that does not support
                  configuration of framing types."


Issue 11:

>The 802.3 Repeater MIB compliance section was changed to make
>the monitor group and address tracking group mandatory rather
>than optional.  I forgot to track that change in our draft.


Change the MANDATORY-GROUPS in the compliance statement to:

        MANDATORY-GROUPS { vgRptrConfigGroup,
                           vgRptrStatsGroup,
                           vgRptrAddrGroup,
                           vgRptrNotificationsGroup }


I will send out separate messages on issues 2, 5, and 8, since
they involve significant new text.

John