Subject: RE: [Hubmib] Working Group Last Call

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Wed, 11 Jan 2006 04:00:14 +0200

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-masked] [mailto:[email-masked]]
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-masked]]
	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-masked]
https://www1.ietf.org/mailman/listinfo/hubmib

---

From: "Edward Beili" <[email-masked]>
Date: Wed, 11 Jan 2006 09:27:44 +0200

Dan,
I have a few things to add to the efm-cu-mib, which I'm planning to do next week. I'll change the rfc363bis at the same time.

I'll try to do everything by Monday, Jan 23.

Regards,
-Edward

-----Original Message-----
From:	[email-masked] on behalf of Romascanu, Dan (Dan)
Sent:	Wed 1/11/2006 4:00 AM
To:	Edward Beili; C. M. Heard; Hub MIB
Cc:	
Subject:	RE: [Hubmib] Working Group Last Call

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-masked] [mailto:[email-masked]] 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.

Regards,
-Edward

-----Original Message-----
From:   C. M. Heard [mailto:[email-masked]]
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,
>    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:
> put the capability list under IANA maintenance so that it (like
> this would lengthen an already protracted process.  In making a

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.

Mike