Subject: [Entmib] State, Status and URL info

From: Keith McCloghrie <[email-masked]>
Date: Mon, 8 Apr 2002 14:35:11 -0700 (PDT)

Hi,

Background: the IP Storage WG took over the task of defining a Fibre
Channel MIB, because little or no progress was being made towards the
previous effort (draft-ietf-ipfc-fcmgmt-int-mib-07.txt) being acceptable
for IETF standardization.  Many objects in that previous MIB have been 
omitted from the IP Storage WG's new MIB (draft-ietf-ips-fcmgmt-mib-01.txt)
because they were not specific to Fibre-Channel and/or they duplicated
MIB objects already defined in other MIBs, including the Entity MIB.
(For more details, see section 11 of draft-ietf-ips-fcmgmt-mib-01.txt.)

An issue has been raised about a few of the objects removed, that
although they are not specific to Fibre Channel, they are not present
in any standard MIB, but they are being used by existing management
application(s).

Specifically, the objects are connUnitState, connUnitStatus and
connUnitUrl (see below), where a "connectivity unit" roughly equates to
a physcial entity in the Entity MIB.

Is it appropriate to add objects for this information to the Entity MIB ??

Thanks,
Keith.
-----------------

 connUnitState OBJECT-TYPE
      SYNTAX INTEGER {
          unknown(1),
          online(2), -- available for meaningful work
          offline(3) -- unavailable for meaningful work, for
                     -- example in self-test mode, configuration, etc.
      }
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
          "This object reports the overall state of the
           connectivity unit.  The meaning of all values
           is essentially self-explanatory.  Any of these
           values may occur with any of the ConnUnitStatus
           values."
      ::= { connUnitEntry 5 }

  connUnitStatus OBJECT-TYPE
      SYNTAX INTEGER {
          unknown(1),
          unused(2), -- cannot report status
          ok(3), -- available for meaningful work
          warning(4), -- something needs attention
          failed(5) -- something has failed
      }
      ACCESS read-only
      STATUS mandatory
      DESCRIPTION
          "Overall status of the connectivity unit. The goal of this
           object is to be the single poll point to check the status
           of the connunit. If there is any other component that has
           warning, then this should be set to warning, etc. Any of
           these values may occur with any of the ConnUnitState
           values."
      ::= { connUnitEntry 6 }

  connUnitUrl OBJECT-TYPE
      SYNTAX DisplayString
      ACCESS read-write
      STATUS mandatory
      DESCRIPTION
          "URL to launch a management application,
          if applicable. Otherwise empty string.
          In a standalone unit, this would be the
          same as the top-level URL. This has the same
          definition as systemURL for keywords.
          If write is not supported, then return invalid.
          This value will be retained across boots."
      ::= { connUnitEntry 10 }

_______________________________________________
Entmib mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/entmib

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 9 Apr 2002 20:18:19 +0300

Hi Keith,

Not being very familiar with the technology I do not know exactly what a connectivity unit is. As I understand, connUnitState and connUnitStatus are kind of adminStatus and operStatus for entities. To what type of entities would they apply (physical, logical, both)?

connUnitUrl is more intriguing for me. Why needs it to be read-write? Why should such information be kept on the device, and why should an application configure by SNMP an URL to launch another application?

Thanks,

Dan

> -----Original Message-----
> From: Keith McCloghrie [mailto:[email-masked]]
> Sent: Tuesday, April 09, 2002 12:35 AM
> To: [email-masked]
> Cc: [email-masked]; [email-masked]; [email-masked]; 
> Keith McCloghrie
> Subject: [Entmib] State, Status and URL info
> 
> 
> Hi,
>

---

From: "Romascanu, Dan (Dan)" <[email-masked]>
Date: Tue, 9 Apr 2002 20:18:19 +0300

Hi Keith,

Thanks,

Dan