RE: Working Group Last Call

"Romascanu, Dan \(Dan\)" <[email protected]> Wed, 11 Jan 2006 04:00:14 +0200
Newsgroups gmane.ietf.hubmib
Message-ID <AAB4B3D3CF0F454F98272CBE187FDE2F09D86555@is0004avexu1.global.avaya.com>
Edward,
 
Please let me know if you will be submitting a revised rfc3636bis draft
soon. 
 
I would like to call for WG Last call with the EFMCu and rfc3636bis
I-Ds, but I want to make sure that you have done all needed updates
before. 
 
Thanks and Regards,
 
Dan
 
 
 
 


  _____  

	From: [email protected] [mailto:[email protected]]
On Behalf Of Edward Beili
	Sent: Wednesday, November 02, 2005 4:49 AM
	To: C. M. Heard; Hub MIB
	Subject: RE: [Hubmib] Working Group Last Call
	
	

	Mike,
	Apart from rpMauMediaAvailable, which is similar to
ifMauMediaAvailable
	there's nothing else that looks like another candidate for the
IANA-MAU-MIB module.
	
	While looking at ifMauMediaAvailable I realized that I forgot to
add two new values defined in the 802.3ah, clause 30.5.1.1.4:
	1. availableReduced - link normal, reduced bandwidth, applies
only to 2BASE-TL and 10PASS-TS
	2. ready - at least one PME available, applies only to 2BASE-TL
and 10PASS-TS
	
	In addition a clarification should be added to 'pmdLinkFault'
that all PMA/PMDs in the aggregation group must detect a fault.
	
	I will add these to the new revision of the 3636bis I-D.
	
	Regards,
	-Edward
	
	
	-----Original Message-----
	From:   C. M. Heard [mailto:[email protected]]
	Sent:   Mon 10/31/2005 11:52 PM
	To:     Hub MIB
	Cc:     Edward Beili
	Subject:        Re: [Hubmib] Working Group Last Call
	On Mon, 24 Oct 2005, Edward Beili wrote:
	> 1. Currently the values for the ifMauTypeListBits are defined
in the
	>    IANA-MAU-MIB, while the values for the
ifMauAutoNegCapabilityBits,
	>    ifMauAutoNegCapAdvertisedBits and
ifMauAutoNegCapReceivedBits objects
	>    are defined in MAU-MIB.
	>    While none of the newly added MAU types (10GBASE-CX4,
2BASE-TL,
	>    10PASS-TS, 100BASE-LX/BX, 1000BASE-LX/BX/PX) supports
	>    auto-negotiation, this may change in the future (e.g. I
don't see
	>    a reason not to support it on P2P (-LX/BX) optical links as
well as
	>    for some new types). I suggest to put TC for these objects
in the
	>    IANA-MAU-MIB as well.
	
	On Sun, 30 Oct 2005, C. M. Heard wrote:
	> If there is a realistic possibility that future MAU types will
	> support auto-negotiation, then it is probably advantageous to
	> put the capability list under IANA maintenance so that it
(like
	> the MAU types) can be expanded quickly upon approval of a new
	> 802.3 standard.  The main counter-argument would be that doing
	> this would lengthen an already protracted process.  In making
a
	> decision it might be useful to solicit input from the 802.3 WG
	> regarding the likelihood of the introduction of new
	> auto-negotiation capabilities.
	
	I just noticed that there is (at least) one more object in the
MAU-MIB
	that has MAU-type-specific values, and that is the enumerated
INTEGER
	object ifMauMediaAvailable.  Additional enumerated values for
this
	object may well be required for future MAU types, so there may
be
	reason to put its enumerations under IANA maintenance as well.
	
	Edward, are there any more such objects lurking in the MAU-MIB?
	
	Mike

_______________________________________________
Hubmib mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/hubmib