802.12 Rptr MIB Draft-- issues

[Karen Kimball <[e-mail]>]

Hi folks,

	Some suggested changes/comments regarding draft 2 of the proposed
IEEE 802.12 Repeater MIB.

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."   

	As currently stated, the text seems to imply that repeaters and 
switches are the _only_ possible master mode devices, which is not true.


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."     
			^^^^^^^^^^^^^^^^^^^^^^^^
	This phrasing is more in keeping with the description of when the
C-bit is set to 0, and correctly notes that configuration failure may be
due to incompatibility with the network (as in framing type mismatch), the
port (as in, repeater training requested but not permitted), or both.

	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.


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"?


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?


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.


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.' 

	While it is very likely that ReadableOctets will increment rapidly on 
an 802.12 network, UnreadableOctets may not. Furthermore, one or both of 
HighPriorityOctets or NormalPriorityOctets may increment rapidly on a given 
802.12 network, but it is not guaranteed to always be both.


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".


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.

	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"?


~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
*   Karen Kimball                          * 
*   Hewlett Packard                        *
*   HP Workgroup Networks Division         *
*   Email: [e-mail]     *
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~