RE: [802.1] Re: MSTP (IEEE 802.1s) MIB (or draft) ?

Hi Alex,
I am glad to see you again inside the business :)
Do you remember, we discussed MSTP traps in
the MIB? Did you define them?
Could you send your last modification of the draft
to stds-802-1 <at> ieee.org, Bridge-mib <at> ietf.org or
rstplib-users <at> lists.sourceforge.net?

Respectfully yours, Thom

 --- Alex Rozin wrote: > 
> Hi,
> I am ready to participate in this activity as a
> volunteer.
> It seems that my edition of the draft is
> circulating.
> Any feedbacks or/and proposition are encouraged to
> come
> forward.
> 
> Regards, Alex
> 
> Dbh> Hi,
> Dbh> 
> Dbh> There has been inconsistency about whether the
> mib modules 
> Dbh> for new 802.1
> Dbh> functionality would be developed by 802.1 or by
> IETF's 
> Dbh> Bridgemib WG. We

Re: Future directions

David,

I my opinion (while I am not a member of WG):

> 1) Do you agree with having the IEEE write
> their own mibs?
Yes, I do.

> 2) Will you participate in the IEEE 802.1
> process for developing the mib modules?
Yes, I will as far as I can.

> 3) Do you agree the bridgemib WG should be
> closed down, since it will
> have completed its charter?
No, I wouldn't like, see next item. 

> 4) Should they also be published as RFCs?
Yes, they should.

> 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, it would.

> For existing 802.1-related MIBs (1493, 1525, 2674,
> et al):

Re: [802.1] Re: MSTP (IEEE 802.1s) MIB (or draft) ?

Alex,

You wrote:
> I may [send the MIB], but I am not sure, that
> [...] stds-802-1 <at> ieee.org & Bridge-mib <at> ietf.org
> will not consider it as a spam.
> I will send it you directly.

I must differ with your opinion on the
matter: IMO this is a most relevant place
to public this document.

Apropos, may I ask you regarding your MIB?
I see here (I mean an edition, that Thom sent me),
that there are a few objects, that are absent
in .1s, for example, port roles (dot1sXstPortRole)
and ports STP traffic counters
(like dot1sPortTxMstBpduCounter). Why do you want
to have these objects in the MIB?

Regards, Beth

Find local movie times and trailers on Yahoo! Movies.
http://au.movies.yahoo.com

RE: Future directions

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

Access to IEEE mibs

FYI.

IEEE 802.1 mibs are being made accessible at 

http://www.ieee802.org/1/files/public/MIBs/

David Harrington            
dbh <at> enterasys.com
Director, Network Management Architecture
Office of the CTO, Enterasys Networks

Re: Future directions

HI,

DBH - In general, the IETF and the IEEE 802.1 have different approaches
in what is included in technical specifications for management and the
process for standardizing a technical specification. Thus, I would
guess that the results from the two different groups would be quite
different for the same problem. Thus, I'm not convinced that hands
off by the IETF is the approach to take.

EG - it concerns me when seeing the statement "These MIBs should be
made obsolete by new ones." I'm not sure what you meant. If you meant
to "start over", then this is a non-starter. That is, any new technical
specification must include unmodified the existing definitions 
(where they are not technically incorrect), and add new definitions
and augmentations of existing definitions. The resulting technical
specification containing one of more MIB modules defining object
and notification types must allow interoperation between old managers
and new agents, and new managers and old agents.
What did you mean?

At 05:43 PM 4/1/2004 +1000, Elisabeth Gloria wrote:
>David,
>
>I my opinion (while I am not a member of WG):
>
>> 1) Do you agree with having the IEEE write
>> their own mibs?
>Yes, I do.
> 
>> 2) Will you participate in the IEEE 802.1

RE: [802.1] Re: MSTP (IEEE 802.1s) MIB (or draft) ?

Thom,

On Thursday, April 01, 2004 8:52 AM you wrote:
> Hi Alex,
> I am glad to see you again inside the business :)
Thanks.

> Do you remember, we discussed MSTP traps in
> the MIB? Did you define them?
> Could you send your last modification of the draft
> to stds-802-1 <at> ieee.org, Bridge-mib <at> ietf.org or
> rstplib-users <at> lists.sourceforge.net?
I may, but I am not sure, that
rstplib-users <at> lists.sourceforge.net is a good place
for it, and stds-802-1 <at> ieee.org & Bridge-mib <at> ietf.org
will not consider it as a spam.
I will send it you directly.

Regards, Alex

RE: [802.1] Re: MSTP (IEEE 802.1s) MIB (or draft) ?

Beth,

On Thursday, April 01 you wrote:
> IMO this [the MSTP MIB draft] is a most relevant place
> to public this document.
OK, I make you responsible for this :)
I attached here a last edition of the draft and a result of
its compilation with snmptranslate.

> Apropos, may I ask you regarding your MIB?
> I see here (I mean an edition, that Thom sent me),
> that there are a few objects, that are absent
> in .1s, for example, port roles (dot1sXstPortRole)
> and ports STP traffic counters
> (like dot1sPortTxMstBpduCounter). Why do you want
> to have these objects in the MIB?
Yes, the bitter experience of management large or/and
complicated networks shows, that managers would like
to know the reasons of established port states. It constrains
to insert the object dot1sXstPortRole.
Counters like dot1sPortTxMstBpduCounter carries out a similar
function, but more for a debugging.

With respect, Alex
 

MSTP-MIB DEFINITIONS ::= BEGIN
-- draft !

    IMPORTS

Re: Future directions

I see no problem in the IEEE producing their own MIB modules; many
organisations do it already, in fact, follow the path
iso(1).member-body(2).us(840).ieee802dot11(10036) and you will find the MIB
module for IEEE 802.11 entities.

I think that the MIB module should only appear in an RFC if the IEEE want
it rooted in .1.3.6.1.2.1 otherwise they can do as many other organisations
do and produce their own.

Since IEEE are the recognised experts in this technology, of bridges and
such-like, then I think it makes a lot of sense for them to control the MIB
module.  It is then harder, more expensive, for the likes of me to be
involved but that is the nature of the IEEE.

Of course the MIB module will be different, increasingly so over the years
eg in using character sets we do not, in its treatment of IPR, in setting
aside our conventions as laid out in draft-ietf-ops-mib-review-guidelines
and whatever else is produced by the IETF.  But that is the nature of
development and progress.  We should only oppose this if we, as the
originators of the 'MIB module' technology, have a strong reason for doing
so and I have not heard one yet.

Tom Petch

ps is this worth cross posting to the mibs list?

-----Original Message-----
From: David T. Perkins <dperkins <at> dsperkins.com>
To: Elisabeth Gloria <green_elisabeth <at> yahoo.com.au>; Harrington, David
<dbh <at> enterasys.com>; Bridge-mib <at> ietf.org <Bridge-mib <at> ietf.org>

RE: Future directions

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

Regards,

Dan

> -----Original Message-----
> From: bridge-mib-admin <at> ietf.org 
> [mailto:bridge-mib-admin <at> ietf.org]On Behalf Of Harrington, David
> Sent: 31 March, 2004 10:21 PM
> To: Bridge-mib <at> ietf.org
> 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