Re: 802.12 Rptr MIB Draft-- issues

[Karen Kimball <[e-mail]>]

My notes, John's notes:

> From: John Flick <[e-mail]>
> >From: Karen Kimball <[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.

	Wrist slap deserved.


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

	I have never supported _just_ "network" or _just_ "port."

	BOTH words are required for the description to be correct. I have
always requested that both words be used. I still think it's important for
explaining how to _fix_ a failure to pass training.


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

	OK, I wasn't sure.


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

	If we don't intend to support this object AT ALL in this MIB, can 
the wording show that? Right now, it looks as if we're waiting for a shoe to
drop.


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

	The first paragraph still doesn't seem quite "correct" to me.

	The phrasing, 
		"frames received from ports on this group and destined 
		to go out multiple ports on this group will be buffered..."
	
		     could be interpreted as either Group-Addressed frames,
or any frame which happens to have multiple destinations on this repeater 
group. If the explicit single-address recipient of the frame resides in a 
repeater group which also contains a cascaded or promiscuous port, that frame 
certainly is destined to go out multiple ports on that group. However, it will 
not be buffered, because it is a unicast packet.

	It is not crucial, but the current wording seems ambiguous.


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

	The object is intended as an aid to help the user fix problems.
I think fully and correctly explaining the cause of the problem (rather
than just _a_ cause which might not be _the_ cause) is important for
that.

	I guess we could ask why we have descriptions of MIB fields anyway.
It seems as if helpfulness to network managers is our general intent, though.


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

	Is a full cycle required (Jeff? Kaj?)? 

	If others have no objections, could changes be incorporated and
approved at the IETF meeting itself? It seems that some standards processes
allow this and others don't. Is it an option here?

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