802.12 Rptr MIB Draft-- issues

[John Flick <[e-mail]>]

Hi,

Since we still have not heard back from the area directorate on the
review of <draft-ietf-vgmib-repeater-dev-02.txt>, and that draft
has now expired, I have gone ahead and started updating the draft
to respond to Karen's comments on December 6.  We can't exactly argue
that rolling the draft will slow down the directorate's review if the
directorate isn't reviewing.  Here is a summary of the changes I have
made.

Please review this and get back to me with any issues ASAP.  I would
like to submit this on Monday, February 17.  Also, I want to be very
clear that I want this to be the FINAL DRAFT.  PLEASE review it now,
or forever hold your peace.

John
===================================================================
>A>
>	In Section 3.2 Master Mode and Slave Mode, I suggest that both
>occurrences of the phrase "switch ports" be modified to "switch or other
>device ports."   

Done.

>B>
>	In the Allowed Configuration Field descriptive portion of Section 3.
>3 IEEE 802.12 Training Frames, I suggest two changes. 
>
>	First, in the description of when the C-bit is set to 1, I propose 
>that the phrasing be changed to  
>	    "The requested configuration is not compatible with the network
>			and/or the attached port."     
>			^^^^^^^^^^^^^^^^^^^^^^^^

Done.

>	Second, in the final paragraph I propose changing the word 'received'
>in the phrase "24 consecutive training frames be received" to  'exchanged'.
>The latter term applies equally to both sides of the training link, and the
>former implies a single side of the link but does not define which one is
>referred to.

Done.

>C> 
>	In Section 3.5.2 Relationship to the 802.3 Repeater MIB, should the
>second paragraph's reference to "an existing standards-track MIB module" be
>updated to "an existing standard MIB module"?

No change.  The term "standards-track" is correct.

>D>	
>	In Section 3.6 Mapping of IEEE 802.12 Management Objects, the Port
>subsection  .aMediaType    is denoted as not yet mapped. Do we now have a
>mapping for this? Can we use the IEEE 802.12 Interfaces MIB media types?

No change.

>E> 
>	In the Section 4 definition of vgRptrGroupCablesBundled, incorrectly
>states that frames are NEVER buffered for Promiscuous or Cascaded ports,
>even when the attribute is set to someCablesBundled.
>
>	The 802.12 standard requires that GROUP-ADDRESSED frames be buffered
>for ALL links when someCablesBundled is true, and that NO frames be buffered
>for any links when the attribute is set to noCablesBundled.

The vgRptrGroupCablesBundled DESCRIPTION has been rewritten as follows:

               "This object is used to indicate whether there are
               any four-pair UTP links connected to this group
               that are contained in a cable bundle with multiple
               four-pair groups (e.g. a 25-pair bundle).  Bundled
               cable may only be used for repeater-to-end node
               links where the end node is not in promiscuous
               mode.

               When a broadcast or multicast packet is received
               from a port on this group that is not a
               promiscuous or cascaded port, the packet will be
               buffered completely before being repeated if
               this object is set to 'someCablesBundled(1)'.
               When this object is equal to 'noCablesBundled(2)',
               all packets received from ports on this group will
               be repeated as the frame is being received.

               Note that the value 'someCablesBundled(1)' will
               work in the vast majority of all installations,
               regardless of whether or not any cables are
               physically in a bundle, since packets received
               from promiscuous and cascaded ports automatically
               avoid the store and forward.  The main situation
               in which 'noCablesBundled(2)' is beneficial is
               when there is a large amount of multicast traffic
               and the cables are not in a bundle.  The value of
               this object should be preserved across repeater
               resets and power failures."


>F>
>	The Section 4 counter definitions of 
>		vgRptrPortL32ReadableOctets 
>		vgRptrPortL32UnreadableOctets 
>		vgRptrPortL32HighPriorityOctets
>		vgRptrPortL32NormalPriorityOctets
>
>		state "Note that this counter will roll over very quickly." 
>I believe this phrasing should say  'can'  rather than 'will.' 

Done.

>G> 
>	In the Section 4 definition of vgRptrPortMulticastFrames, I believe
>the word  'the'   is missing from the fourth sentence. "Note that when value
>of"  is probably meant to be "Note that when THE value of".

Done.

>H>
>	
>	In the Section 4 definition of vgRptrRptrDetectedDupAddress, the
>description of how this object applies to the cascade port should note that
>this bit may also be set if vgRptrMgrDetectedDupAddress was set to True on
>the other (master) end of the training link.

The vgRptrGroupCablesBundled DESCRIPTION now reads:

               "This object is used to indicate that the
               repeater detected an error-free training frame on
               this port with a non-null source MAC address which
               matches the value of vgRptrAddrLastTrainedAddress
               of another active port in the same repeater.  This
               is reset to 'false' when an error-free training
               frame is received with a non-null source MAC
               address which does not match
               vgRptrAddrLastTrainedAddress of another port which
               is active in the same repeater.

               For the cascade port, this object will be 'true'
               if the 'D' bit in the most recently received
               error-free training response frame was set,
               indicating the device at the other end of the link
               believes that this repeater's cascade port is
               using a duplicate address.  This may be because
               the device at the other end of the link detected a
               duplicate address itself, or, if the other device
               is also a repeater, it could be because
               vgRptrDetectedDupAddress was set to 'true' on the
               port that this repeater's cascade port is
               connected to."

