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 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
The IF-CAP-STACK-MIB in RFC 5066 is generic and the IETF proposed to
continue to be maintained by the IETF in a separate new document
The IEEE 802.3 proposed to create an RFC that documents the issues
related to the transition of the Ethernet MIB work to IEEE 802.3 similar
to RFC 4663 which documents the transition of the Bridge MIB work to
IEEE 802.1
- The OPSAWG was rechartered in October 2012 to include the two relevant
documents

7.2. Relevant Documents
- IEEE 802.3.1 Draft
-http://datatracker.ietf.org/wg/opsawg/charter/  
- TBD OPSAWG I-Ds

7.3. Owners
- Benoit Claise, Dan Romascanu, Ed Beili (IETF), Howard Frazier (IEEE 802.3)

7.4. Action Items
- Dan Romascanu will enter the Sponsor Ballot pool and enter a comment
suggesting that the IEEE 802.3 take out the IEEE8023-IF-CAP-STACK-MIB
from their document and refer the IF-CAP-STACK-MIB instead.
- Ed Beili will write an I-D targeting standards track that obsoletes
RFC 5066 and extract IF-CAP-STACK-MIB from RFC5056, with wording
emphasizing the generic nature of this module
- Ed Beili will write an I-D targeting informational RFC, similar to RFC
4663, with:
a) Listing of all the RFCs obsoleted by the IEEE 802.3.1-2011
b) A table mapping the old IETF MIB names with the corresponding new
IEEE ones
c) Clarifications/rules on the IETF-IEEE interactions, mailing lists,
reviews
d) Clarifications on the intellectual property considerations
The first version will be posted by Ed. Then Dan Romascanu and Howard
Frazier will add IETF-IEEE interactions chapter.
- Howard Frazier to add a EDITOR'S NOTE in the current IEEE MIB
document, to explain the situation


Regards, Benoit
-------- Original Message --------
Subject: [OPSAWG] I-D Action: draft-ietf-opsawg-rfc5066bis-00.txt
Date: Wed, 02 Jan 2013 04:17:12 -0800
From: internet-drafts< at >ietf.org
To: i-d-announce< at >ietf.org
CC: opsawg< at >ietf.org



A New Internet-Draft is available from the on-line Internet-Drafts directories.
  This draft is a work item of the Operations and Management Area Working Group Working Group of the IETF.

Title           : Interface Stack Capability MIB
Author(s)       : Edward Beili
Filename        : draft-ietf-opsawg-rfc5066bis-00.txt
Pages           : 15
Date            : 2012-12-25

Abstract:
    This document defines Management Information Base (MIB) module for
    use with network management protocols in TCP/IP-based internets.
    This document defines a set of objects, 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.  This document obsoletes
    RFC 5066.  It amends that specification by moving the entire EFM-CU-
    MIB module along with the relevant descriptive text, to a separate
    document, maintained by the Institute of Electrical and Electronics
    Engineers (IEEE) 802.3.1 working group.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-opsawg-rfc5066bis

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-opsawg-rfc5066bis-00


Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
OPSAWG mailing list
OPSAWG< at >ietf.org
https://www.ietf.org/mailman/listinfo/opsawg






_______________________________________________
OPSAWG mailing list
OPSAWG< at >ietf.org
https://www.ietf.org/mailman/listinfo/opsawg

_______________________________________________
Hubmib mailing list
Hubmib< at >ietf.org
https://www.ietf.org/mailman/listinfo/hubmib

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

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 Informational RFC to document
this transition. 

I hope this helps. 

Regards,

Dan




one

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
Information
Department.
approval
to

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

_______________________________________________
Hubmib mailing list
Hubmib< at >ietf.org
https://www.ietf.org/mailman/listinfo/hubmib

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

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