Re: [Bridge-mib] 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@dsperkins.com>
To: Elisabeth Gloria <green_elisabeth@yahoo.com.au>; Harrington, David
<dbh@enterasys.com>; Bridge-mib@ietf.org <Bridge-mib@ietf.org>
Date: 02 April 2004 09:23
Subject: Re: [Bridge-mib] 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
>>> 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):
>>> 6) Should these be moved to the IEEE?
>>Not, it is not necessarily.
>>
>>> 7) If not, why not? How should the IETF mib modules
>>> be maintained as the
>>> IEEE 802.1 technologies change?
>>These MIBs should be made obsolete by new ones.
>>
>>Regards, Beth
>Regards,
>/david t. perkins
>
>_______________________________________________
>Bridge-mib mailing list
>Bridge-mib@ietf.org
>https://www1.ietf.org/mailman/listinfo/bridge-mib

_______________________________________________
Bridge-mib mailing list
Bridge-mib@ietf.org
https://www1.ietf.org/mailman/listinfo/bridge-mib