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

From: Duane Baldwin <[email-masked]>
Date: Fri, 26 Jul 2002 08:39:18 -0500

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                                                                                 
                      <[email-masked]>          To:       Duane Baldwin/Rochester/IBM@IBMUS                             
                                               cc:       [email-masked] (Elizabeth G. Rodriguez),   
                      07/25/02 03:01 PM         [email-masked], [email-masked], [email-masked]             
                                               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.

---

From: Keith McCloghrie <[email-masked]>
Date: Fri, 26 Jul 2002 07:50:42 -0700 (PDT)

Duane,

> today.  Can you help in bringing this requirement to the Entity MIB WG?  Or

As I indicated in my previous message, I already did what you're asking
for; I took the requirement for each of the removed objects to the
Entity MIB WG.  Some of them have since been adopted there.  For the
others, perhaps I didn't explain the requirement for them as well as
you could.  Nevertheless, I believe it will take a sustained effort to
get them not only adopted but progressed to standardization.  I'm sorry
but I don't have the time or motivation for such a sustained effort.
In contrast, you seem to be motivated; so, the question is: do you have
the time ??

Keith.