Re: 802.12 Rptr MIB Draft-- issues

[John Flick <[e-mail]>]

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

First, a slap on the wrist for waiting until last call to review a
draft that has been available for 4 months.  Last call is supposed to
be for catching serious bugs, not nitpicking over minor wording changes.
We need to decide whether any of these comments are serious enough to
cause us to rev the draft yet again.  Keep in mind that the Area
Directorate will also be reviewing this draft and will almost
certainly have some comments, so minor tweaks could be batched in
with changes requested by the Directorate.  This would avoid further
delays.  This draft has been out for four months with no comments,
and we are 15 months late according in our charter.

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

See above.

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

Actually, I think it said "port" back in draft 00, and I changed it to
"network" as a result of YOUR comments on that draft last December :-).
I guess I don't really care how we word this, I just want to stop spinning
on minor wording tweaks.

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

See above.

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

The term "standards-track" is correct here.  The IETF 802.3 Repeater
MIB has not reached Full Standard status, so we can't really refer to
it as a standard.

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

Notice below that where it says "Tranceiver MIB issue".  RFC 2020
says the same thing.  We decided ages ago (October 1995) to remove the
media type from both the repeater and interface MIBs to go into a
Tranceiver MIB document, which would be analogous to the 802.3 MAU MIB.
We decided to hold off on actually doing that document until the IEEE 802.12
redundant links specification was stable.

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

Actually, the first paragraph of that description is correct.  Group
addressed frames received on promiscuous or cascaded ports are never
buffered, regardless of the value of this object.  However, they are
either buffered to all ports or no ports.  (It doesn't repeat out
different ports at different times).  I suppose that the second
paragraph could be made clearer by changing:

    "since promiscuous and cascaded ports automatically avoid the
    store and forward."

to:
    "since packets received from promiscuous and cascaded ports
    automatically avoid the store and forward."

However, the first paragraph is already pretty exlicit about this.

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

This wording was stolen from the 802.3 Repeater MIB draft.  "can" is
probably more correct.  However, see earlier comments about minor
wording tweaks.

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

See earlier comment about minor wording tweaks.

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

Fairly low level detail.  Do we really need to make this explicit in
this MIB?

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

I'm not sure I like the new names any better.  "Looks like a stutter"
doesn't seem like enough cause to make a change if the name makes
sense and its meaining is clear.  There are plenty of objects in other
modules that have names that "look like a stutter".

I may sound like I am being overly resistent to making changes, but
we should have been finished with this a long time ago.  I hate to
waste yet another update and review cycle for minor rewording.

John