gmane.ietf.hubmib

Fwd: [OPSAWG] Fwd: I-D Action:draft-ietf-opsawg-rfc5066bis-00.txt

Benoit Claise — 2013-01-02T13:45:27

Dear all,

Forwarded to this mailer, just in case...
All discussions regarding this draft should take place in OPSAWG: 
"opsawg< at >ietf.org" <opsawg< at >ietf.org>

Regards, Benoit


-------- Original Message --------
Subject: [OPSAWG] Fwd: I-D Action: draft-ietf-opsawg-rfc5066bis-00.txt
Date: Wed, 02 Jan 2013 14:37:27 +0100
From: Benoit Claise <bclaise< at >cisco.com>
To: opsawg< at >ietf.org <opsawg< at >ietf.org>
CC: Edward Beili <EdwardB< at >actelis.com>, Howard Frazier 
<hfrazier< at >broadcom.com>



Dear all,

Here is some background information on this document, mainly taken from 
the IETF-IEEE coordination call meeting minutes 
(http://www.ietf.org/iesg/ieee/20121029/coordination.txt).

7. IETF Ethernet MIB, ADSL MIB and IEEE 802.3
7.1. Description
In the transition process between the IETF and the IEEE the following
documents were taken over by IEEE 802.3:
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

Re: testing if the list is still alive

Edward Beili — 2012-09-09T05:26:17

I see it.

Regards,
-E.


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





_______________________________________________
Hubmib mailing list
Hubmib< at >ietf.org<mailto: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

Re: [OPS-AREA] IEEE/IETF relationship on Ethernet-specificMIB Modules (was DISCUSS on draft-ietf-adslmib-gbond-eth-mib-07.txt)

Romascanu, Dan (Dan — 2012-07-29T05:58:54

Hi David,

Of course existing management applications will not interoperate as-is
and will need to be changed in order to work with the new IEEE 802.3 MIB
modules. Did anybody claim differently? 

Dan



MIB
original
other
changed,
for
Maybe
OIDs
but
or
versions
(and
modules
On
draft-ietf-adslmib-gbond-eth-mib-07.txt)
clear.
draft-ietf-adslmib-gbond-eth-mib-07.txt)
technical
which
modules.
OIDs
merely
original
the
IEEE
their
typically
1.3.6.1
I
to
This
RFC
refers
functionality
module,
the
(IEEE
to
(OAM)
corresponding
should
would

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

Benoit Claise — 2012-07-27T23:13:18

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 
<http://tools.ietf.org/html/rfc5066>.

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

Regarding a doubt an EFMOAM

deepa ramar — 2011-11-22T11:11:21

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

Re: [MIB-DOCTORS] Questions on IEEE published mib modulesvs IETF

Michael MacFaden — 2011-08-17T17:16:04

On Wed, Aug 17, 2011 at 8:36 AM, Romascanu, Dan (Dan)
<dromasca< at >avaya.com> wrote:

Ok, that's good to know. Unfortunately there is no README.txt file at this URL
  http://www.ieee802.org/1/files/public/MIBs
to describe when files are posted here at what part of the standards
process this is/such as being up for reaffirmation. Am
going to the pdf's just to make sure.


Makes sense to me, have already started using IEEE8021-BRIDGE-MIB,
IEEE8021-Q-BRIDGE, and others in products so would
prefer new to use correct IEEE versions when they become available.

Thanks again,
Mike MacFaden

Re: Questions on IEEE published mib modules vs IETF

Romascanu, Dan (Dan — 2011-08-17T15:36:54

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 Informationa

Re: FW: [802.3.1_MIBS] FW: 802.3.1-2011ApprovalNotification

David Harrington — 2011-07-19T22:08:53

Hi,

My question is:
Is there a separate community (e.g., enterprise vs service providers)
for whom the IETF MIB modules make sense, and for whom updating to the
IEEE MIB modules is not warranted? If so, you might want to keep the
IETF standard separate from the IEEE standard (but not progress the
IETF standard).

dbh



or
that
to
discriminators.

http://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html) 
Std
Management
[mailto:k.evangelista< at >ieee.org]
Publishing
be

Re: FW: [802.3.1_MIBS] FW: 802.3.1-2011ApprovalNotification

Romascanu, Dan (Dan — 2011-07-20T03:16:15


Hi Mike, 

Adequate notice seems fine to me.

Enjoy your time away from e-mail. 

Thanks and Regards,

Dan 

I-D,
effort)
it
the
802.3.1-2011
in
this.
A
Board

Re: FW: [802.3.1_MIBS] FW: 802.3.1-2011ApprovalNotification

C. M. Heard — 2011-07-20T03:14:14

Dan,

Sorry, my bad -- I did not mean to suggest anything heavyweight, 
certainly not publishing an RFC, just giving adequte notice to 
interested parties of the intended action.  Something less official 
than a last call put to the relevant lists would be quite 
sufficient.

Thanks and regards,

Mike

P.S.  I'll be out of e-mail contact for approximately the next 10 
days; I'll try to be prompt about attending to anything in the queue 
when I return.

On Wed, 20 Jul 2011, Romascanu, Dan (Dan) wrote:

Re: FW: [802.3.1_MIBS] FW: 802.3.1-2011ApprovalNotification

Romascanu, Dan (Dan — 2011-07-20T02:54:26


Hi Mike, 

Hmmmm ... 'a widely announced IETF last call' implies writing an I-D,
and probably making it an RFC. What would be last-calling? Do you think
that we need an official last-call? I thought that for modifying the
meta-data information for the RFCs an IESG decision would be enough.
Wound a less official question asked on the lists beyond be sufficient?
Frankly, if we go all the way and we write an I-D and make it an RFC (we
also need a volunteer for this) I would rather go all the way and make
the RFCs Historic. 

I spoke with Howard Frazier (who is chairing the IEEE 802.3.1 effort)
today. As expected he agrees with the proposal. The second phase of the
MIB revision in IEEE 802.3 is already chartered and with the exception
of the repeater and copper EFM MIB modules all the other MIB modules
will go through changes. 

Thanks and Regards,

Dan 
one-slide
in
be
providers.
of
these
RFC
4878,
Task
a
for

Re: FW: [802.3.1_MIBS] FW: 802.3.1-2011ApprovalNotification

C. M. Heard — 2011-07-20T01:08:39

Dan,

Waiting until after the IETF meeting to run the proposal past the 
IESG sounds quite reasonable.

If the IESG is open to the proposal, it seems to me that a 
widely-announced IETF last-call should suffice.  My suggestion would 
be to cc: the last call announcement to the hubmib, ietfmibs, 
ops-area, and (possibly) opsawg lists (besides of course 
ietf-announce, where all such things appear).

Thanks

Mike

On Tue, 19 Jul 2011, Romascanu, Dan (Dan) wrote:

Re: FW: [802.3.1_MIBS] FW: 802.3.1-2011ApprovalNotification

Romascanu, Dan (Dan — 2011-07-19T22:30:49


Hi, 

I think that the situation with the Ethernet MIB modules is somehow
different from the one with the Bridge modules on this respect. The
Ethernet MIB modules laready covered some of the SP space when Ethernet
started to propagate in the Metro and WAN applications. There is no
clear separation and what IEEE 802.3 continues the work in the IETF.
Actually the first set of MIB modules issued by IEEE 802.3.1 changes
little in the MIB modules structure beyond moving their root under IEEE
control and extending the range of supported PHYs and MAUs. 

I may not know all that is happening and I am ready to stand corrected
if I am missing information. As I am at the IEEE 802 meeting this week I
will try to learn more on the IEEE 802.3 side. 

Regards,

Dan 
(speaking as contributor)

Re: FW: [802.3.1_MIBS] FW: 802.3.1-2011ApprovalNotification

Romascanu, Dan (Dan — 2011-07-19T21:53:52


Hi Mike, 

I think that everybody who expressed opinions in this thread agreed with
your suggestion to mark the said RFCs as Obsoleted by IEEE 802.3.1 ...
We also seem to agree that if possible we would do it by an IESG
decision, avoiding the extra cost of writing an RFC. I am not sure yet
that the IESG will accept this proposal, and I hesitate to run it in the
busy week before the IETF meeting. 

Question - do we need to run this beyond the hubmib list? A one-slide
presentation in the OPSAREA meeting for example? 

Thanks and Regards,

Dan 
On
it
and
Notification
approved
notification.
new
of
on

Re: FW: [802.3.1_MIBS] FW: 802.3.1-2011ApprovalNotification

C. M. Heard — 2011-07-19T20:37:15

Greetings,

David Harrington and Glenn Parsons both provide good reasons why the 
status of the IETF Bridge MIB modules should remain unchanged.

My question, however, concerned the Ethernet-related MIB modules in 
RFCs 2108, 3621, 3635, 3637, 4836, 4837, 4878, and 5066.  The 
situation for those is different.  New versions (rooted under 
different OIDs) have been published in IEEE Std 802.3.1, and the 
overview section of that document says that it "supersedes and makes 
obsolete" those RFCs.

Mike Heard

On Tue, 19 Jul 2011, David Harrington wrote:

Re: FW: [802.3.1_MIBS] FW: 802.3.1-2011ApprovalNotification

David Harrington — 2011-07-19T04:51:24

Hi,

As I recall, when we did the transfer, it was agreed that the IETF
Bridge MIBs would continue to be standards (i.e. not be obsolete or
historic), and the defined compliance levels would continue to be
valid for those who wished to comply only to the IETF standards.

IEEE had an interest in extending the IETF MIB modules in ways that
were not backwards compatible, such as totally modifying indexes to
existing tables in order to support per-provider(?) discriminators.
IETF Bridge MIBs have been widlet deployed in enterprise environments,
and many of those environments had no desire to move to the
per-provider approach that was/is important to service providers.

Allowing the continuation of the IETF compliance as a valid option
addressed this difference in perspective.

I suppose one could draw a parallel with the RADIUS/Diameter split and
co-existence for different environments.

dbh

see
RFCs,
http://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html) 
2108,
meta-data
Force,
as
plan
Informati

Re: FW: [802.3.1_MIBS] FW: 802.3.1-2011ApprovalNotification

Romascanu, Dan (Dan — 2011-07-18T23:13:24


Hi Glenn, 

Thanks for reminding one important reason for not making the IETF Bridge
MIBs obsolete. 

There is no intention to change this, at least AFAIK. 

Regards,

Dan 
and
you

Re: FW: [802.3.1_MIBS] FW: 802.3.1-2011ApprovalNotification

Glenn Parsons — 2011-07-18T22:42:19

Dan,

We did not discuss this option for the 802.1 MIBs at the time, even though that was the general intent.  

The view was that if someone wanted to implement a simple bridge, they could use the IETF MIBs (in RFC 4188, 4318 & 4363).

As a result we imported some definitions from the IETF BRIDGE-MIB and Q-BRIDGE-MIB instead of redefining them.

Given this, is making the IETF Bridge MIBs obsolete appropriate?

For 802.3, I don't think there are any imports from the IETF MIBS, so this would be cleaner.

Cheers,
Glenn.

-----Original Message-----
From: hubmib-bounces< at >ietf.org [mailto:hubmib-bounces< at >ietf.org] On Behalf Of Romascanu, Dan (Dan)
Sent: July-18-11 4:39 PM
To: Bert Wijnen (IETF); C. M. Heard
Cc: Hubmib; David B Harrington
Subject: Re: [Hubmib] FW: [802.3.1_MIBS] FW: 802.3.1-2011ApprovalNotification



Hi Bert, 

I thought that we can avoid the writing of such an RFC for the transition of the Ethernet MIB documents to IEEE 802.3, as we already approved the transition process within the IESG, and the

Re: FW: [802.3.1_MIBS] FW: 802.3.1-2011ApprovalNotification

Bert Wijnen (IETF — 2011-07-18T20:44:26

If you can do it that way, then that would be fine with me.
It would be less work (supposedly).

Bert
----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <dromasca< at >avaya.com>
To: "Bert Wijnen (IETF)" <bertietf< at >bwijnen.net>; "C. M. Heard" <heard< at >pobox.com>
Cc: "Hubmib" <hubmib< at >ietf.org>; "David B Harrington" <ietfdbh< at >comcast.net>
Sent: Monday, July 18, 2011 10:38 PM
Subject: RE: [Hubmib] FW: [802.3.1_MIBS] FW: 802.3.1-2011ApprovalNotification

Hi Bert,

I thought that we can avoid the writing of such an RFC for the
transition of the Ethernet MIB documents to IEEE 802.3, as we already
approved the transition process within the IESG, and the IEEE 802.3 have
completed the first phase of the work. Would you or somebody else object
to having the IESG approve marking the IETF RFCs as 'obsolete' and
pointing to the IEEE 802.3 in the meta-data or you do believe that we
must have this information in an RFC and run this through a consensus
process which is broader than the IESG?

Thanks and Regards,

Dan

to

Re: FW: [802.3.1_MIBS] FW: 802.3.1-2011ApprovalNotification

Romascanu, Dan (Dan — 2011-07-18T20:38:53


Hi Bert, 

I thought that we can avoid the writing of such an RFC for the
transition of the Ethernet MIB documents to IEEE 802.3, as we already
approved the transition process within the IESG, and the IEEE 802.3 have
completed the first phase of the work. Would you or somebody else object
to having the IESG approve marking the IETF RFCs as 'obsolete' and
pointing to the IEEE 802.3 in the meta-data or you do believe that we
must have this information in an RFC and run this through a consensus
process which is broader than the IESG? 

Thanks and Regards,

Dan 

to
RFCs,
http://www.ietf.org/iesg/statement/designating-rfcs-as-historic.html)
meta-data
Force,
as
plan
Department.
approval

Re: FW: [802.3.1_MIBS] FW: 802.3.1-2011ApprovalNotification

Bert Wijnen (IETF — 2011-07-18T20:26:07

Well, my proposal then would be that we write a 1-2 page informational RFC that
explains that the new IEEE modules are the newer modules and should be used.
The new RFC that we write then obsoletes the IETF MIB RFCs. So they
do not become historic, but they get obsoleted bij an informational
(or BCP if that is better) RFC document that explains why and points to
the new current IEEE MIB modules.

Bert
----- Original Message ----- 
From: "Romascanu, Dan (Dan)" <dromasca< at >avaya.com>
To: "Bert (IETF) Wijnen" <bertietf< at >bwijnen.net>; "C. M. Heard" <heard< at >pobox.com>
Cc: "Hubmib" <hubmib< at >ietf.org>; "David B Harrington" <ietfdbh< at >comcast.net>
Sent: Monday, July 18, 2011 9:34 PM
Subject: Re: [Hubmib] FW: [802.3.1_MIBS] FW: 802.3.1-2011ApprovalNotification