Subject: RE: [Bridge-mib] Future directions

From: "Harrington, David" <[email-masked]>
Date: Thu, 1 Apr 2004 08:33:54 -0500

Hi Juergen,

Open availability is a concern. IEEE 802.1 has agreed that the mib
modules should be published as text that is freely available. The
details aren't completely worked out yet (i.e. I haven't seen it
actually put into play yet).

I believe the plan is to publish the mib portion in ascii text and make
it readily available. The standard of which it is part would still be a
PDF that, under the existing "Get IEEE802" program, would be freely
available six months after standardization/publication. See
http://standards.ieee.org/getieee802/ for more information.

The plan is pretty consistent with the existing environment, where the
IEEE creates and publishes a standard under IEEE publishing/availability
rules, and then the IETF Bridgemib WG writes and publishes a MIB module
to manage that technology, following IETF publishing/availability rules.

The one major difference is that IEEE 802.1 will not make the
specifications of the technology or mibs openly available for **public**
review during development, which is the IEEE way; the mib documents
would typically not be freely and publicly available until six months
after they were approved by the IEEE. However, 802.1 is willing to allow
IETF WGs controlled access (via WG chairs and MIB Doctors) to the mibs
and the technology specification during development for purpose of
review. To be clear, I believe the agreement is that an approved person,
such as a WG chair, will be given password access to the IEEE document
and can post it to an IETF WG public mailing list for review, but cannot
divulge the password; this is consistent with the way the bridgemib and
hubmib WGs have been working with IEEE. There are obviously some gaping
holes in the approach, but we're trying to allow two very different
publication/availability systems to work together.

So I believe the IEEE will "provide simple open and stable access to the
MIBs they produce." It may be desirable to keep the bridgemib WG alive,
but dormant, to allow a forum for IETF review of 802.1 mib modules.

dbh

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Juergen Schoenwaelder
> Sent: Wednesday, March 31, 2004 4:49 PM
> To: Harrington, David
> Cc: [email-masked]
> Subject: Re: [Bridge-mib] Future directions
> 
> On Wed, Mar 31, 2004 at 03:20:46PM -0500, Harrington, David wrote:
>  
> > 4) Should they also be published as RFCs? 
> 
> It is important for me that the specifications and the MIB 
> modules are 
> easily accessible. RFCs have proven to be really great in this aspect.
> So from my view, it really boils down to the question whether IEEE is
> able to provide simple open and stable acess to the MIBs they produce.
> 
> /js
> 
> -- 
> Juergen Schoenwaelder		    International University Bremen
> <http://www.eecs.iu-bremen.de/>	    P.O. Box 750 561, 
> 28725 Bremen, Germany
> 
> _______________________________________________
> Bridge-mib mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/bridge-mib
> 
> 

_______________________________________________
Bridge-mib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/bridge-mib

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Fri, 2 Apr 2004 17:51:54 +0200

My 2 agorot (~ 0.8 cents) in-text.

Regards,

Dan

> [mailto:[email-masked]]On Behalf Of Harrington, David
> Sent: 31 March, 2004 10:21 PM
> To: [email-masked]
> Subject: [Bridge-mib] Future directions
> 
> 
> Hi,
> 
> The bridgemib work has stalled, and we're working to un-stall it.
> 
> We have been in discussions with IEEE 802.1, and they are willing to
> write their own mibs because this will help them produce mibs
> contemporaneously with the managed functionality. I will be providing
> MIB Doctor reviews for them during the transition, and possibly after
> the transition. IEEE 802.1 plans to publish mibs as part of their
> standard in their normal PDF format, and also make the mibs 
> available in
> text format for import into mib compilers and applications.
> 
> I have been working with Bert, and our current expectation is that the
> Bridgemib WG will finalize the existing bridgemib WG 
> documents, and then
> presumably close down. I am working to get the four remaining 
> documents
> finalized and into WG last call.
> 
> Bert raised a good point; we should ask what the implementers and
> deployers of the mibs would like as a future direction. So let me
> stimulate some discussion, so the powers-that-be in IETF and IEEE have
> some guidance:
> 
> 1) Do you agree with having the IEEE write their own mibs?

yes

> 2) Will you participate in the IEEE 802.1 process for 
> developing the mib
> modules?

yes

> 3) Do you agree the bridgemib WG should be closed down, since it will
> have completed its charter?
> 
yes

> For future mibs produced by IEEE:
> If they are published as RFCs, this would probably be as Informational
> only. The IEEE standard would be the official version, and to 
> the degree
> we could achieve it, the IETF might publish a mirror copy. 

yes, if the IEEE 802.1 WG wishes it so.

> 5) Synchronization between IEEE/IETF review/publishing cycles 
> has proven
> difficult, so we are considering publishing Informational 
> RFCs with only
> a pointer to the IEEE standard. Would that suffice?
> 

yes. If this was a problem for a large base of customers or users of these MIBs, we would have seen a more consistent participation in the Bridge MIB WG.

> For existing 802.1-related MIBs (1493, 1525, 2674, et al):
> 6) Should these be moved to the IEEE?

yes, if the IEEE 802.1 WG wishes so.

> 7) If not, why not? How should the IETF mib modules be 
> maintained as the
> IEEE 802.1 technologies change?

No, because this becomes an IEEE problem. The last years experience shows that there is no longer enough interest in the IETF to sustain IEEE 802.1 MIBs development and maintenance.

> 8) If yes, what should we do with the existing standards? Would making
> them Historic and replacing them with Informational RFCs that point to
> the IEEE standards documents suffice?

One Informational RFC defining this process, and pointing to the IEEE standards documents would be welcome.

> 
> David Harrington            
> [email-masked]
> Director, Network Management Architecture
> Office of the CTO, Enterasys Networks
> 
>