Re: [MIB-DOCTORS] FW: [802.1 - 4828] 802.1ap has beenapproved...

Hi,
 
I think the community needs lots more information to make such a
decision. The SNMP community should look at the new module(s) before
deciding the old one(s) should be declared Historic. Personally, I do
not think it is warranted. My reasons are discussed below.
 
-- getting access to the new MIB modules --
 
From the 802.1ap web page, the link requires a password. Can you post
the MIB modules to the MIB Doctor and OPS-area lists? It should
probably also be copied to the MIBs list, since many MIB implementers
might follow that rather than the whole ops-area list.
 
It appears the latest MIB link is for Draft 4.3, but are there still
outstanding comments to be resolved for Draft 4.3? i.e., is the ZIP
file with the MIB modules fully up-to-date?
 
Can the MIB modules be made available to the IETF SNMP community
without a password? I suggest posting the ZIP file on the OPS area web
site for a while, or posting a link to the publicly accessible MIB
modules on the mibs mailing list.
 
Since the IEEE MIB modules do not contain much information about the
changes to bridging, and this does affect IETF MIB modules, it would
be nice if 802.1 permitted freely available access to the entire
updated 802.1 specification so the SNMP community can better
understand the changes to the MIB modules.
 
-- RFC4663, "Transferring MIB Work from IETF Bridge MIB WG to IEEE
802.1 WG" --

This document was written to establish some clear expectations between
IETF and IEEE about the transition of Bridge MIB WG MIB modules to the
IEEE 802.1 WG. The plan was reviewed by the IESG, IAB, IETF, and IEEE.
This document states:
 
" For backwards compatibility, the existing IETF documents will still
be valid and remain unchanged.

   If an 802.1 WG document must update or obsolete the IETF version of
a
   Bridge MIB document, the 802.1 WG can create and submit an
internet-
   draft to the IESG to be published as an RFC that points to the
openly
   available IEEE copy and the IEEE standard.  The IESG would need to
   approve the publication of the RFC.  The RFC status would be
   reflected in the RFC-INDEX and also in the database, so it will be
   reflected on the RFC-Editor web page.  Thus, we don't have a
problem
   with synchronization between the copies being published. "
 
If we do want to obsolete (or deprecate) the IETF MIB modules, then
the IEEE should develop an internet-draft and have the IESG approve
it.
 
-- Coexistence of the MIB modules --
 
The IEEE ZIP file contains a number of new MIB files:
IEEE8021-BRIDGE-MIB.mib
IEEE8021-CFM-MIB.mib
IEEE8021-CFM-V2-MIB.mib
IEEE8021-MSTP-MIB.mib
IEEE8021-PBB-MIB.mib
IEEE8021-PB-MIB.mib
IEEE8021-Q-BRIDGE-MIB.mib
IEEE8021-SPANNING-TREE-MIB.mib
IEEE8021-TC-MIB.mib
 
The IETF and IEEE 802 have separate registration branches (arcs) in
the Object Identifier (OID) tree.  The IETF BRIDGE MIB family of
modules are registered under the IETF branch, and assignments are
maintained by IANA.  The IEEE BRIDGE MIB family of modules are
registered under the ieee802dot1mibs branch, and assignments are
maintained by IEEE 802.
 
For example, the IEEE8021-BRIDGE-MIB is registered at {
ieee802dot1mibs 2 }, while the IETF BRIDGE-MIB is registered at {
mib-2 17 }. So one does not really replace the other; they parallel
each other to support different environments, and should be able to
co-exist.
 
The BRIDGE-MIB family has been around a long time, and is applicable
to probably 99+% of the bridging devices available today. I question
whether existing NMSs and all the legacy bridging devices are unlikely
to migrate quickly to the new MIB module and its new OID registration,
even if we call it Historic. 
 
As discussed in RFC4663, we need a balance between disruption to
existing implementations and efficiency in making changes.  Keeping
the existing trees in their place minimizes disruption to existing
implementations. That is why IETF and IEEE agreed that "For backwards
compatibility, the existing IETF documents will still be valid and
remain unchanged."  I question whether they "remain unchanged" if we
declare them Historic.

I think most existing devices will not require migrating to the new
MIB modules. Did the IEEE make sure that the new bridging standards
were backwards compatible and/or could co-exist with the old bridging
standards? If so, I am not sure we need to take any action for the
IETF MIB modules. 
 
