From mailman-owner@ietf.org Mon Apr 1 05:55:09 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16500 for ; Mon, 1 Apr 2002 05:55:09 -0500 (EST) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id FAA20329 for ; Mon, 1 Apr 2002 05:55:12 -0500 (EST) Date: Mon, 1 Apr 2002 05:55:12 -0500 (EST) Message-Id: <200204011055.FAA20329@optimus.ietf.org> From: mailman-owner@ietf.org Subject: ietf.org mailing list memberships reminder To: entmib-archive@ietf.org X-No-Archive: yes Precedence: bulk X-Mailman-Version: 1.0 Precedence: bulk List-Id: Session Initiation Protocol This is a reminder, sent out once a month, about your ietf.org mailing list memberships. It includes your subscription info and how to use it to change it or unsubscribe from a list. You can visit the URLs to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on. In addition to the URL interfaces, you can also use email to make such changes. For more info, send a message to the '-request' address of the list (for example, entmib-request@ietf.org) containing just the word 'help' in the message body, and an email message will be sent to you with instructions. If you have questions, problems, comments, etc, send them to mailman-owner@ietf.org. Thanks! Passwords for entmib-archive@lists.ietf.org: List Password // URL ---- -------- entmib@ietf.org CNIo https://www1.ietf.org/mailman/options/entmib/entmib-archive@lists.ietf.org From entmib-admin@ietf.org Mon Apr 8 17:36:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07168 for ; Mon, 8 Apr 2002 17:36:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14552; Mon, 8 Apr 2002 17:35:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14529 for ; Mon, 8 Apr 2002 17:35:44 -0400 (EDT) Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07137 for ; Mon, 8 Apr 2002 17:35:39 -0400 (EDT) Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id OAA05712; Mon, 8 Apr 2002 14:35:11 -0700 (PDT) From: Keith McCloghrie Message-Id: <200204082135.OAA05712@cisco.com> To: entmib@ietf.org Date: Mon, 8 Apr 2002 14:35:11 -0700 (PDT) Cc: duane.baldwin@us.ibm.com, gop@us.ibm.com, dap@cisco.com, kzm@cisco.com (Keith McCloghrie) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Entmib] State, Status and URL info Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IETF Entity MIB WG X-BeenThere: entmib@ietf.org Content-Transfer-Encoding: 7bit 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 Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From daemon@ns.ietf.org Mon Apr 8 17:36:48 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07177 for ; Mon, 8 Apr 2002 17:36:48 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id RAA14646 for entmib-archive@odin.ietf.org; Mon, 8 Apr 2002 17:36:52 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14552; Mon, 8 Apr 2002 17:35:46 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id RAA14529 for ; Mon, 8 Apr 2002 17:35:44 -0400 (EDT) Received: from cisco.com (cypher.cisco.com [171.69.11.18]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07137 for ; Mon, 8 Apr 2002 17:35:39 -0400 (EDT) Received: (from kzm@localhost) by cisco.com (8.8.8/2.6/Cisco List Logging/8.8.8) id OAA05712; Mon, 8 Apr 2002 14:35:11 -0700 (PDT) From: Keith McCloghrie Message-Id: <200204082135.OAA05712@cisco.com> To: entmib@ietf.org Date: Mon, 8 Apr 2002 14:35:11 -0700 (PDT) Cc: duane.baldwin@us.ibm.com, gop@us.ibm.com, dap@cisco.com, kzm@cisco.com (Keith McCloghrie) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Entmib] State, Status and URL info Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IETF Entity MIB WG X-BeenThere: entmib@ietf.org Content-Transfer-Encoding: 7bit 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 Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Tue Apr 9 13:20:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12678 for ; Tue, 9 Apr 2002 13:20:24 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05745; Tue, 9 Apr 2002 13:20:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05714 for ; Tue, 9 Apr 2002 13:20:14 -0400 (EDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12667 for ; Tue, 9 Apr 2002 13:20:12 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10035 for ; Tue, 9 Apr 2002 13:18:38 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10029 for ; Tue, 9 Apr 2002 13:18:37 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Entmib] State, Status and URL info Date: Tue, 9 Apr 2002 20:18:19 +0300 Message-ID: Thread-Topic: [Entmib] State, Status and URL info Thread-Index: AcHfRSc6WO70yHHHTUio98FlAj6niwApC3Zw From: "Romascanu, Dan (Dan)" To: "Keith McCloghrie" , Cc: , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA05715 Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IETF Entity MIB WG X-BeenThere: entmib@ietf.org Content-Transfer-Encoding: 8bit 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:kzm@cisco.com] > Sent: Tuesday, April 09, 2002 12:35 AM > To: entmib@ietf.org > Cc: duane.baldwin@us.ibm.com; gop@us.ibm.com; dap@cisco.com; > Keith McCloghrie > Subject: [Entmib] State, Status and URL info > > > 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 > Entmib@ietf.org > https://www1.ietf.org/mailman/listinfo/entmib > _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From daemon@optimus.ietf.org Tue Apr 9 13:20:25 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12694 for ; Tue, 9 Apr 2002 13:20:25 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA05762 for entmib-archive@odin.ietf.org; Tue, 9 Apr 2002 13:20:26 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05745; Tue, 9 Apr 2002 13:20:16 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA05714 for ; Tue, 9 Apr 2002 13:20:14 -0400 (EDT) Received: from ierw.net.avaya.com (ierw.net.avaya.com [198.152.13.101]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA12667 for ; Tue, 9 Apr 2002 13:20:12 -0400 (EDT) Received: from ierw.net.avaya.com (localhost [127.0.0.1]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10035 for ; Tue, 9 Apr 2002 13:18:38 -0400 (EDT) Received: from IS0004AVEXU1.global.avaya.com (h135-64-105-51.avaya.com [135.64.105.51]) by ierw.net.avaya.com (8.9.3+Sun/8.9.3) with ESMTP id NAA10029 for ; Tue, 9 Apr 2002 13:18:37 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.5762.3 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: [Entmib] State, Status and URL info Date: Tue, 9 Apr 2002 20:18:19 +0300 Message-ID: Thread-Topic: [Entmib] State, Status and URL info Thread-Index: AcHfRSc6WO70yHHHTUio98FlAj6niwApC3Zw From: "Romascanu, Dan (Dan)" To: "Keith McCloghrie" , Cc: , , Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by optimus.ietf.org id NAA05715 Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IETF Entity MIB WG X-BeenThere: entmib@ietf.org Content-Transfer-Encoding: 8bit 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:kzm@cisco.com] > Sent: Tuesday, April 09, 2002 12:35 AM > To: entmib@ietf.org > Cc: duane.baldwin@us.ibm.com; gop@us.ibm.com; dap@cisco.com; > Keith McCloghrie > Subject: [Entmib] State, Status and URL info > > > 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 > Entmib@ietf.org > https://www1.ietf.org/mailman/listinfo/entmib > _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From entmib-admin@ietf.org Tue Apr 9 14:24:45 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15419 for ; Tue, 9 Apr 2002 14:24:45 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10646; Tue, 9 Apr 2002 14:23:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10618 for ; Tue, 9 Apr 2002 14:23:26 -0400 (EDT) Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15310 for ; Tue, 9 Apr 2002 14:23:23 -0400 (EDT) Received: from dperkins-nb2.dsperkins.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id LAA24402; Tue, 9 Apr 2002 11:22:44 -0700 (PDT) Message-Id: <5.0.2.1.2.20020409110226.03751ec0@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 09 Apr 2002 11:22:28 -0700 To: Keith McCloghrie , entmib@ietf.org From: "David T. Perkins" Subject: Re: [Entmib] State, Status and URL info Cc: duane.baldwin@us.ibm.com, gop@us.ibm.com, dap@cisco.com, kzm@cisco.com (Keith McCloghrie) In-Reply-To: <200204082135.OAA05712@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IETF Entity MIB WG X-BeenThere: entmib@ietf.org HI, The entity MIB for a long time has needed state and status info. There are very complex models for this, and very simple models. The below two objects seem a little too simple to me. The third object looks like a "scratch pad object". It seems very problematic when you consider how it would be used when there are multiple managers. Probably the best resources on this issue are the following documents: 1) Telcordia's GR-1093 - Generic State Requirements for Network Elements Issue 2, June 2000 2) ISO/IEC 10164-2 (and ITU-T X.731) - State Management Functions August 1991 3) ITU-T M.3100 - Generic Network Information Model Version 2, 1995 Dave Sidor from the ITU-T community has made available the ITU-T documents to the IETF community for no fee. But I do not know if Telcordia has made available any of their documents, which have a fee, to the IETF community for no fee. In general, the IETF has a loosely defined generic model for state/status that was (I believe) first used in the IF table based on admin state and oper state. This model has been loosely copied to other MIB modules. The ITU-T and Telcordia models are rigorously defined, and are different from the IETF model in one important aspect. That is, in the IETF model, the oper state "follows" (if possible) the the admin state; where in the ITU-T model, the oper state is independent of the admin state. The ITU-T model is richer than the IETF model. For example, it supports redundancy. At 02:35 PM 4/8/2002 -0700, Keith McCloghrie wrote: >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 >Entmib@ietf.org >https://www1.ietf.org/mailman/listinfo/entmib Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib From daemon@optimus.ietf.org Tue Apr 9 14:24:46 2002 Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15432 for ; Tue, 9 Apr 2002 14:24:46 -0400 (EDT) Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id OAA10787 for entmib-archive@odin.ietf.org; Tue, 9 Apr 2002 14:24:48 -0400 (EDT) Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10646; Tue, 9 Apr 2002 14:23:28 -0400 (EDT) Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id OAA10618 for ; Tue, 9 Apr 2002 14:23:26 -0400 (EDT) Received: from riverstonenet.com (mail.riverstonenet.com [63.113.148.10]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA15310 for ; Tue, 9 Apr 2002 14:23:23 -0400 (EDT) Received: from dperkins-nb2.dsperkins.com by riverstonenet.com (8.9.3+Sun/SMI-SVR4-Yago) id LAA24402; Tue, 9 Apr 2002 11:22:44 -0700 (PDT) Message-Id: <5.0.2.1.2.20020409110226.03751ec0@mail4.bayarea.net> X-Sender: dperkins@mail4.bayarea.net X-Mailer: QUALCOMM Windows Eudora Version 5.0.2 Date: Tue, 09 Apr 2002 11:22:28 -0700 To: Keith McCloghrie , entmib@ietf.org From: "David T. Perkins" Subject: Re: [Entmib] State, Status and URL info Cc: duane.baldwin@us.ibm.com, gop@us.ibm.com, dap@cisco.com, kzm@cisco.com (Keith McCloghrie) In-Reply-To: <200204082135.OAA05712@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: entmib-admin@ietf.org Errors-To: entmib-admin@ietf.org X-Mailman-Version: 1.0 Precedence: bulk List-Id: IETF Entity MIB WG X-BeenThere: entmib@ietf.org HI, The entity MIB for a long time has needed state and status info. There are very complex models for this, and very simple models. The below two objects seem a little too simple to me. The third object looks like a "scratch pad object". It seems very problematic when you consider how it would be used when there are multiple managers. Probably the best resources on this issue are the following documents: 1) Telcordia's GR-1093 - Generic State Requirements for Network Elements Issue 2, June 2000 2) ISO/IEC 10164-2 (and ITU-T X.731) - State Management Functions August 1991 3) ITU-T M.3100 - Generic Network Information Model Version 2, 1995 Dave Sidor from the ITU-T community has made available the ITU-T documents to the IETF community for no fee. But I do not know if Telcordia has made available any of their documents, which have a fee, to the IETF community for no fee. In general, the IETF has a loosely defined generic model for state/status that was (I believe) first used in the IF table based on admin state and oper state. This model has been loosely copied to other MIB modules. The ITU-T and Telcordia models are rigorously defined, and are different from the IETF model in one important aspect. That is, in the IETF model, the oper state "follows" (if possible) the the admin state; where in the ITU-T model, the oper state is independent of the admin state. The ITU-T model is richer than the IETF model. For example, it supports redundancy. At 02:35 PM 4/8/2002 -0700, Keith McCloghrie wrote: >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 >Entmib@ietf.org >https://www1.ietf.org/mailman/listinfo/entmib Regards, /david t. perkins _______________________________________________ Entmib mailing list Entmib@ietf.org https://www1.ietf.org/mailman/listinfo/entmib