>	As a side note, I might recommend changing the object's name just
>because it presently looks like a stutter. Could we deviate enough from the 
>IEEE naming to call it something like, "vgRptrHardwareDetectedDupAddress" or
>"vgRptrLinkDetectedDupAddress"?

No change.


In addition to Karen's comments, the following updates were made:

1. Updated MODULE IDENTITY:

          vgRptrMIB MODULE-IDENTITY
               LAST-UPDATED "9702132246Z"  -- February 13, 1997
               ORGANIZATION "IETF 100VG-AnyLAN Working Group"
               CONTACT-INFO
                       "WG E-mail: [e-mail]

                            Chair: Jeffrey Johnson
                           Postal: cisco Systems, Inc.
                                   170 W.Tasman Drive
                                   San Jose, CA 94015
                              Tel: [phone]
                           E-mail: [e-mail]

                           Editor: John Flick
                           Postal: Hewlett Packard Company
                                   8000 Foothills Blvd. M/S 5556
                                   Roseville, CA 95747-5556
                              Tel: [phone]
                              Fax: [phone]
                           E-mail: [e-mail]"
               DESCRIPTION
                       "This MIB module describes objects for managing
                       IEEE 802.12 repeaters."
               ::= { experimental 64 }
               -- NOTE TO RFC EDITOR: When this document is published as
               -- an RFC, change '{ experimental 64 }' to '{ mib-2 XX }',
               -- where XX is assigned by IANA, and delete this comment.

2. Added NOTIFICATION-GROUP:

          vgRptrNotificationsGroup NOTIFICATION-GROUP
              NOTIFICATIONS {
                              vgRptrHealth,
                              vgRptrResetEvent
                            }
              STATUS        current
              DESCRIPTION
                      "A collection of notifications used to indicate
                      802.12 repeater general status changes."
              ::= { vgRptrGroups 4 }

3. Updated MODULE-COMPLIANCE:

          vgRptrCompliance MODULE-COMPLIANCE
              STATUS     current
              DESCRIPTION
                      "The compliance statement for managed 802.12
                      repeaters."

              MODULE  -- this module
                  MANDATORY-GROUPS { vgRptrConfigGroup,
                                     vgRptrNotificationsGroup }

                  GROUP  vgRptrStatsGroup
                  DESCRIPTION
                         "Implementation of this optional group is
                         recommended for systems which have the
                         instrumentation to do performance monitoring."

                  GROUP  vgRptrAddrGroup
                  DESCRIPTION
                         "Implementation of this optional group is
                         recommended for all systems which have the
                         necessary instrumentation to track the last
                         trained MAC address attached to a repeater
                         port."

              MODULE     SNMP-REPEATER-MIB
                  GROUP  snmpRptrGrpRptrAddrSearch
                  DESCRIPTION
                          "Implementation of this group is recommended
                          for systems which have the necessary
                          instrumentation to search all incoming data
                          streams for a particular source MAC address."
              ::= { vgRptrCompliances 1 }

          END


4. Updated references for 802.3 Repeater MIB and Patent Grant document:

   [7] de Graaf, K., D. Romascanu, D. McMaster, and K. McCloghrie,
       "Definitions of Managed Objects for IEEE 802.3 Repeater
       Devices", RFC 2108, 3Com Corporation, Madge Networks (Israel)
       Ltd., Cisco Systems, Inc., February, 1997.

   [8] McAnally, G., Gilbert, D., and J. Flick, "Conditional Grant of
       Rights to Specific Hewlett-Packard Patents In Conjunction With
       the Internet Engineering Task Force's Internet-Standard
       Network Management Framework", RFC 1988, August 1996.


5. Expanded Security Considerations:

    7.  Security Considerations

       Certain management information defined in this MIB may be considered
       sensitive in some network environments.  Therefore, authentication of
       received SNMP requests and controlled access to management
       information should be employed in such environments.  The method for
       this authentication is a function of the SNMP Administrative
       Framework, and has not been expanded by this MIB.

       Several objects in the vgRptrConfigGroup allow write access.  Setting
       these objects can have a serious effect on the operation of the
       network, including modifying the framing type of the network,
       resetting the repeater, enabling and disabling individual ports, and
       modifying the allowed capabilities of end stations attached to each
       port.  It is recommended that implementers seriously consider whether
       set operations should be allowed without providing, at a minimum,
       authentication of request origin.

       One particular object in this MIB, vgRptrPortAllowedTrainType, is
       considered significant for providing operational security in an
       802.12 network.  It is recommended that network administrators
       configure this object to the 'allowEndNodesOnly' value on all ports
       except ports which the administrator knows are attached to cascaded
       repeaters or devices which require promiscuous receive capability
       (bridges, switches, RMON probes, etc.).  This will prevent
       unauthorized users from extending the network (by attaching cascaded
       repeaters or bridges) without the administrator's knowledge, and will
       prevent unauthorized end nodes from listening promiscuously to
       network traffic.