Edward Beili | 9 Sep 2012 07:26
Favicon

Re: testing if the list is still alive

I see it.

Regards,
-E.


On Sep 6, 2012, at 12:52, "Romascanu, Dan (Dan)" <dromasca <at> avaya.com> wrote:





_______________________________________________
Hubmib mailing list
Hubmib <at> ietf.org
https://www.ietf.org/mailman/listinfo/hubmib
_______________________________________________
Hubmib mailing list
Hubmib <at> ietf.org
https://www.ietf.org/mailman/listinfo/hubmib
Benoit Claise | 28 Jul 2012 01:13
Picon
Favicon

IEEE/IETF relationship on Ethernet-specific MIB Modules (was DISCUSS on draft-ietf-adslmib-gbond-eth-mib-07.txt)

Dear all,

While DISCUSSing draft-ietf-adslmib-gbond-eth-mib-06.txt with the IESG, an issue was brought up. Let me explain.

The IETF is no longer developing any Ethernet-related MIB modules and has transferred the responsibility of these development of MIB modules for Ethernet to the IEEE 802.3 WG. This process has already started a few years ago, when the HUBMIB WG was shut down. This process also covers the last RFC produced by the HUBMIG WG, RFC 5066 - Ethernet in the First Mile Copper (EFMCu) Interfaces MIB

This RFC5066 contains two MIB modules
1. the EFM-CU-MIB MIB module (Ethernet to the First Mile Copper), clearly Ethernet-specific
2. the IF-CAP-STACK MIB module is not Ethernet-specific, but generic
    For example, draft-ietf-adslmib-gbond-eth-mib-07.txt refers to this MIB module.

However, according to the agreement, it is within the IEEE competence to develop the IEEE8023-IF-CAP-STACK-MIB in 802.3.1 rather than refer RFC 5066.
The issue was raised that it didn't make sense to refer to the IEEE8023-IF-CAP-STACK-MIB when this cross-connect functionality is not used for Ethernet, and that the reference RFC5056 was actually preferred.

This week, we had an IEEE/IESG meeting where this issue was discussed between Dan Romascanu (as the IEEE liaison), Howard Frazier (802.3.1) and myself.
The following has been agreed upon: the EFM-CU-MIB MIB module should be maintained by IEEE, while the IF-CAP-STACK-MIB should be maintained by the IETF.
Practically, it means:
1. Obsoleting RFC 5066
2. Creating RFC 5066bis. Extracting IF-CAP-STACK-MIB from RFC5056, with some wording emphasizing the generic nature of this module, and clearly mentioning that the IEEE 802.3.1 is responsible for EFM-CU-MIB.
    Ed Beili agreed to take the lead on this document.
3. The next version of draft-ietf-adslmib-gbond-eth-mib will contain the following text
4.4 Relationship with the IEEE 802.3 MIB modules The IEEE 802.3 working group chartered a task force [IEEE802.3.1] which continues the development of standard MIB modules based on the initial work done in the IETF. Future projects resulting from the work of this Task Force may include and possibly extend the work done in the IETF, such as [RFC5066]. ------------- To Informative References add: [IEEE802.3.1] IEEE P802.3.1 Revision to IEEE Std 802.3.1-2011 (IEEE 802.3.1a) Ethernet MIBs Task Force, http://grouper.ieee.org/groups/802/3/1/index.html

Thanks to Howard Frazier. Edward Beili, Menachem Dodge, Dan Romascanu, and Moti Morgenstern for helping with this issue. This shows an inter-SDO success story IMHO.


A second document has also been discussed.
It would be a good idea to have an informational RFC, similar to RFC 4663 - Transferring MIB Work from IETF Bridge MIB WG to IEEE ..., with the following content.
1. Listing of all the RFCs obsoleted by the IEEE 802.3.1-2011

RFC 2108 – Ethernet Repeater Devices
RFC 3621 - Power Ethernet MIB
RFC 3635 - Ethernet-like Interface Types
RFC 3637 - Ethernet WAN Interface Sublayer
RFC 4836 - Ethernet Medium Attachment Units (MAUs)
RFC 4837 - Ethernet Passive Optical Networks (EPON)
RFC 4878 - Operations, Administration, and Maintenance (OAM) Functions on Ethernet-Like Interfaces
RFC 5066 - Ethernet in the First Mile Copper (EFMCu) Interfaces MIB

