SORT BY:

LIST ORDER
THREAD
AUTHOR
SUBJECT


SEARCH

IPS HOME


    [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

    Re: IPS-ALL: FC Mgmt MIB WG Last Call



    Kieth,

    OK, I understand that this MIB is a replacement for both draft-ietf-ipfc-fcmgmt-int-mib-07.txt and RFC 2837, and it appears to be an excellent effort relative to these objectives and in fixing the many problems in the original MIBs. But I also assume one of the priorities of this WG is to identify the migration path for users of the new MIB, which is why I raised the issue. (I also raised the same issue back in April of this year.)

    The ability to discover a management URL is important and is widely used today. Can you help in bringing this requirement to the Entity MIB WG? Or maybe as you mention, a management MIB is a better approach - but is there such an effort underway? The concept of a management URL object could definitely be improved on relative to "connUnitUrl", such as allowing multiple URL entries.

    Thanks in advance for the help!

    Duane Baldwin

    --

    Keith McCloghrie <kzm@cisco.com>




            Keith McCloghrie <kzm@cisco.com>

            07/25/02 03:01 PM



    To: Duane Baldwin/Rochester/IBM@IBMUS
    cc: Elizabeth.G.Rodriguez@123mail.net (Elizabeth G. Rodriguez), ips@ece.cmu.edu, owner-ips@ece.cmu.edu, t11_3@mail.t11.org
    Subject: Re: IPS-ALL: FC Mgmt MIB WG Last Call


    Duane,

    > Here is the first of several issues/questions:
    >
    > Relative to the initial draft of this MIB (draft-ietf-ipfc-fcmgmt-int-mib-
    > 07.txt), the object "connUnitUrl" has been removed.

    No, draft-ietf-ipfc-fcmgmt-int-mib-07.txt was a different MIB. The MIB
    under review here is a replacement for both that MIB and RFC 2837. The
    replacement is needed because the previous MIB(s) had significant
    problems. In fact, the inclusion of "connUnitUrl" was part of one such
    problem, as is indicated by section 11.2.6 of the I-D being reviewed here.

    > No alternative is
    > suggested for this MIB in the text. Are there known alternatives for this
    > object? If so, this information should be included in the MIB text. If
    > there is no alternative, then this is a significant issue. Management
    > applications may use this value to enable the launch of the FC device
    > element manager.

    The semantics of "connUnitUrl" are not specific to Fibre Channel, and
    so it needs to be another WG with a more generic charter, which defines
    a MIB for "connUnitUrl" and other similar management information.

    About a year ago, I raised the issue, in the Entity-MIB WG, of the
    objects that will no longer have a home; specifically, I listed them as:

    >> The content not specific to Fibre Channel includes:
    >>
    >> - product name & info, serial#, mgmt-URL, contact, location, upTime,
    >> - state: online/offline, ok/warning/failed,
    >> - read-write control object: reset/online/offline,
    >> - module-ID (to group conn-units in a hierarchy),
    >> - a Revision Table (lists the revisions of hardware/firmware/etc.
    >> components supported by a connectivity unit),
    >> - a Sensor Table.

    The Entity MIB WG has since adopted a work item for an Entity Sensor
    MIB, and is looking at online/offline information.

    In response to my message, the WG chair said (at that time):

    >>Based on our discussions before London, I thought that Steve Blumenau
    >>(or someone else from the Fibre Channel group) would come to discuss
    >>any issues that the FC group had with the RFC 2737, in particular.
    >>However, Steve did not show up at the Entity MIB meetings. If the
    >>FC folks have any issues with RFC 2737, I encourage them to raise
    >>those issues on this list.
    >>
    >>Margaret

    and the AD said:

    >>Keith, I am sure that you realize that if there is no WG interest, that
    >>there is no way we can just assign such a topic to the WG.
    >>So... possibly based on your info below, some people may come forward
    >>to say yes yes... we are volunteering. Maybe the IPFC people come
    >>out (or nmaybe you can convince them) to help with this work in the
    >>entmib WG.
    >>
    >>An alternative path is that you do an individual submission via
    >>RFC-Editor and we can do a 4-week IETF Last Call for PS.
    >>Maybe Margareth would not mind if you post a draft and try to get
    >>some feedback via the WGs mailing list before you actually ask
    >>for it to be considered PS.

    So, if you feel strongly that MIB objects need to be defined for a
    mgmt-URL, etc., then I recommend you follow one of these two approaches.

    Keith.


    GIF image



Home

Last updated: Tue Jul 30 10:39:08 2002
11481 messages in chronological order