When device vendors decide they want to support the new bridging
standards, then they can update their MIB module support as
appropriate. They will do this when their business needs require it.
There is a lot of new fucntionality in the updated 802.1 and
associated MIB modules. I doubt we will need to declare MIB modules
Historic to make this migration happen.

-- Updating or Obsoleting the IETF MIB modules --
 
Per RFC4663, 
"If an 802.1 WG document must update or obsolete the IETF version of a
   Bridge MIB document, the 802.1 WG can create and submit an
internet-
   draft to the IESG to be published as an RFC that points to the
openly
   available IEEE copy and the IEEE standard.  The IESG would need to
   approve the publication of the RFC.  The RFC status would be
   reflected in the RFC-INDEX and also in the database, so it will be
   reflected on the RFC-Editor web page.  Thus, we don't have a
problem
   with synchronization between the copies being published. "
 
If the old bridging technology can coexist in the same network with
the new bridging technology, and we already know that the old MIB
modules can coexist with the new MIB modules, then I do not see a
strong justification for obsoleting the IETF MIB modules.
 
There was IEEE discussion of writing the 802.1ap section 5 conformance
clauses to allow choosing either RFC4363 or the .1ap MIB for
enterprise or legacy systems. Did 802.1 adopt this approach?
 
-- Educating the IETF SNMP community about the changes --
 
I have not read the new 802.1 standard, and the MIB modules do not
contain explanatory text. If we permit coexistence of the IETF ad IEEE
MIB modules, then it would probably be very useful to have a document
that explains the changes to the MIB and why they exist. 
 
The IEEE made massive changes to 802.1 bridging to accommodate
provider bridging and multiple spanning trees and service instances.
It would be really helpful to have a tutorial session to expalin the
changes to the IETF (SNMP) community, and then to have the tutorial
presentations available in the proceedings. Maybe we can get David
Levi to come do a tutorial, since he worked on both IETF and IEEE MIB
modules (and already has presentations developed for IEEE.
 
I recommend the OPS area web page also have a link to such a
presentation.
 
David Harrington
[email protected]
[email protected]
[email protected]


  _____  

From: [email protected] [mailto:[email protected]] On
Behalf Of Romascanu, Dan (Dan)
Sent: Tuesday, December 09, 2008 12:12 PM
To: Bert Wijnen (IETF); MIB Doctors (E-mail); ops-area (IETF)
Subject: Re: [OPS-AREA] [MIB-DOCTORS] FW: [802.1 - 4828] 802.1ap has
beenapproved...


Yes, I wanted first to get feedback on this lists before approaching
the IEEE. Does anybody think that this is not a good idea or that it's
a waste of time?
 
Thanks for volunteering to do it (when we decide). 
 
Dan
 


  _____  

From: Bert Wijnen (IETF) [mailto:[email protected]] 
Sent: Tuesday, December 09, 2008 7:03 PM
To: Romascanu, Dan (Dan); MIB Doctors (E-mail); ops-area (IETF)
Subject: Re: [MIB-DOCTORS] FW: [802.1 - 4828] 802.1ap has been
approved...


Makes sense to me. We probably need to write a one or two page (plus x
boilerplate) RFC 
for that, or so I suspect? I can do an I-D if you want. Maybe we
should make sure we keep
802.1 in the loop on that, no?
 
Bert

----- Original Message ----- 
From: Romascanu,  <mailto:[email protected]> Dan (Dan) 
To: MIB Doctors (E-mail) <mailto:[email protected]>  ; ops-area
<mailto:[email protected]> (IETF) 
Sent: Tuesday, December 09, 2008 5:57 PM
Subject: [MIB-DOCTORS] FW: [802.1 - 4828] 802.1ap has been approved...

This new IEEE 802.1 standard includes the MIB modules that replace the
Bridge MIB. 

The question is whether we should consider making RFC 4188 and RFC
4363
Historic. 

Dan


-----Original Message-----
From: IEEE 802.1 list HELP only [mailto:[email protected]] On
Behalf Of Tony Jeffree
Sent: Tuesday, December 09, 2008 6:21 PM

....

I have just heard that 802.1ap was approved as a standard.
Congratulations and thanks to all that contributed to the success of
this project!

Regards,
Tony
_______________________________________________
MIB-DOCTORS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mib-doctors

_______________________________________________
OPS-AREA mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ops-area