2. A table mapping the old IETF MIB names with the corresponding new IEEE ones
3. Clarifications/rules on the IETF-IEEE interactions, mailing lists, reviews
4. Clarifications on the intellectual property considerations

Next to Dan and Ed, Howard agrees to co-author this document. And that sends a strong positive signal.

There is one open issue though with this second document: should we send to historic all the MIB modules mentioned above? What would be the impact for the equipment vendors and NMS applications?
Dan Romascanu will present this issue at the OPS-AREA meeting.

Finally, regarding the future cooperation between the IEEE and IETF regarding the development of the 802.3.1-2011, Howard Frazier mentioned that any feedback could be sent directly to him, and that he would insert it into the ballot.


Regards, Benoit (OPS A.D.)




_______________________________________________
Hubmib mailing list
Hubmib <at> ietf.org
https://www.ietf.org/mailman/listinfo/hubmib
deepa ramar | 22 Nov 2011 12:11
Picon

Regarding a doubt an EFMOAM

Hi,

This is regarding a doubt w.r.t EFMOAM implementation in device.

Is Device needed more than one port to support OAM ?
In which scenario it is true ?

Because One port is enough to monitor the health of the link between customer end and service provider end.

Regards,
Dheepa P R

_______________________________________________
Hubmib mailing list
Hubmib <at> ietf.org
https://www.ietf.org/mailman/listinfo/hubmib
Romascanu, Dan (Dan | 17 Aug 2011 17:36
Favicon

Re: Questions on IEEE published mib modules vs IETF

Hi Mike, 

I am copying hubmib as the last question refers to Ethernet MIB
documents. 

There is no equivalent of the IETF maturity levels in the IEEE. There is
just one level of standards, and there is a re-affirmation process that
needs to happen every five years, unless the standard was updated
sooner. 

I do not know about the LAG MIB. I think - but I am not sure - that it
is being updated. Best place to ask is the IEEE 802.3 folks - Howard
Frazier(hfrazier <at> broadcom.com) is a good person to start from. Howard
chairs the IEEE 802.3.1 project which is taking over the Ethernet MIB
work in the IEEE 

The MIB modules defined in RFC 3635 and RFC 4836 (and a few more) are in
the scope of IEEE 802.3.1 which was approved as an IEEE standard a few
months ago. We entertained a discussion at and around the Quebec meeting
and decided to mark the RFCs as obsolete by the IEEE standards and point
to these, but not transit them to Historic (not yet in any case). Bert
will write when he gets some time a short Informational RFC to document
this transition. 

I hope this helps. 

Regards,

Dan

> -----Original Message-----
> From: macfaden <at> gmail.com [mailto:macfaden <at> gmail.com] On Behalf Of
> Michael MacFaden
> Sent: Tuesday, August 16, 2011 2:07 AM
> To: Romascanu, Dan (Dan)
> Cc: MIB Doctors (E-mail)
> Subject: Questions on IEEE published mib modules vs IETF
> 
> Hi Dan,
> 
> Can you or someone on this list explain what's the equivalent of the
> IETF maturity level for
> IEEE mib modules?  Specifically those found here:
> http://www.ieee802.org/1/files/public/MIBs
> 
> For example am looking at  IEEE8023-LAG-MIB which doesn't match the
one
> in this
> spec so am curious when it would be updated. The changes appear to be
> fixed REFERENCES only.
> http://standards.ieee.org/getieee802/download/802.1AX-2008.pdf
> 
> Lastly, are these IETF mib modules going to deprecated/moved to IEEE?
> EtherLike-MIB/3635 and MAU-MIB/4836.
> 
> Thanks
> Mike MacFaden
Romascanu, Dan (Dan | 22 May 2011 11:05
Favicon

FW: [802.3.1_MIBS] FW: 802.3.1-2011 Approval Notification


FYI. 

Regards,

Dan 

-----Original Message-----
From: Howard Frazier [mailto:hfrazier <at> BROADCOM.COM] 
Sent: Saturday, May 21, 2011 12:06 AM
To: STDS-802-3-MIB <at> LISTSERV.IEEE.ORG
Subject: [802.3.1_MIBS] FW: 802.3.1-2011 Approval Notification

Dear Members of the IEEE 802.3.1 Ethernet MIB modules Task Force,

The initial version of P802.3.1/D3.1 Standard for Management Information Base (MIB) definitions for
Ethernet has been approved as an IEEE standard. See below. Congratulations and thanks to all of you for
your work on this project.

A PAR for a revision of the standard is on the agenda for the June IEEE-SA Standards Board meeting.

We will hold a short meeting next Thursday afternoon in conjunction with the IEEE 802.3 interim meetings in
Incline Village, NV, to plan our work for the revision project.

Howard Frazier
Chair, IEEE 802.3.1 Ethernet MIB modules Task Force

-----Original Message-----
From: Law, David [mailto:dlaw <at> hp.com]
Sent: Friday, May 20, 2011 12:05 PM
To: Howard Frazier
Subject: FW: 802.3.1-2011 Approval Notification

Hi Howard,

On checking I found that I did have the approval notification. 

Congratulations!!

Best regards,
  David
_______________________________________

From: k.evangelista <at> ieee.org [mailto:k.evangelista <at> ieee.org]
Sent: 17 May 2011 14:28
To: Law, David
Cc: p.nikolich <at> ieee.org; K.Bennett <at> ieee.org; k.breitfelder <at> ieee.org; thompson <at> ieee.org
Subject: 802.3.1-2011 Approval Notification

17 May 2011 

David Law 
HP Ltd. 
20 Clayknowes Ave 
Musselburgh, East Lothian EH21 6UR 
Scotland 
 
cc:          Paul Nikolich, Sponsor Chair 
        Kathryn Bennett, Program Manager 
              Kim Breitfelder, Manager Standards Publishing 
        Thomas Geoffrey, Negative Balloter 

RE: NEW P802.3.1/D3.1 (C/LM) Standard for Management Information Base (MIB) definitions for Ethernet 
Dear David, 

I am pleased to inform you that P802.3.1 was approved as a new standard by the IEEE-SA Standards Board on 16
May 2011. A copy of the document will be forwarded to the Standards Publications Department. The editor
assigned to work on the project will contact you. 

All IEEE standards shall be updated within five years of approval by the IEEE-SA Standards Board. If the
standard is not revised, reaffirmed, or withdrawn within five years, the Sponsor will be notified that it
will be submitted to the Standards Board for administrative withdrawal.   

It should be noted that any negative balloters have the right to appeal. Please consult the following web
pages for information on this process: 
  
http://standards.ieee.org/develop/policies/bylaws/
  
http://standards.ieee.org/develop/policies/opman/

Please contact me if you have any questions prior to speaking with your editor.   

Sincerely, 
************************************************
Karen M. Evangelista
IEEE - SA Governance, Administrator
IEEE Standards Activities Department
445 Hoes Lane
Piscataway, NJ 08854-4141 USA
TEL: +1 732 562 3854
FAX: +1 732 796 6966
k.evangelista <at> ieee.org
*************************************************
_______________________________________________
Hubmib mailing list
Hubmib <at> ietf.org
https://www.ietf.org/mailman/listinfo/hubmib
Romascanu, Dan (Dan | 2 Mar 2011 18:35
Favicon

FW: Draft PAR for revision of P802.3.1

 If you are interested in participating in the further development of
the Ethernet MIBs my recommendation is to start participating in this
project (P802.3.1)

Regards,

Dan

-----Original Message-----
From: Howard Frazier [mailto:hfrazier <at> broadcom.com] 
Sent: Wednesday, March 02, 2011 6:45 PM
To: Romascanu, Dan (Dan)
Subject: FW: Draft PAR for revision of P802.3.1

Dan,

Here it is.

Howard

-----Original Message-----
From: Howard Frazier
Sent: Friday, February 25, 2011 4:25 PM
To: 'STDS-802-3-MIB <at> LISTSERV.IEEE.ORG'
Subject: Draft PAR for revision of P802.3.1

Dear Members of the IEEE 802.3.1 Ethernet MIB modules Task Force,

Attached please find a draft of a proposed PAR for a revision of IEEE
Std 802.3.1 Standard for Management Information Base (MIB) definitions
for Ethernet.

As we are nearing completion of the initial project, it is time to start
the process to initiate a revision to catch the document up so that it
is synchronized and consistent with IEEE Std 802.3 Standard for Ethernet
(love the new title). Please review the draft PAR, and let me know if
you have any comments. I plan to seek approval of this PAR at the
upcoming plenary session, and to have it placed on the June IEEE-SA
Standards Board meeting agenda. 
Since it is a "maintenance" PAR, it need not be circulated to the IEEE
802 EC 30 days in advance of the plenary, and we don't need to work up a
5 Criteria slide deck.

You will note that the scope and purpose statements have been reworded
slightly in order to address comments that came up during the initial
project. We no longer use the words "future"
and "recent", and the purpose has been reworded to make it clear that
only the SNMP modules will be published in machine readable form.

I have been asked why the PAR does not include a list of the specific
amendments to IEEE Std 802.3 that will be reflected in the revision of
IEEE Std 802.3.1. Let me first state that I fully intend to mirror the
set of amendments that are being incorporated into the currently
underway revision of IEEE Std 802.3, which means all approved amendments
through 802.3bg. I believe that this should be captured in the project
objectives, rather than the PAR, because I don't want to have to go
through the process of changing the PAR in the event that we later
decide to deviate from this plan.
This is how we did it for the initial project, and I think it should
work just fine for the revision. I will send out a draft set of project
objectives shortly.

I look forward to meeting with you in Singapore.

Howard Frazier
Broadcom Corporation
Chair, IEEE 802.3.1 Ethernet MIB modules Task Force
Attachment (P802.3.1REV_PAR_r1.pdf): application/pdf, 35 KiB
_______________________________________________
Hubmib mailing list
Hubmib <at> ietf.org
https://www.ietf.org/mailman/listinfo/hubmib
Romascanu, Dan (Dan | 2 Mar 2011 11:22
Favicon

FW: [802.3.1_MIBS] Plan and objectives for P802.3.1-Rev

This may be of interest for the hubmib enthusiasts who still on this
list. 

Regards,

Dan

-----Original Message-----
From: Howard Frazier [mailto:hfrazier <at> BROADCOM.COM] 
Sent: Wednesday, March 02, 2011 12:50 AM
To: STDS-802-3-MIB <at> LISTSERV.IEEE.ORG
Subject: [802.3.1_MIBS] Plan and objectives for P802.3.1-Rev

Dear Members of the IEEE 802.3.1 Ethernet MIB modules Task Force,

Attached please find a few slides that describe a proposed plan and a
set of objectives for a revision project on IEEE Std 802.3.1-2011.
I will present these slides in Singapore along with the proposed PAR
that I circulated last week.

Comments welcome.

Howard Frazier
Broadcom Corporation
Chair, IEEE 802.3.1 Ethernet MIB modules Task Force
Attachment (plan_objectives.pdf): application/pdf, 84 KiB
_______________________________________________
Hubmib mailing list
Hubmib <at> ietf.org
https://www.ietf.org/mailman/listinfo/hubmib
Olivier Seveur | 7 Feb 2011 17:02
Favicon

Correlation betwen two MIB


Hi,


I'm a SNMP administrator and i tried to found a link between two MIB: POWER ETHERNET MIB and IF-MIB.


I use pethPsePortTable  in the PEM  and ifTable in the IF-MIB


But i cannot found common index between them.


I found some link where ou explain some way to do it, but it not working


Can you give me some advice


I thanks you a lot

Regards



Seveur Olivier
01.44.95.41.26 ___________________________________ The integrity of this message cannot be guaranteed on the internet .Therefore EXANE cannot be considered responsible for the contents. If you are not the intended recipient of this message ,please delete it and notify the sender. This message is provided for information purposes only and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments Although it may contain some elements from publications produced by Exane's research department ,this message is not research. Please consult our web site for important disclaimers and disclosures concerning Exane's research (http://www.exane.com) ___________________________________
_______________________________________________
Hubmib mailing list
Hubmib <at> ietf.org
https://www.ietf.org/mailman/listinfo/hubmib
Baud, Yann | 18 Nov 2010 12:05
Picon

RFC 5066 Comment on PME initialization and aggregation

I wish to comment on the penultimate paragraph of RFC 5066 section 3.1.3:
 
*Quoted*
    Note that the PCS port does not have to be operationally 'down' for
    the connection to succeed.  In fact, a dynamic PME addition (and
    removal) MAY be implemented with an available PME being initialized
    first (by setting its ifAdminStatus to 'up') and then added to an
    operationally 'up' PCS port, by modifying a respective ifStackTable
    (and respective ifInvStackTable) entry.
 
In fact, PME addition to a PCS is impossible once the PME has been initialized, because
the discovery and aggregation phases, which are done using ITU-T G.994.1 (G.Hs), must occur before PME training and
activation in the PME initialization process. Once the PME is initialized, it is impossible
to configure the aggregation on the peer pme (IEEE 802.3 2008 61.4.7).
 
I would much welcome a clarification on this paragraph.
 
Best Regards,
Yann
_______________________________________________
Hubmib mailing list
Hubmib <at> ietf.org
https://www.ietf.org/mailman/listinfo/hubmib
Bert Wijnen (IETF | 15 Sep 2008 11:01

Possible 802.3 MIB work in IEEE 802.3

HUBMIB WG members and MIB doctors.

Well, we all know the HUBMIB WG is closed.
Nevertheless, I thik it is good for you all to be aware of this
activity in IEEE 802.3.

It looks like any new MIB work in this space may indeed be
taken up by IEEE 802.3, similar as the BRIDGE-MIB work
was picked up a few years back by the IEEE 802.1

Bert Wijnen
old (indeed) WG chair of the (closed) HUBMIB WG.

> ----- Original Message ----- 
> From: "Howard Frazier" <hfrazier <at> BROADCOM.COM>
> To: <STDS-802-3-MAINT <at> LISTSERV.IEEE.ORG>
> Sent: Monday, September 15, 2008 5:49 AM
> Subject: [802.3_MAINT] draft PAR and 5 Critters for P802.3.1
> 
> 
> 
> Dear IEEE 802.3 maintenance task force members,
> 
> attached please find draft text for a PAR and the 5 criteria
> responses for a new project, P802.3.1, to create a standard
> for Ethernet MIB modules.  I am circulating the draft text
> to this reflector for discussion at our meeting in Seoul.
> 
> Howard Frazier
> Broadcom Corporation
>
Attachment (MIB_project.ppt): application/vnd.ms-powerpoint, 28 KiB
Attachment (MIB_critters.ppt): application/vnd.ms-powerpoint, 172 KiB
_______________________________________________
Hubmib mailing list
Hubmib <at> ietf.org
https://www.ietf.org/mailman/listinfo/hubmib
Edward Beili | 21 Nov 2007 10:23
Favicon

RE: RFC 5066 on Ethernet in the First Mile Copper(EFMCu)Interfaces MIB

Bert,
Thanks for the guidance, comments and help you have provided during this long period.

I would also like to thank the hubmib group members, especially people mentioned in the Acknowledgments
section of the rfc, namely (in alphabetical order):
    Udi Ashkenazi (Actelis)
    Mike Heard
    Alfred Hoenes (TR-Sys)
    Marina Popilov (Actelis)
    Mathias Riess (Infineon)
    Dan Romascanu (Avaya)
    Matt Squire (Hatteras)
    Bert Wijnen (Alcatel)

I'm now working on the G.Bond MIBs in ADSLMIB group
(http://www.ietf.org/html.charters/adslmib-charter.html), providing management for the ITU-T
G.998.x series xDSL bonding protocols. So, if you were unaware of this work, hop onto the adslmib mailing list.

Regards,
-E.

> -----Original Message-----
> From: WIJNEN, Bert (Bert) [mailto:bwijnen <at> alcatel-lucent.com] 
> Sent: Wednesday, November 21, 2007 10:59
> To: hubmib <at> ietf.org
> Subject: FW: [Hubmib] RFC 5066 on Ethernet in the First Mile 
> Copper(EFMCu)Interfaces MIB
> 
> Congrats to the (now closed) WG for the final publication of 
> our work. Special thanks to Edward Beili for his careful and 
> meticulous work in the whole process and specifically in the 
> final stages of the process.
> 
> Bert Wijnen
> Chair of the IETF HUBMIB WG
> 
> -----Original Message-----
> From: rfc-editor <at> rfc-editor.org [mailto:rfc-editor <at> rfc-editor.org]
> Sent: Wednesday, November 21, 2007 1:44 AM
> To: ietf-announce <at> ietf.org; rfc-dist <at> rfc-editor.org
> Cc: hubmib <at> ietf.org; rfc-editor <at> rfc-editor.org
> Subject: [Hubmib] RFC 5066 on Ethernet in the First Mile 
> Copper (EFMCu)Interfaces MIB
> 
> 
> A new Request for Comments is now available in online RFC libraries.
> 
>         
>         RFC 5066
> 
>         Title:      Ethernet in the First Mile 
>                     Copper (EFMCu) Interfaces MIB 
>         Author:     E. Beili
>         Status:     Standards Track
>         Date:       November 2007
>         Mailbox:    edward.beili <at> actelis.com
>         Pages:      90
>         Characters: 193465
>         Updates/Obsoletes/SeeAlso:   None
> 
>         I-D Tag:    draft-ietf-hubmib-efm-cu-mib-08.txt
> 
>         URL:        http://www.rfc-editor.org/rfc/rfc5066.txt
> 
> This document defines Management Information Base (MIB) 
> modules for use
> with network management protocols in TCP/IP-based internets.
> This document describes extensions to the Ethernet-like Interfaces MIB
> and Medium Attachment Unit (MAU) MIB modules with a set of objects for
> managing Ethernet in the First Mile Copper (EFMCu) interfaces 
> 10PASS-TS
> and 2BASE-TL, defined in IEEE Std 802.3ah-2004
> (note: IEEE Std 802.3ah-2004 has been integrated into IEEE Std 802.3-
> 2005).  In addition, a set of objects is defined, describing cross-
> connect capability of a managed device with multi-layer (stacked)
> interfaces, extending the stack management objects in the Interfaces
> Group MIB and the Inverted Stack Table MIB modules.  [STANDARDS TRACK]
> 
> This document is a product of the Ethernet Interfaces and Hub MIB
> Working Group of the IETF.
> 
> This is now a Proposed Standard Protocol.
> 
> STANDARDS TRACK: This document specifies an Internet standards track
> protocol for the Internet community,and requests discussion and
> suggestions for improvements.Please refer to the current 
> edition of the
> Internet  Official Protocol Standards (STD 1) for the standardization
> state and  status of this protocol.  Distribution of this memo is
> unlimited.
> 
> This announcement is sent to the IETF list and the RFC-DIST list.
> Requests to be added to or deleted from the IETF distribution list
> should be sent to IETF-REQUEST <at> IETF.ORG.  Requests to be added to or
> deleted from the RFC-DIST distribution list should be sent to
> RFC-DIST-REQUEST <at> RFC-EDITOR.ORG.
> 
> Details on obtaining RFCs via FTP or EMAIL may be obtained by 
> sending an
> EMAIL message to rfc-info <at> RFC-EDITOR.ORG with the message body 
> 
> help: ways_to_get_rfcs. For example:
> 
>         To: rfc-info <at> RFC-EDITOR.ORG
>         Subject: getting rfcs
> 
>         help: ways_to_get_rfcs
> 
> Requests for special distribution should be addressed to either the
> author of the RFC in question, or to 
> RFC-Manager <at> RFC-EDITOR.ORG.  Unless
> specifically noted otherwise on the RFC itself, all RFCs are for
> unlimited distribution.
> 
> Submissions for Requests for Comments should be sent to
> RFC-EDITOR <at> RFC-EDITOR.ORG.  Please consult RFC 2223, 
> Instructions to RFC
> Authors, for further information.
> 
> 
> The RFC Editor Team
> USC/Information Sciences Institute
> 
> ...
> 
> 
> 
> 
> _______________________________________________
> Hubmib mailing list
> Hubmib <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/hubmib
> 
> 
> _______________________________________________
> Hubmib mailing list
> Hubmib <at> ietf.org
> https://www1.ietf.org/mailman/listinfo/hubmib
> 

Gmane