From owner-ipfc@standards.gadzoox.com Mon Apr 10 14:00:41 2000 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27981 for ; Mon, 10 Apr 2000 14:00:40 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id KAA11025 for ipfc-list; Mon, 10 Apr 2000 10:45:12 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from gordan.pl.gadzoox.com (gordan.pl.gadzoox.com [209.95.220.16]) by standards.gadzoox.com (8.8.7/8.8.7) with ESMTP id KAA11022 for ; Mon, 10 Apr 2000 10:45:10 -0700 Received: by gordan.pl.gadzoox.com with Internet Mail Service (5.5.2650.21) id <2JS0KHRV>; Mon, 10 Apr 2000 10:54:46 -0700 Message-ID: <312419998E3CD211A52900A0C991A47A225626@gordan.pl.gadzoox.com> From: Murali Rajagopal To: "'ipfc@standards.gadzoox.com'" Cc: "Barry B. Reinhold (E-mail)" , "Andrea Westerinen (E-mail)" Subject: RFC 2625 Interoperability Testing Call for Participation Date: Mon, 10 Apr 2000 10:54:45 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk The IETF Meeting in Australia discussed the Interoperability Testing of RFC 2625 implementations. The testing will be physically conducted at the SNIA Facility (Colorado). Andre Westerinen (andreawest@mindspring.com ) has kindly agreed to provide the details including recommended Hotels. The testing is currently slated to happen during the second week of August. Barry Reinhold from UNH (bbr@unh.edu) will oversee the actual Testing and drive the Test Suites and Configurations through his organization. There is a fee of $1500 payable to UNH. Please feel free to contact either Andrea or Barry if you have questions regarding the testing. I would like to hear (on the ipfc reflector) from all those wishing to participate in this testing . Regards, Murali Rajagopal IPFC WG Chair Senior Manager, Product Engineering Gadzoox Networks, Irvine,CA Tel: 949-789-4646, Fax: 949-789-4601 Email: murali@gadzoox.com <<...>> From owner-ipfc@standards.gadzoox.com Fri Apr 14 17:50:34 2000 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA14922 for ; Fri, 14 Apr 2000 17:50:32 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id OAA13182 for ipfc-list; Fri, 14 Apr 2000 14:37:43 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from mumm.ibr.cs.tu-bs.de (root@mumm.ibr.cs.tu-bs.de [134.169.34.190]) by standards.gadzoox.com (8.8.7/8.8.7) with SMTP id OAA13179 for ; Fri, 14 Apr 2000 14:37:38 -0700 Received: from henkell.ibr.cs.tu-bs.de (schoenw@henkell [134.169.34.191]) by mumm.ibr.cs.tu-bs.de (8.9.3/8.9.3) with ESMTP id XAA10031; Fri, 14 Apr 2000 23:46:28 +0200 (MET DST) Received: from schoenw@localhost by henkell.ibr.cs.tu-bs.de (8.7.6/tubsibr) id XAA28255; Fri, 14 Apr 2000 23:46:28 +0200 Date: Fri, 14 Apr 2000 23:46:28 +0200 Message-Id: <200004142146.XAA28255@henkell.ibr.cs.tu-bs.de> From: Juergen Schoenwaelder To: ipfc@standards.gadzoox.com Subject: draft-ietf-ipfc-fcmgmt-int-mib-03.txt mib revision Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Below is a first step to convert the SMIv1 MIB contained in into SMIv2. I have also added lots of comments (see XXX) about constructions that need to be revised in order to get this MIB into a shape that can be moved on the IETF standards track. /js FIBRE-CHANNEL-MGMT-MIB DEFINITIONS ::= BEGIN IMPORTS OBJECT-TYPE, NOTIFICATION-TYPE, MODULE-IDENTITY, Integer32, IpAddress, TimeTicks, mib-2 FROM SNMPv2-SMI TEXTUAL-CONVENTION, DisplayString FROM SNMPv2-TC; fcMgmtMIB MODULE-IDENTITY LAST-UPDATED "200004140000Z" ORGANIZATION "IETF IPFC Working Group" CONTACT-INFO "S. Blumenau EMC Corporation 171 South Street Hopkinton, MA 01748-9103 U.S.A Tel: +1 508 435 1000 Fax: +1 508 435 4657 Email: blumenau_steven@isus.emc.com" DESCRIPTION "The fibre channel management MIB module." REVISION "200004140000Z" DESCRIPTION "Initial revision, published as RFC XXXX." ::= { mib-2 8888 } -- TO BE ASSIGNED -- XXX Should this MIB not better be called FIBRE-CHANNEL-CU-MIB -- XXX (CU = connectivity unit) since all definitions seem to -- XXX belong to connectivity units. The name fibre channel -- XXX management MIB just seems to be overly broad in scope, -- XXX especially since there is a fabric element MIB as well. fcMgmtNotifications OBJECT IDENTIFIER ::= { fcMgmtMIB 0 } fcMgmtObjects OBJECT IDENTIFIER ::= { fcMgmtMIB 1 } fcMgmtConformance OBJECT IDENTIFIER ::= { fcMgmtMIB 2 } fcMgmtConfig OBJECT IDENTIFIER ::= { fcMgmtObjects 1 } fcMgmtNotifyFilter OBJECT IDENTIFIER ::= { fcMgmtObjects 2 } fcMgmtStatistics OBJECT IDENTIFIER ::= { fcMgmtObjects 3 } fcMgmtCompliances OBJECT IDENTIFIER ::= { fcMgmtConformance 1 } fcMgmtGroups OBJECT IDENTIFIER ::= { fcMgmtConformance 2 } -- Textual conventions for this MIB FcNameId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "" SYNTAX OCTET STRING (SIZE(8)) -- XXX Needs to have a non empty DESCRIPTION clause. -- XXX Is that the same as FcNameId defined in FIBRE-CHANNEL-FE-MIB? -- XXX If yes, why not reuse that definition? -- XXX It is generally unclear to me how this MIB relates to the -- XXX FIBRE-CHANNEL-FE-MIB. This needs to be clarified in the -- XXX text which goes along with this set of definitions. FcGlobalId ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "" SYNTAX OCTET STRING (SIZE(16)) -- XXX Needs to have a non empty DESCRIPTION clause. Check any -- XXX similarities with the FIBRE-CHANNEL-FE-MIB. FcEventSeverity ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "" SYNTAX INTEGER { unknown (1), emergency (2), alert (3), critical (4), error (5), warning (6), notify (7), info (8), debug (9), mark (10) -- All messages logged } -- XXX Needs to have an explanation of these values in the -- XXX DESCRIPTION clause. FcUnitType ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION " unknown(1) other(2) none of the following hub(3) passive connectivity unit supporting loop protocol switch(4) active connectivity unit supporting multiple protocols gateway(5) unit that converts not only the interface but also encapsulates the frame into another protocol. The assumption is that there are always two gateways connected together. For example, FC <-> ATM. converter(6) unit that converts from one interface to another. For example, FC <-> SCSI. hba(7) host bus adapter proxy-agent(8) software proxy-agent storage-device(9) disk,cd,tape,etc host(10) host computer storage-subsystem(11) raid, library, etc module(12) subcomponent of a system swdriver(13) software driver storage-access-device(14) provides storage management and access for hetergeneous hosts and heterogeneous devices." SYNTAX INTEGER { unknown(1), other(2), hub(3), switch(4), gateway(5), converter(6), hba(7), proxy-agent(8), storage-device(9), host(10), storage-subsystem(11), module(12), swdriver(13), storage-access-device(14) } -- XXX Hyphens are not allowed. I also do not understand the -- XXX difference between unknown and other. Is this enumeration -- XXX fixed for all times or does it need maintenance? If yes, -- XXX I suggest to split these things into a separate TC module. -- XXX Needs to have a non empty DESCRIPTION clause. -- the connectivity unit group -- Implementation of the group is mandatory for all systems. -- XXX Conformance requirements go into compliance statements and -- XXX not into comments in SMIv2. fcConnUnitNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of connectivity units present on this system. May be a count of the boards in a chassis or the number of full boxes in a rack." ::= { fcMgmtConfig 1 } -- XXX I do not think that the fcConnUnitNumber can be negative. -- XXX Either use Unsigned32 or use a suitable range restriction. -- XXX (I suggest Unsigned32.) And what about the value 0? Does -- XXX it make sense or does it have a special meaning? fcConnURL OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "The top-level URL of the system. If it does not exist the value is an empty string. The URL format is implementation dependent and can have keywords embedded that are preceeded by a percent sign (eg, %USER). The following are the defined keywords that will be recognized and replaced with data during a launch. USER - replace with username PASSWORD - replace with password GLOBALID - replace with globalid SERIALNO - replace with serial number" ::= { fcMgmtConfig 2 } -- XXX I do not understand who is replacing these keywords so -- XXX I can't say whether this is a good thing to do or not. -- XXX At least PASSWORD may trigger some serious security review. -- The connectivity table contains general information on the -- system's connectivity units. fcConnUnitTable OBJECT-TYPE SYNTAX SEQUENCE OF FcConnUnitEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The connectivity table contains general information on the system's units. The number of entries is given by the value of fcConnUnitNumber. It is 1 for stand-alone systems." ::= { fcMgmtConfig 3 } fcConnUnitEntry OBJECT-TYPE SYNTAX FcConnUnitEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A connectivity unit entry containing objects for a particular unit." INDEX { fcConnUnitId } ::= { fcConnUnitTable 1 } FcConnUnitEntry ::= SEQUENCE { fcConnUnitId OCTET STRING, fcConnUnitGlobalId FcGlobalId, fcConnUnitType FcUnitType, fcConnUnitNumPorts Integer32, fcConnUnitState INTEGER, fcConnUnitStatus INTEGER, fcConnUnitProduct DisplayString, fcConnUnitSerialNo DisplayString, fcConnUnitUpTime TimeTicks, fcConnUnitUrl DisplayString, fcConnUnitDomainId OCTET STRING, fcConnUnitProxyMaster INTEGER, fcConnUnitPrincipal INTEGER, fcConnUnitNumSensors Integer32, fcConnUnitNumRevs Integer32, fcConnUnitModuleId OCTET STRING, fcConnUnitName DisplayString, fcConnUnitInfo DisplayString, fcConnUnitControl INTEGER, fcConnUnitContact DisplayString, fcConnUnitLocation DisplayString, fcConnUnitEventFilter FcEventSeverity, fcConnUnitNumEvents Integer32, fcConnUnitMaxEvents Integer32, fcConnUnitEventCurrID Integer32 } fcConnUnitId OBJECT-TYPE SYNTAX OCTET STRING (SIZE (16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The unique identification for this connectivity unit among those within this proxy domain. The value MUST be unique within the proxy domain because it is the index variable for fcConnUnitTable. The value assigned to a given conectivity unit SHOULD be persistent across agent and unit resets. It SHOULD be the same as fcConnUnitGlobalId if fcConnUnitGlobalId is known and stable." ::= { fcConnUnitEntry 1 } -- XXX Are there any constraints/semantics associated with the -- XXX fcConnUnitId or can it be a sequence of arbitrary binary -- XXX octets? And should it not share the type with -- XXX fcConnUnitGlobalId? That is, should FcGlobalId not be -- XXX named FcConnUnitId and be used wherever you have an -- XXX identification for a connectivity unit? fcConnUnitGlobalId OBJECT-TYPE SYNTAX FcGlobalId MAX-ACCESS read-only STATUS current DESCRIPTION "An optional global-scope identifier for this connectivity unit. It MUST be a WWN for this connectivity unit or 16 octets of value zero. WWN formats requiring fewer than 16 octets MUST be extended to 16 octets with trailing zero octets. If a WWN is used for fcConnUnitId, the same WWN MUST be used for fcConnUnitGlobalId. When a non-zero value is provided, it SHOULD be persistent across agent and unit resets. It SHOULD be globally unique. It SHOULD be one of these FC-PH/PH3 formats: IEEE (NAA=1) IEEE Extended (NAA=2) IEEE Registered (NAA=5). IEEE Registered extended (NAA=6). Use of the IEEE formats allows any IEEE-registered vendor to assure global uniqueness independently. The following are some references on IEEE WWN formats: http://standards.ieee.org/regauth/oui/tutorials/fibreformat.html http://standards.ieee.org/regauth/oui/tutorials/fibrecomp_id.html If one or more WWNs are associated with the connectivity unit via other management methods, one of them SHOULD be used for fcConnUnitGlobalId. If there is not a WWN assigned specifically to the connectivity unit, there is some merit, though not a requirement, to using a WWN assigned to (one of) its permanently attached FC/LAN interface(s). This can not risk uniqueness, though. As a counterexample, if your agent runs in a host and the host has an HBA, it is quite possible that agent, host, and HBA will all be distinct connectivity units, so the host and agent can not use the WWN of the HBA. Another example: If your hub has a built-in Ethernet port, it might be reasonable for the hub to use its LAN address (prefixed with the appropriate NAA) as its fcConnUnitId. But if the Ethernet were a replaceable PCCard, the hub should have an independent ID." ::= { fcConnUnitEntry 2 } fcConnUnitType OBJECT-TYPE SYNTAX FcUnitType MAX-ACCESS read-only STATUS current DESCRIPTION "The type of this connectivity unit." ::= { fcConnUnitEntry 3 } fcConnUnitNumPorts OBJECT-TYPE SYNTAX Integer32 UNITS "ports" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of physical ports in the connectivity unit (internal/embedded, external)." ::= { fcConnUnitEntry 4 } -- XXX Negative ports? This should probably be unsigned or at least -- XXX have a range restriction. UNITS clause? fcConnUnitState OBJECT-TYPE SYNTAX INTEGER { unknown(1), online(2), offline(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Overall state of the connectivity unit." ::= { fcConnUnitEntry 5 } -- XXX Can this object in principle be written? Would it make sense -- XXX to introduce an fcConnUnitAdminStatus and fcConnUnitOperStatus -- XXX to export the administratively assigned and the current operational -- XXX state? fcConnUnitStatus OBJECT-TYPE SYNTAX INTEGER { unknown(1), unused(2), ok(3), warning(4), -- needs attention failed(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "Overall status of the connectivity unit." ::= { fcConnUnitEntry 6 } -- XXX How are these statuses related to the previous state -- XXX enumeration? Which combinations are possible? The -- XXX enumerated values should be explained in the DESCRIPTION -- XXX clause. fcConnUnitProduct OBJECT-TYPE SYNTAX DisplayString (SIZE (0..79)) MAX-ACCESS read-only STATUS current DESCRIPTION "The connectivity unit vendor's product model name." ::= { fcConnUnitEntry 7 } -- XXX This should probably be an SnmpAdminString for -- XXX internationalization. Is there any architectural reason -- XXX for the size constraint? Why not allow the full default -- XXX length of 0..255? (You can lower the bounds in a conformance -- XXX statement if that is important for some reason.) fcConnUnitSerialNo OBJECT-TYPE SYNTAX DisplayString (SIZE (0..79)) MAX-ACCESS read-only STATUS current DESCRIPTION "The serial number for this connectivity unit." ::= { fcConnUnitEntry 8 } -- XXX This should probably be an SnmpAdminString for -- XXX internationalization. Is there any architectural reason -- XXX for the size constraint? Why not allow the full default -- XXX length of 0..255? (You can lower the bounds in a conformance -- XXX statement if that is important for some reason.) fcConnUnitUpTime OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "The number of centiseconds since the last unit initialization." ::= { fcConnUnitEntry 9 } fcConnUnitUrl OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current 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 fcConnURL for keywords." ::= { fcConnUnitEntry 10 } -- XXX See the comments on fcConnURL regarding the keywords. You may -- XXX want to define a TC for this special DisplayString for URLs -- XXX with embedded keywords. Does it make protocol sense to write -- XXX this object? fcConnUnitDomainId OBJECT-TYPE SYNTAX OCTET STRING (SIZE(3)) MAX-ACCESS read-only STATUS current DESCRIPTION "24 bit Fibre Channel address ID of this connectivity unit, right justified with leading zero's if required. If this value is not applicable, return all bits set to one." ::= { fcConnUnitEntry 11 } -- XXX How can a 24 bit address be right justified if it goes into -- XXX an OCTET STRING of size 3? I think this description needs -- XXX a rewrite. fcConnUnitProxyMaster OBJECT-TYPE SYNTAX INTEGER { unknown(1), no(2), yes(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "A value of 'yes' means this is the proxy master unit for a set of managed units. For example, this could be the only unit with a management card in it for a set of units. A standalone unit should return 'yes' for this object." ::= { fcConnUnitEntry 12 } -- XXX Does it make protocol sense to write this object? fcConnUnitPrincipal OBJECT-TYPE SYNTAX INTEGER { unknown(1), no(2), yes(3) } MAX-ACCESS read-only STATUS current DESCRIPTION "Whether this connectivity unit is the principal unit within the group of fabric elements. If this value is not applicable, return unknown." ::= { fcConnUnitEntry 13 } -- XXX Does it make protocol sense to write this object? fcConnUnitNumSensors OBJECT-TYPE SYNTAX Integer32 UNITS "sensors" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of sensors in the fcConnUnitSensorTable." ::= { fcConnUnitEntry 14 } -- XXX Negative ports? This should probably be unsigned or at least -- XXX have a range restriction. UNITS clause? fcConnUnitNumRevs OBJECT-TYPE SYNTAX Integer32 UNITS "revisions" MAX-ACCESS read-only STATUS current DESCRIPTION "The number of revisions in the fcConnUnitRevsTable." DEFVAL { 1 } ::= { fcConnUnitEntry 15 } -- XXX Negative revisions? This should probably be unsigned or at least -- XXX have a range restriction. UNITS clause? fcConnUnitModuleId OBJECT-TYPE SYNTAX OCTET STRING (SIZE(16)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is a unique id, persistent between boots, that can be used to group a set of connectivity units together into a module. The intended use would be to create a connectivity unit with a fcConnUnitType of 'module' to represent a physical or logical group of connectivity units. Then the members of the group would set the value of fcConnUnitId for this 'container' connectivity unit. fcConnUnitModuleId should be zeros if this connectivity unit is not part of a module." ::= { fcConnUnitEntry 16 } -- XXX What about adding a DEFVAL of zeros here? Does it make protocol -- XXX sense to write this object? fcConnUnitName OBJECT-TYPE SYNTAX DisplayString (SIZE(0..79)) MAX-ACCESS read-write STATUS current DESCRIPTION "A display string containing a name for this connectivity unit. This object value should be persistent between boots." ::= { fcConnUnitEntry 17 } -- XXX This should probably be an SnmpAdminString for -- XXX internationalization. Is there any architectural reason -- XXX for the size constraint? Why not allow the full default -- XXX length of 0..255? (You can lower the bounds in a conformance -- XXX statement if that is important for some reason.) fcConnUnitInfo OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-write STATUS current DESCRIPTION "A display string containing information about this connectivity unit. This object value should be persistent between boots." ::= { fcConnUnitEntry 18 } -- XXX This should probably be an SnmpAdminString for -- XXX internationalization. fcConnUnitControl OBJECT-TYPE SYNTAX INTEGER { unknown(1), invalid(2), resetConnUnitColdStart(3), resetConnUnitWarmStart(4), offlineConnUnit(5), onlineConnUnit(6) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to control the addressed connectivity unit. NOTE: 'Cold Start' and 'Warm Start' are as defined in MIB II and are not meant to be a factory reset. resetConnUnitColdStart: the addressed unit performs a 'Cold Start' reset. resetConnUnitWarmStart: the addressed unit performs a 'Warm Start' reset. offlineConnUnit: the addressed unit puts itself into an implementation dependant 'offline' state. In general,if a unit is in an offline state, it cannot be used to perform meaningful Fibre Channel work. onlineConnUnit: the addressed unit puts itself into an implementation dependant 'online' state. In general, if a unit is in an online state, it is capable of performing meaningful Fibre Channel work. NOTE: Each implementation may chose not to allow any or all of these values on a SET. " ::= { fcConnUnitEntry 19 } -- XXX This definition is broken. First, consider my suggestion -- XXX for fcConnUnitState. The reference to MIB II is ambiguous -- XXX in what it means. Second, the meaning of coldStart and warmStart -- XXX in RFC 1907 is the reinitalization of the SNMP entity and -- XXX this is most likely not what you want (since you stick it -- XXX here into the fcConnUnitTable). Also, please be precise -- XXX in what happens if I choose to implement some of these -- XXX values as read-only and a manager tries to write them. fcConnUnitContact OBJECT-TYPE SYNTAX DisplayString (SIZE (0..79)) MAX-ACCESS read-write STATUS current DESCRIPTION "Contact information for this connectivity unit." ::= { fcConnUnitEntry 20 } -- XXX This should probably be an SnmpAdminString for -- XXX internationalization. Is there any architectural reason -- XXX for the size constraint? Why not allow the full default -- XXX length of 0..255? (You can lower the bounds in a conformance -- XXX statement if that is important for some reason.) -- XXX You may also want to say a bit more what you expect to -- XXX be in the fcConnUnitContact object and what the value looks -- XXX like if you do not have contact information. fcConnUnitLocation OBJECT-TYPE SYNTAX DisplayString (SIZE (0..79)) MAX-ACCESS read-write STATUS current DESCRIPTION "Location information for this connectivity unit." ::= { fcConnUnitEntry 21 } -- XXX This should probably be an SnmpAdminString for -- XXX internationalization. Is there any architectural reason -- XXX for the size constraint? Why not allow the full default -- XXX length of 0..255? (You can lower the bounds in a conformance -- XXX statement if that is important for some reason.) fcConnUnitEventFilter OBJECT-TYPE SYNTAX FcEventSeverity MAX-ACCESS read-only STATUS current DESCRIPTION "This value defines the event severity that will be logged by this connectivity unit. All events of severity less than or equal to fcConnUnitEventFilter are logged in the fcConnUnitEventTable." ::= { fcConnUnitEntry 22 } -- XXX I think this object should be read-write. You probably want -- XXX to say something in the conformance statements about what -- XXX happens if I do not support event logging (in case that is -- XXX a conformance option). fcConnUnitNumEvents OBJECT-TYPE SYNTAX Integer32 UNITS "events" MAX-ACCESS read-only STATUS current DESCRIPTION "Number of events currently in the fcConnUnitEventTable." ::= { fcConnUnitEntry 23 } -- XXX Negative events? This should probably be unsigned or at least -- XXX have a range restriction. UNITS clause? fcConnUnitMaxEvents OBJECT-TYPE SYNTAX Integer32 UNITS "events" MAX-ACCESS read-only STATUS current DESCRIPTION "Max number of events that can be defined in fcConnUnitEventTable." ::= { fcConnUnitEntry 24 } -- XXX Negative events? This should probably be unsigned or at least -- XXX have a range restriction. UNITS clause? I also think the -- XXX description needs to be rewritten since the event table is -- XXX actually a circular buffer and this object seems to define -- XXX the size of the circular buffer. It also makes protocol -- XXX sense to define this object read-write. fcConnUnitEventCurrID OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The last used event id (fcConnUnitEventId)." ::= { fcConnUnitEntry 24 } -- XXX Negative event ids? It might be useful to define a TC for -- XXX the index type so that you can use it whenever you need to -- XXX refer to an event. Furthermore, you should define what the -- XXX value is in case there is not event in the fcConnUnitEventTable -- The revisions table list the revisions supported by connectivity -- units. fcConnUnitRevsTable OBJECT-TYPE SYNTAX SEQUENCE OF FcConnUnitRevsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of the revisions supported by connectivity units managed by this agent." ::= { fcMgmtConfig 4 } -- XXX Please state exactly which revisions you refer to. Are these -- XXX revisions of the fibre channel protocol? Or revisions of the -- XXX fibre channel MIBs? ...? fcConnUnitRevsEntry OBJECT-TYPE SYNTAX FcConnUnitRevsEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "" INDEX { fcConnUnitRevsUnitId, fcConnUnitRevsIndex } ::= { fcConnUnitRevsTable 1 } -- XXX Should the first INDEX component not be fcConnUnitId? -- XXX This entry definitions must have a non-empty description clause. FcConnUnitRevsEntry ::= SEQUENCE { fcConnUnitRevsUnitId OCTET STRING, fcConnUnitRevsIndex Integer32, fcConnUnitRevsRevision DisplayString, fcConnUnitRevsDescription DisplayString } fcConnUnitRevsUnitId OBJECT-TYPE SYNTAX OCTET STRING (SIZE (16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The connUnitId of the connectivity unit that contains this revision table." ::= { fcConnUnitRevsEntry 1 } -- XXX I think this object is not needed (see comment above). If it -- XXX is needed, please consider to define a TC for the type and -- XXX use it throughout the MIB. fcConnUnitRevsIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value among all connUnitRevsEntrys with the same value of connUnitRevsUnitId, in the range between 1 and fcConnUnitNumRevs for this connectivity unit." ::= { fcConnUnitRevsEntry 2 } -- XXX The ranges between fcConnUnitRevsIndex and fcConnUnitNumRevs -- XXX should be aligned. fcConnUnitRevsRevision OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "A vendor-specific string identifying a revision of a component of the connectivity unit." ::= { fcConnUnitRevsEntry 3 } -- XXX The descrition introduces the notion of a component of a -- XXX connectivity unit. I think this needs more explanation. -- XXX This should probably be an SnmpAdminString for -- XXX internationalization. fcConnUnitRevsDescription OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "Description of a component to which the revision corresponds." ::= { fcConnUnitRevsEntry 4 } -- XXX This should probably be an SnmpAdminString for -- XXX internationalization. -- The sensor table list the sensors supported by each connectivity -- unit. fcConnUnitSensorTable OBJECT-TYPE SYNTAX SEQUENCE OF FcConnUnitSensorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of the sensors supported by each connectivity unit." ::= { fcMgmtConfig 5 } fcConnUnitSensorEntry OBJECT-TYPE SYNTAX FcConnUnitSensorEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains the information for a specific sensor." INDEX { fcConnUnitSensorUnitId, fcConnUnitSensorIndex } ::= { fcConnUnitSensorTable 1 } -- XXX Should the first INDEX component not be fcConnUnitId? FcConnUnitSensorEntry ::= SEQUENCE { fcConnUnitSensorUnitId OCTET STRING, fcConnUnitSensorIndex Integer32, fcConnUnitSensorName DisplayString, fcConnUnitSensorStatus INTEGER, fcConnUnitSensorInfo DisplayString, fcConnUnitSensorMessage DisplayString, fcConnUnitSensorType INTEGER, fcConnUnitSensorCharacteristic INTEGER } fcConnUnitSensorUnitId OBJECT-TYPE SYNTAX OCTET STRING (SIZE (16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The fcConnUnitId of the connectivity unit that contains this sensor table." ::= { fcConnUnitSensorEntry 1 } -- XXX I think this object is not needed (see comment above). If it -- XXX is needed, please consider to define a TC for the type and -- XXX use it throughout the MIB. fcConnUnitSensorIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value among all connUnitSensorEntrys with the same value of connUnitSensorUnitId, in the range between 1 and fcConnUnitNumSensors." ::= { fcConnUnitSensorEntry 2 } -- XXX The ranges between fcConnUnitSensorIndex and fcConnUnitNumSensors -- XXX should be aligned. fcConnUnitSensorName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "A textual identification of the sensor intended primarily for operator use." ::= { fcConnUnitSensorEntry 3 } -- XXX This should probably be an SnmpAdminString for -- XXX internationalization. Should this be read-write? fcConnUnitSensorStatus OBJECT-TYPE SYNTAX INTEGER { unknown(1), other(2), ok(3), -- the sensor indicates ok warning(4), -- the sensor indicates a warning failed(5) -- the sensor indicates failure } MAX-ACCESS read-only STATUS current DESCRIPTION "The status indicated by the sensor." ::= { fcConnUnitSensorEntry 4 } -- XXX The enumerated values should be described in the DESCRIPTION. -- XXX Also, explain the difference between unknown(1) and other(2). fcConnUnitSensorInfo OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "Miscellaneous static information about the sensor such as its serial number." ::= { fcConnUnitSensorEntry 5 } -- XXX This should probably be an SnmpAdminString for -- XXX internationalization. fcConnUnitSensorMessage OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "This describes the status of the sensor as a message. It may also provide more resolution on the sensor indication, for example 'Cover temperature 1503K, above nominal operating range'" ::= { fcConnUnitSensorEntry 6 } -- XXX This should probably be an SnmpAdminString for -- XXX internationalization. fcConnUnitSensorType OBJECT-TYPE SYNTAX INTEGER { unknown(1), other(2), battery(3), fan(4), power-supply(5), transmitter(6), enclosure(7), board(8), receiver(9) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of component being monitored by this sensor." ::= { fcConnUnitSensorEntry 7 } -- XXX Hyphens are not allowed. All enumerated values should be -- XXX described in the DESCRIPTION clause. What is the difference -- XXX between unknown(1) and other(2)? fcConnUnitSensorCharacteristic OBJECT-TYPE SYNTAX INTEGER { unknown(1), other(2), temperature(3), pressure(4), emf(5), currentValue(6), -- current is a keyword airflow(7), frequency(8), power(9) } MAX-ACCESS read-only STATUS current DESCRIPTION "The characteristics being monitored by this sensor." ::= { fcConnUnitSensorEntry 8 } -- XXX The enumerations need to be clearly described. I personally -- XXX am not 100 % what emf(5) stands for (electro magnetic field?). -- XXX What is the difference between unknown(1) and other(2)? -- The port table contains generic information on ports for a specific -- connectivity unit. fcConnUnitPortTable OBJECT-TYPE SYNTAX SEQUENCE OF FcConnUnitPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Generic information on ports for a specific connectivity unit." ::= { fcMgmtConfig 6 } fcConnUnitPortEntry OBJECT-TYPE SYNTAX FcConnUnitPortEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains the information for a specific port." INDEX { fcConnUnitPortUnitId, fcConnUnitPortIndex } ::= { fcConnUnitPortTable 1 } -- XXX Should the first INDEX component not be fcConnUnitId? FcConnUnitPortEntry ::= SEQUENCE { fcConnUnitPortUnitId OCTET STRING, fcConnUnitPortIndex Integer32, fcConnUnitPortType INTEGER, fcConnUnitPortFCClassCap OCTET STRING, fcConnUnitPortFCClassOp OCTET STRING, fcConnUnitPortState INTEGER, fcConnUnitPortStatus INTEGER, fcConnUnitPortTransmitterType INTEGER, fcConnUnitPortModuleType INTEGER, fcConnUnitPortWwn FcNameId, fcConnUnitPortFCId OCTET STRING, fcConnUnitPortSerialNo DisplayString, fcConnUnitPortRevision DisplayString, fcConnUnitPortVendor DisplayString, fcConnUnitPortSpeed INTEGER, fcConnUnitPortControl INTEGER, fcConnUnitPortName DisplayString, fcConnUnitPortPhysicalNumber INTEGER, fcConnUnitPortStatObject OBJECT IDENTIFIER } fcConnUnitPortUnitId OBJECT-TYPE SYNTAX OCTET STRING (SIZE (16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The fcConnUnitId of the connectivity unit that contains this port." ::= { fcConnUnitPortEntry 1 } -- XXX I think this object is not needed (see comment above). If it -- XXX is needed, please consider to define a TC for the type and -- XXX use it throughout the MIB. fcConnUnitPortIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value among all connUnitPortEntrys on this connectivity unit, between 0 and fcConnUnitNumPorts." ::= { fcConnUnitPortEntry 2 } -- XXX The ranges between fcConnUnitPortIndex and fcConnUnitNumPorts -- XXX should be aligned. fcConnUnitPortType OBJECT-TYPE SYNTAX INTEGER { unknown (1), other (2), not-present (3), hub-port (4), n-port (5), -- end port for fabric l-port (6), -- end port for loop fl-port (7), -- public loop f-port (8), -- fabric port e-port (9), -- fabric expansion port g-port (10), -- generic fabric port domain-ctl (11), -- domain controller hub-controller(12), scsi (13), -- parallel SCSI port escon (14), lan (15), wan (16) } MAX-ACCESS read-only STATUS current DESCRIPTION "The port type." ::= { fcConnUnitPortEntry 3 } -- XXX Hyphens are not allowed. All enumerated values should be -- XXX described in the DESCRIPTION clause. What is the difference -- XXX between unknown(1) and other(2)? fcConnUnitPortFCClassCap OBJECT-TYPE SYNTAX OCTET STRING (SIZE (2)) MAX-ACCESS read-only STATUS current DESCRIPTION "Bit mask that specifies the classes of service capability of this port. If this is not applicable, return all bits set to zero. The bits have the following definition: unknown - 0 class-f - 1 class-one - 2 class-two - 4 class-three - 8 class-four - 16 class-five - 32 class-six - 64" ::= { fcConnUnitPortEntry 4 } -- XXX You should use the BITS SMIv2 type here. Hyphens are not allowed. -- XXX All enumerated bits should be described in the DESCRIPTION clause. -- XXX What about a similar definition of FcCosCap in the FIBRE-CHANNEL-FE-MIB? fcConnUnitPortFCClassOp OBJECT-TYPE SYNTAX OCTET STRING (SIZE (2)) MAX-ACCESS read-only STATUS current DESCRIPTION "Bit mask that specifies the classes of service that are currently operational. If this is not applicable, return all bits set to zero. This object has the same definition as fcConnUnitPortFCClassCap" ::= { fcConnUnitPortEntry 5 } -- XXX The object does not have the same definition/semantics. Only -- XXX the data type is the same. And since this is the case, you -- XXX should introduce a TC for the data type. fcConnUnitPortState OBJECT-TYPE SYNTAX INTEGER { unknown(1), online(2), offline(3), bypassed(4) } MAX-ACCESS read-only STATUS current DESCRIPTION "The state of the port hardware." ::= { fcConnUnitPortEntry 6 } -- XXX All enumerated values should be described in the DESCRIPTION clause. -- XXX Can this object in principle be written? Would it make sense -- XXX to introduce an fcConnUnitPortStatus and fcConnUnitPortOperStatus -- XXX to export the administratively assigned and the current operational -- XXX state? fcConnUnitPortStatus OBJECT-TYPE SYNTAX INTEGER { unknown (1), unused (2), ok (3), warning (4), -- needs attention failure (5), notparticipating(6), initializing (7), bypass (8) -- manually or automatically -- isolated from loop or fabric } MAX-ACCESS read-only STATUS current DESCRIPTION "An overall protocol status for the port." ::= { fcConnUnitPortEntry 7 } -- XXX How are these statuses related to the previous state -- XXX enumeration? Which combinations are possible? The -- XXX enumerated values should be explained in the DESCRIPTION -- XXX clause. fcConnUnitPortTransmitterType OBJECT-TYPE SYNTAX INTEGER { unknown(1), other(2), unused(3), shortwave(4), longwave(5), copper(6), scsi(7), longwaveNoOFC(8), shortwaveNoOFC(9), longwaveLED(10) } MAX-ACCESS read-only STATUS current DESCRIPTION "The technology of the port transceiver." ::= { fcConnUnitPortEntry 8 } -- XXX The enumerated values should be explained in the DESCRIPTION -- XXX clause. What is the difference between unknown(1) and other(2)? fcConnUnitPortModuleType OBJECT-TYPE SYNTAX INTEGER { unknown(1), other(2), gbic(3), embedded(4), -- fixed, ie, oneXnine glm(5), gbicSerialId(6), gbicNoSerialId(7), gbicNotInstalled(8), smallFormFactor(9) } MAX-ACCESS read-only STATUS current DESCRIPTION "The module type of the port connector." ::= { fcConnUnitPortEntry 9 } -- XXX The enumerated values should be explained in the DESCRIPTION -- XXX clause. What is the difference between unknown(1) and other(2)? -- XXX What is the relationship between fcConnUnitPortType and -- XXX fcConnUnitPortModuleType? fcConnUnitPortWwn OBJECT-TYPE SYNTAX FcNameId MAX-ACCESS read-only STATUS current DESCRIPTION "The World Wide Name of the port if applicable, otherwise empty string." ::= { fcConnUnitPortEntry 10 } -- XXX Can this value not in principle be modified? fcConnUnitPortFCId OBJECT-TYPE SYNTAX OCTET STRING (SIZE(3)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is the assigned Fibre Channel ID of this port. This value is expected to be a Big Endian value of 24 bits. If this is loop, then it is the ALPA that is connected. If this is an eport, then it will only contain the domain ID left justified, zero filled. If this port does not have a Fibre Channel address, return all bits set to 1." ::= { fcConnUnitPortEntry 11 } -- XXX Is this the same as FcAddressId defined in FIBRE-CHANNEL-FE-MIB? -- XXX If yes, why no use that definition? fcConnUnitPortSerialNo OBJECT-TYPE SYNTAX DisplayString (SIZE(0..79)) MAX-ACCESS read-only STATUS current DESCRIPTION "The serial number of the unit (e.g., for a GBIC). If this is not applicable, return a zero-length string." ::= { fcConnUnitPortEntry 12 } -- XXX This should probably be an SnmpAdminString for -- XXX internationalization. Is there any architectural reason -- XXX for the size constraint? Why not allow the full default -- XXX length of 0..255? (You can lower the bounds in a conformance -- XXX statement if that is important for some reason.) fcConnUnitPortRevision OBJECT-TYPE SYNTAX DisplayString (SIZE(0..79)) MAX-ACCESS read-only STATUS current DESCRIPTION "The port revision (e.g., for a GBIC)." ::= { fcConnUnitPortEntry 13 } -- XXX This should probably be an SnmpAdminString for -- XXX internationalization. Is there any architectural reason -- XXX for the size constraint? Why not allow the full default -- XXX length of 0..255? (You can lower the bounds in a conformance -- XXX statement if that is important for some reason.) fcConnUnitPortVendor OBJECT-TYPE SYNTAX DisplayString (SIZE(0..79)) MAX-ACCESS read-only STATUS current DESCRIPTION "The port vendor (e.g., for a GBIC)." ::= { fcConnUnitPortEntry 14 } -- XXX This should probably be an SnmpAdminString for -- XXX internationalization. Is there any architectural reason -- XXX for the size constraint? Why not allow the full default -- XXX length of 0..255? (You can lower the bounds in a conformance -- XXX statement if that is important for some reason.) fcConnUnitPortSpeed OBJECT-TYPE SYNTAX Integer32 UNITS "kilobytes per second" MAX-ACCESS read-only STATUS current DESCRIPTION "The speed of the port in kilobytes per second." ::= { fcConnUnitPortEntry 15 } -- XXX Negative speed? Should probably be a Gauge32? UNITS clause? fcConnUnitPortControl OBJECT-TYPE SYNTAX INTEGER { unknown(1), invalid(2), resetConnUnitPort(3), bypassConnUnitPort(4), unbypassConnUnitPort(5), offlineConnUnitPort(6), onlineConnUnitPort(7), resetConnUnitPortCounters(8) } MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to control the addressed connUnit's port. Valid commands are: resetConnUnitPort: If the addressed connectivity unit allows this operation to be performed to this port, the addressed port performs a vendor-specific 'reset' operation. Examples of these operations are: the Link Reset protocol, the Loop Initialization protocol, or a resynchronization occurring between the transceiver in the addressed port to the transceiver that the port is connected to. bypassConnUnitPort: If the addressed connectivity unit allows this operation to be performed to this port, the addressed port performs a vendor-specific 'bypass' operation. Examples of these operations are: transitioning from online to offline, a request(NON-PARTICIPATING) command to the Loop Port state machine, or removal of the port from an arbitrated loop by a hub. unbypassConnUnitPort: If the addressed connectivity unit allows this operation to be performed to this port, the addressed port performs a vendor-specific 'unbypass' operation. Examples of these operations are: the Link Failure protocol, a request(PARTICIPATING) command to the Loop Port state machine, or addition of the port to an arbitrated loop by a hub. offlineConnUnitPort: If the addressed connectivity unit allows this operation to be performed to this port, the addressed port performs a vendor-specific 'offline' operation. Examples of these operations are: disabling a port's transceiver, the Link Failure protocol, request(NON-PARTICIPATING) command to the Loop Port state machine, or removal of the port from an arbitrated loop by a hub. onlineConnUnitPort: If the addressed connectivity unit allows this operation to be performed to this port, the addressed port performs a vendor-specific 'online' operation. Examples of these operations are: enabling a port's transceiver, the Link Failure protocol, request(PARTICIPATING) command to the Loop Port state machine, or addition of the port from an arbitrated loop by a hub. NOTE: Each implementation may chose not to allow any or all of these values on a SET." ::= { fcConnUnitPortEntry 16 } -- XXX What is resetConnUnitPortCounters? I hope it is not what -- XXX the name suggests. Anyway, it must be explained. -- XXX Also, please be precise in what happens if I choose to -- XXX implement some of these values as read-only and a manager -- XXX tries to write them. fcConnUnitPortName OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-write STATUS current DESCRIPTION "A string describing the addressed port." ::= { fcConnUnitPortEntry 17 } -- XXX This should probably be an SnmpAdminString for -- XXX internationalization. Is this really a name? Or should -- XXX it be fcConnUnitPortInfo? fcConnUnitPortPhysicalNumber OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "This is the internal port number this port is known by. In many implementations, this should be the same as fcConnUnitPortIndex. Some implementations may have an internal port representation not compatible with the rules for table indeces. In that case, provide the internal representation of this port in this object. This value may also be used in the fcConnUnitLinkPortNumberX or fcConnUnitLinkPortNumberY objects of the fcConnUnitLinkTable." ::= { fcConnUnitPortEntry 18 } -- XXX I have doubts that it is useful to export the internal numbering -- XXX scheme. Also, I have doubts that people use negative numbers. -- XXX I also think that the name is misleading. It should probably be -- XXX fcConnUnitPortInternalNumber. fcConnUnitPortStatObject OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "This contains the OID of the first object of the table that contains the statistics for this particular port. If this has a value of zero, then there are no statistics available for this port. The port type information will help identify the statistics objects that will be found in the table. From this point, one would do a getnext to get the next statistics object. When the first part of the OID changes, the end of table is reached." ::= { fcConnUnitPortEntry 19 } -- XXX Not sure yet I understand how this works. If the table is -- XXX properly indexed, than there is no need to define a range -- XXX of relevant entries. Which statistics tables can apply for -- XXX a given port? Is it not possible to deduce the statistics -- XXX table from port type? Is this really needed? And what is a -- XXX an OBJECT IDENTIFIER with a value of zero? -- The event table contains information about connectivity unit events. fcConnUnitEventTable OBJECT-TYPE SYNTAX SEQUENCE OF FcConnUnitEventEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of connectivity unit events. Errors, warnings, and information should be reported in this table." ::= { fcMgmtConfig 7 } fcConnUnitEventEntry OBJECT-TYPE SYNTAX FcConnUnitEventEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains information on a specific event for the given connectivity unit." INDEX { fcConnUnitEventUnitId, fcConnUnitEventIndex } ::= { fcConnUnitEventTable 1 } -- XXX Should the first INDEX component not be fcConnUnitId? FcConnUnitEventEntry ::= SEQUENCE { fcConnUnitEventUnitId OCTET STRING, fcConnUnitEventIndex Integer32, fcConnUnitEventDateAndTime DisplayString, fcConnUnitEventTimeStamp TimeTicks, fcConnUnitEventSeverity FcEventSeverity, fcConnUnitEventType INTEGER, fcConnUnitEventObject OBJECT IDENTIFIER, fcConnUnitEventDescr DisplayString } fcConnUnitEventUnitId OBJECT-TYPE SYNTAX OCTET STRING (SIZE (16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The connUnitId of the connectivity unit that contains this event table." ::= { fcConnUnitEventEntry 1 } -- XXX I think this object is not needed (see comment above). If it -- XXX is needed, please consider to define a TC for the type and -- XXX use it throughout the MIB. fcConnUnitEventIndex OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each connectivity unit has its own event buffer. As it wraps, it may write over previous events. This object is an index into the buffer. It is recommended that this table be read using 'getNext's to retrieve the initial table. The management application should read the event table at periodic intervals and then determine if any new entries were added by comparing the last known index value with the current highest index value. The management application should then update its copy of the event table. If the read interval is too long, it is possible that there may be events that may not be contained in the agent's internal event buffer. For example, an agent may read events 50-75. At the next read interval, connUnitEventCurrID is 189. If the management app tries to read event index 76, and the agent's internal buffer is 100 entries max, event index 76 will no longer be available. The index value is an incrementing integer starting from one every time there is a table reset. On table reset, all contents are emptied and all indeces are set to zero. When an event is added to the table, the event is assigned the next higher integer value than the last item entered into the table. If the index value reaches its maximum value, the next item entered will cause the index value to roll over and start at one again." ::= { fcConnUnitEventEntry 2 } -- XXX The ranges between fcConnUnitEventIndex and fcConnUnitNumEvents -- XXX should be aligned. fcConnUnitEventDateAndTime OBJECT-TYPE SYNTAX DisplayString (SIZE (15)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is the real time when the event occurred. It has the following format. DDMMYYYY HHMMSS DD=day number MM=month number YYYY=year number HH=hour number MM=minute number SS=seconds number If not applicable, return a NULL string." ::= { fcConnUnitEventEntry 3 } -- XXX Do not invent your own data and time format. Use DateAndTime -- XXX from SNMPv2-TC (RFC 2579) instead. Define precisely what you -- XXX return in case the date is unknown. fcConnUnitEventTimeStamp OBJECT-TYPE SYNTAX TimeTicks MAX-ACCESS read-only STATUS current DESCRIPTION "This is the sysUpTime timestamp when the event occurred." ::= { fcConnUnitEventEntry 4 } -- XXX This should use TimeStamp from SNMPv2-TC (RFC 2579). Is there -- XXX a special value which is reported in case sysUpTime is not -- XXX known? fcConnUnitEventSeverity OBJECT-TYPE SYNTAX FcEventSeverity MAX-ACCESS read-only STATUS current DESCRIPTION "The event severity level." ::= { fcConnUnitEventEntry 5 } fcConnUnitEventType OBJECT-TYPE SYNTAX INTEGER { unknown(1), other(2), status(3), configuration(4), topology(5) } MAX-ACCESS read-only STATUS current DESCRIPTION "The type of this event." ::= { fcConnUnitEventEntry 6 } -- XXX The enumerated values should be explained in the DESCRIPTION -- XXX clause. What is the difference between unknown(1) and other(2)? fcConnUnitEventObject OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "This is used with the fcConnUnitEventType to identify which object the event refers to. It can be the OID of a connectivity unit or of another object like fcConnUnitPortStatus." ::= { fcConnUnitEventEntry 7 } -- XXX I do not understand how this is supposed to work. What exactly -- XXX does this object contain for the various event types? -- XXX More fundamental question: Why can you not simply use the -- XXX NOTIFICATION-LOG-MIB ? -- XXX Please do not reinvent the wheel. Mayby just defining a few -- XXX suitable notifications does the whole job? fcConnUnitEventDescr OBJECT-TYPE SYNTAX DisplayString MAX-ACCESS read-only STATUS current DESCRIPTION "The description of the event." ::= { fcConnUnitEventEntry 8 } -- XXX This should probably be an SnmpAdminString for -- XXX internationalization. -- The link table is intended to organize and communicate -- any information the agent possesses -- which would assist a management application -- to discover the CONNECTIVITY UNITS in the -- framework and the TOPOLOGY of their interconnect. -- That is, the goal is to assist the management -- application not only to LIST the elements of the framework, -- but to MAP them. -- With this goal, the agent SHOULD include -- as much as it possesses about any links -- from its own connectivity units to others, -- including links among its own units. -- An agent SHOULD include partial information -- about links if it is not able to fully -- define them in accord with the following structure; -- however, the information MUST include either -- a nonzero fcConnUnitNodeId- or a nonzero fcConnUnitPortWwn- -- for each end of the link. -- If the agent is able to discover links -- which do not directly attach to members of its agency -- and its discovery algorithm gives some assurance -- the links are recently valid, it MAY include these links. -- Link information entered by administrative action -- MAY be included even if not validated directly -- if the link has at least one endpoint in this agency, -- but SHOULD NOT be included otherwise. -- A connectivity unit should fill the table in as best it can. -- One of the methods to fill this in would be to use the RNID -- ELS (ANSI document 99-422v0). This allows one to query a -- port for the information needed for the link table. -- This table is accessed either directly if the management -- software has an index value or via GetNexts. The value of -- the indexes are not required to be contiguous. Each entry -- created in this table will be assigned an index. This -- relationship is kept persistent until the entry is removed -- from the table or the system is reset. The total number of -- entries are defined by the size of the table -- For an entry to be considered to be valid, both the X (local) -- and the Y (remote) need to have one valid value. -- XXX This is all very fine but should not be stated in a comment. -- XXX Comments are subject to be removed by MIB processors. All -- XXX semantics should therefore be stated in description clauses. fcConnUnitLinkTable OBJECT-TYPE SYNTAX SEQUENCE OF FcConnUnitLinkEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of links known to this agent from this connectivity unit to other connectivity units." ::= { fcMgmtConfig 8 } fcConnUnitLinkEntry OBJECT-TYPE SYNTAX FcConnUnitLinkEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing a particular link to another connectivity unit." INDEX { fcConnUnitLinkUnitId, fcConnUnitLinkIndex } ::= { fcConnUnitLinkTable 1 } -- XXX Should the first INDEX component not be fcConnUnitId? FcConnUnitLinkEntry ::= SEQUENCE { fcConnUnitLinkUnitId OCTET STRING, fcConnUnitLinkIndex Integer32, fcConnUnitLinkNodeIdX OCTET STRING, fcConnUnitLinkPortNumberX Integer32, fcConnUnitLinkPortWwnX OCTET STRING, fcConnUnitLinkNodeIdY OCTET STRING, fcConnUnitLinkPortNumberY Integer32, fcConnUnitLinkPortWwnY OCTET STRING, fcConnUnitLinkAgentAddressY OCTET STRING, fcConnUnitLinkAgentAddressTypeY Integer32, fcConnUnitLinkAgentPortY Integer32, fcConnUnitLinkUnitTypeY FcUnitType, fcConnUnitLinkConnIdY OCTET STRING } fcConnUnitLinkUnitId OBJECT-TYPE SYNTAX OCTET STRING (SIZE (16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The connectivity unit that contains this link table." ::= { fcConnUnitLinkEntry 1 } fcConnUnitLinkIndex OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "This value is used to create a unique value for each entry in the link table with the same fcConnUnitLinkUnitId. The value can only be reused if it is not currently in use and the value is the next candidate to be used. This value is allowed to wrap at the highest value represented by the number of bits. This value is reset to zero when the system is Reset and the first value to be used is one." ::= { fcConnUnitLinkEntry 2 } -- XXX So why is 0 included in the range if the first value to be used -- XXX is 1?? fcConnUnitLinkNodeIdX OBJECT-TYPE SYNTAX OCTET STRING (SIZE(64)) MAX-ACCESS read-only STATUS current DESCRIPTION "The node WWN of the unit at one end of the link. If the node WWN is unknown and the node is a connectivity unit in the responding agent then the value of this object MUST BE equal to its fcConnUnitID." ::= { fcConnUnitLinkEntry 3 } -- XXX I am lost here. What is a WWN? fcConnUnitGlobalId says it is -- XXX 16 bytes long. This object says it is 64 bytes long. And the -- XXX fcConnUnitPortWwn object uses FcNameId which says it has a -- XXX size of 8 bytes. This needs to be cleaned up. I strongly -- XXX suggest to introduce TCs for these things. (And also consider -- XXX to import things from the FIBRE-CHANNEL-FE-MIB or to define -- XXX a common TC MIB for these things. -- XXX I think the descriptor should be clearer. What about -- XXX fcConnUnitLinkSrcNodeWwn? fcConnUnitLinkPortNumberX OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The port number on the unit specified by fcConnUnitLinkNodeIdX if known, otherwise -1. If the value is nonnegative then it will be equal to connUnitPortPhysicalNumber." ::= { fcConnUnitLinkEntry 4 } -- XXX Does this mean the range is (-1 | 1..2147483647)? -- XXX This refers to connUnitPortPhysicalNumber which was deprecated -- XXX and thus removed from this revision. This needs to get resolved. -- XXX Why is this not the same as fcConnUnitPortIndex? -- XXX I think the descriptor should be clearer. What about -- XXX fcConnUnitLinkSrcPortNumber? fcConnUnitLinkPortWwnX OBJECT-TYPE SYNTAX OCTET STRING (SIZE(16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The port WWN of the unit specified by fcConnUnitLinkNodeIdX if known, otherwise 16 octets of binary 0." ::= { fcConnUnitLinkEntry 5 } -- XXX Please use TCs for the various WWN's (see previous comments). -- XXX I think the descriptor should be clearer. What about -- XXX fcConnUnitLinkSrcPortWwn? fcConnUnitLinkNodeIdY OBJECT-TYPE SYNTAX OCTET STRING (SIZE(64)) MAX-ACCESS read-only STATUS current DESCRIPTION "The node WWN of the unit at the other end of the link. If the node WWN is unknown and the node is a connectivity unit in the responding SNMP agency then the value of this object MUST BE equal to its fcConnUnitID." ::= { fcConnUnitLinkEntry 6 } -- XXX Please use a TC for node WWNs (see comments above). -- XXX I think the descriptor should be clearer. What about -- XXX fcConnUnitLinkDstNodeWwn? fcConnUnitLinkPortNumberY OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The port number on the unit specified by fcConnUnitLinkNodeIdY if known, otherwise -1. If the value is nonnegative then it will be equal to connUnitPortPhysicalNumber." ::= { fcConnUnitLinkEntry 7 } -- XXX Does this mean the range is (-1 | 1..2147483647)? -- XXX This refers to connUnitPortPhysicalNumber which was deprecated -- XXX and thus removed from this revision. This needs to get resolved. -- XXX Why is this not the same as fcConnUnitPortIndex? -- XXX I think the descriptor should be clearer. What about -- XXX fcConnUnitLinkDstPortNumber? fcConnUnitLinkPortWwnY OBJECT-TYPE SYNTAX OCTET STRING (SIZE(16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The port WWN on the unit specified by fcConnUnitLinkNodeIdY if known, otherwise 16 octets of binary 0." ::= { fcConnUnitLinkEntry 8 } -- XXX Please use TCs for the various WWN's (see previous comments). -- XXX I think the descriptor should be clearer. What about -- XXX fcConnUnitLinkDstPortWwn? fcConnUnitLinkAgentAddressY OBJECT-TYPE SYNTAX OCTET STRING (SIZE(16)) MAX-ACCESS read-only STATUS current DESCRIPTION "The address of an FCMGMT MIB agent for the node identified by connUnitLinkNodeIdY, if known; otherwise 16 octets of binary 0." ::= { fcConnUnitLinkEntry 9 } -- XXX Why 16 octets? Why do you not use a more generic mechanism? -- XXX Is this the transport address of the SNMP agent? fcConnUnitLinkAgentAddressTypeY OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "If connUnitLinkAgentAddressY is nonzero, it is a protocol address. ConnUnitLinkAgentAddressTypeY is the the 'address family number' assigned by IANA to identify the address format (eg, 1 is Ipv4, 2 is Ipv6)." ::= { fcConnUnitLinkEntry 10 } -- XXX What is the requirement here? You should use a generic transport -- XXX address mechanism (e.g. TAddress from SNMPv2-TC (RFC 2579) or -- XXX what comes out of the IPv6 MIB design team effort. Note that -- XXX there are already IANA maintained TC's for IANA address families. -- XXX What is the semantic of a negative address family number? fcConnUnitLinkAgentPortY OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The IP port number for the agent. This is provided in case the agent is at a non-standard SNMP port." ::= { fcConnUnitLinkEntry 11 } -- XXX A general transport addressing mechanism will take care of -- XXX that. Negative port numbers do not make much sense to me. fcConnUnitLinkUnitTypeY OBJECT-TYPE SYNTAX FcUnitType MAX-ACCESS read-only STATUS current DESCRIPTION "Type of the FC connectivity unit." ::= { fcConnUnitLinkEntry 12 } fcConnUnitLinkConnIdY OBJECT-TYPE SYNTAX OCTET STRING (SIZE(3)) MAX-ACCESS read-only STATUS current DESCRIPTION "This is the Fibre Channel ID of this port. If the connectivity unit is a switch, this is expected to be a Big Endian value of 24 bits. If this is loop, then it is the ALPA that is connected. If this is an eport, then it will only contain the domain ID. If not any of those, unknown or cascaded loop, return all bits set to 1." ::= { fcConnUnitLinkEntry 13 } -- XXX Please introduce a TC for this data type since it is used -- XXX in multiple places. I do not fully understand the description. -- XXX What is meant by "this port"? ------------------------------------------------------------------------------ -- The following is a set of statistics tables. There is one for each port -- type class. Port types are aggregated into a port type class, such as all -- the fabric port types. There is one and only one statistics table for each -- individual port. For all objects in statistics tables, if the object is not -- supported by the conn unit then the high order bit is set to 1 with all -- other bits set to zero. The high order bit is reserved to indicate is the -- object if supported or not. All objects start at a value of zero at hardware -- initialization and continue incrementing till end of 63 bits and then wrap -- to zero. -- XXX Comments are subject to be removed by MIB processors. All -- XXX semantics should therefore be stated in description clauses. -- XXX The semantics with the high-order bit are definitely very very -- XXX very strange. In the SNMP world, there is a simple rule: Objects -- XXX that do not exist do not exist. Also, hardware initialization -- XXX may have nothing to do with the initialization of the management -- XXX software. I very strongly suggest to use normal counters rather -- XXX then inventing something new. -- Hub Port Statistics fcConnUnitPortStatHubTable OBJECT-TYPE SYNTAX SEQUENCE OF FcConnUnitPortStatHubEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of statistics for the hub port type." ::= { fcMgmtStatistics 1 } -- XXX Should probably explain for which port types this table -- XXX is populated. fcConnUnitPortStatHubEntry OBJECT-TYPE SYNTAX FcConnUnitPortStatHubEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing hub port statistics." INDEX { fcConnUnitPortStatHubUnitId, fcConnUnitPortStatHubIndex } ::= { fcConnUnitPortStatHubTable 1 } -- XXX Should the first INDEX component not be fcConnUnitId? -- XXX Should the second INDEX component not be fcConnUnitPortIndex? FcConnUnitPortStatHubEntry ::= SEQUENCE { fcConnUnitPortStatHubUnitId OCTET STRING, fcConnUnitPortStatHubIndex Integer32, fcConnUnitPortStatHubErrors OCTET STRING, fcConnUnitPortStatHubTxFrames OCTET STRING, fcConnUnitPortStatHubRxFrames OCTET STRING, fcConnUnitPortStatHubTxOctets OCTET STRING, fcConnUnitPortStatHubRxOctets OCTET STRING } fcConnUnitPortStatHubUnitId OBJECT-TYPE SYNTAX OCTET STRING (SIZE (16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The fcConnUnitId of the connectivity unit that contains this port stat table." ::= { fcConnUnitPortStatHubEntry 1 } -- XXX I think this object is not needed (see comment above). If it -- XXX is needed, please consider to define a TC for the type and -- XXX use it throughout the MIB. fcConnUnitPortStatHubIndex OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value among all entrys in this table, between 0 and fcConnUnitNumPort." ::= { fcConnUnitPortStatHubEntry 2 } -- XXX I think this object is not needed (see comment above). If it -- XXX is needed, please consider to define a TC for the type and -- XXX use it throughout the MIB. fcConnUnitPortStatHubErrors OBJECT-TYPE SYNTAX OCTET STRING (SIZE (8)) MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the errors that have occured on this port." ::= { fcConnUnitPortStatHubEntry 3 } -- XXX I think this should be a counter. fcConnUnitPortStatHubTxFrames OBJECT-TYPE SYNTAX OCTET STRING (SIZE (8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames that have been transmitted by this port." ::= { fcConnUnitPortStatHubEntry 4 } -- XXX I think this should be a counter. fcConnUnitPortStatHubRxFrames OBJECT-TYPE SYNTAX OCTET STRING (SIZE (8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames that have been received by this port." ::= { fcConnUnitPortStatHubEntry 5 } -- XXX I think this should be a counter. fcConnUnitPortStatHubTxOctets OBJECT-TYPE SYNTAX OCTET STRING (SIZE (8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets that have been transmitted by this port." ::= { fcConnUnitPortStatHubEntry 6 } -- XXX I think this should be a counter. fcConnUnitPortStatHubRxOctets OBJECT-TYPE SYNTAX OCTET STRING (SIZE (8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets that have been received by this port." ::= { fcConnUnitPortStatHubEntry 7 } -- XXX I think this should be a counter. -- Fabric Port Statistics fcConnUnitPortStatFabricTable OBJECT-TYPE SYNTAX SEQUENCE OF FcConnUnitPortStatFabricEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of statistics for the fabric port types." ::= { fcMgmtStatistics 2 } fcConnUnitPortStatFabricEntry OBJECT-TYPE SYNTAX FcConnUnitPortStatFabricEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing fabric port statistics." INDEX { fcConnUnitPortStatFabricUnitId, fcConnUnitPortStatFabricIndex } ::= { fcConnUnitPortStatFabricTable 1 } -- XXX Should the first INDEX component not be fcConnUnitId? -- XXX Should the second INDEX component not be fcConnUnitPortIndex? FcConnUnitPortStatFabricEntry ::= SEQUENCE { fcConnUnitPortStatFabricUnitId OCTET STRING, fcConnUnitPortStatFabricIndex Integer32, fcConnUnitPortStatFabricErrors OCTET STRING, fcConnUnitPortStatFabricTxFrames OCTET STRING, fcConnUnitPortStatFabricRxFrames OCTET STRING, fcConnUnitPortStatFabricTxOctets OCTET STRING, fcConnUnitPortStatFabricRxOctets OCTET STRING } fcConnUnitPortStatFabricUnitId OBJECT-TYPE SYNTAX OCTET STRING (SIZE (16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The fcConnUnitId of the connectivity unit that contains this port stat table." ::= { fcConnUnitPortStatFabricEntry 1 } -- XXX I think this object is not needed (see comment above). If it -- XXX is needed, please consider to define a TC for the type and -- XXX use it throughout the MIB. fcConnUnitPortStatFabricIndex OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value among all entrys in this table, between 0 and fcConnUnitNumPort." ::= { fcConnUnitPortStatFabricEntry 2 } -- XXX I think this object is not needed (see comment above). If it -- XXX is needed, please consider to define a TC for the type and -- XXX use it throughout the MIB. fcConnUnitPortStatFabricErrors OBJECT-TYPE SYNTAX OCTET STRING (SIZE (8)) MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the errors that have occured on this port." ::= { fcConnUnitPortStatFabricEntry 3 } -- XXX I think this should be a counter. fcConnUnitPortStatFabricTxFrames OBJECT-TYPE SYNTAX OCTET STRING (SIZE (8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames that have been transmitted by this port." ::= { fcConnUnitPortStatFabricEntry 4 } -- XXX I think this should be a counter. fcConnUnitPortStatFabricRxFrames OBJECT-TYPE SYNTAX OCTET STRING (SIZE (8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of frames that have been received by this port." ::= { fcConnUnitPortStatFabricEntry 5 } -- XXX I think this should be a counter. fcConnUnitPortStatFabricTxOctets OBJECT-TYPE SYNTAX OCTET STRING (SIZE (8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets that have been transmitted by this port." ::= { fcConnUnitPortStatFabricEntry 6 } -- XXX I think this should be a counter. fcConnUnitPortStatFabricRxOctets OBJECT-TYPE SYNTAX OCTET STRING (SIZE (8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of octets that have been received by this port." ::= { fcConnUnitPortStatFabricEntry 7 } -- XXX I think this should be a counter. -- SCSI Port Statistics fcConnUnitPortStatSCSITable OBJECT-TYPE SYNTAX SEQUENCE OF FcConnUnitPortStatSCSIEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of statistics for the SCSI port type." ::= { fcMgmtStatistics 3 } fcConnUnitPortStatSCSIEntry OBJECT-TYPE SYNTAX FcConnUnitPortStatSCSIEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing SCSI port statistics." INDEX { fcConnUnitPortStatSCSIUnitId, fcConnUnitPortStatSCSIIndex } ::= { fcConnUnitPortStatSCSITable 1 } -- XXX Should the first INDEX component not be fcConnUnitId? -- XXX Should the second INDEX component not be fcConnUnitPortIndex? FcConnUnitPortStatSCSIEntry ::= SEQUENCE { fcConnUnitPortStatSCSIUnitId OCTET STRING, fcConnUnitPortStatSCSIIndex Integer32, fcConnUnitPortStatSCSIErrors OCTET STRING, fcConnUnitPortStatSCSITxIOs OCTET STRING, fcConnUnitPortStatSCSIRxIOs OCTET STRING, fcConnUnitPortStatSCSITxBytes OCTET STRING, fcConnUnitPortStatSCSIRxBytes OCTET STRING } fcConnUnitPortStatSCSIUnitId OBJECT-TYPE SYNTAX OCTET STRING (SIZE (16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The connUnitId of the connectivity unit that contains this port stat table." ::= { fcConnUnitPortStatSCSIEntry 1 } -- XXX I think this object is not needed (see comment above). If it -- XXX is needed, please consider to define a TC for the type and -- XXX use it throughout the MIB. fcConnUnitPortStatSCSIIndex OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value among all entrys in this table, between 0 and fcConnUnitNumPort." ::= { fcConnUnitPortStatSCSIEntry 2 } -- XXX I think this object is not needed (see comment above). If it -- XXX is needed, please consider to define a TC for the type and -- XXX use it throughout the MIB. fcConnUnitPortStatSCSIErrors OBJECT-TYPE SYNTAX OCTET STRING (SIZE (8)) MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the errors that have occured on this port." ::= { fcConnUnitPortStatSCSIEntry 3 } -- XXX I think this should be a counter. fcConnUnitPortStatSCSITxIOs OBJECT-TYPE SYNTAX OCTET STRING (SIZE (8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of I/Os that have been transmitted by this port." ::= { fcConnUnitPortStatSCSIEntry 4 } -- XXX I think this should be a counter. fcConnUnitPortStatSCSIRxIOs OBJECT-TYPE SYNTAX OCTET STRING (SIZE (8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of I/Os that have been received by this port." ::= { fcConnUnitPortStatSCSIEntry 5 } -- XXX I think this should be a counter. fcConnUnitPortStatSCSITxBytes OBJECT-TYPE SYNTAX OCTET STRING (SIZE (8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of bytes that have been transmitted by this port." ::= { fcConnUnitPortStatSCSIEntry 6 } -- XXX I think this should be a counter. fcConnUnitPortStatSCSIRxBytes OBJECT-TYPE SYNTAX OCTET STRING (SIZE (8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of bytes that have been received by this port." ::= { fcConnUnitPortStatSCSIEntry 7 } -- XXX I think this should be a counter. -- LAN/WAN Port Statistics fcConnUnitPortStatLANTable OBJECT-TYPE SYNTAX SEQUENCE OF FcConnUnitPortStatLANEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of statistics for the LAN/WAN port type." ::= { fcMgmtStatistics 4 } fcConnUnitPortStatLANEntry OBJECT-TYPE SYNTAX FcConnUnitPortStatLANEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry describing LAN/WAN port statistics." INDEX { fcConnUnitPortStatLANUnitId, fcConnUnitPortStatLANIndex } ::= { fcConnUnitPortStatLANTable 1 } -- XXX Should the first INDEX component not be fcConnUnitId? -- XXX Should the second INDEX component not be fcConnUnitPortIndex? FcConnUnitPortStatLANEntry ::= SEQUENCE { fcConnUnitPortStatLANUnitId OCTET STRING, fcConnUnitPortStatLANIndex Integer32, fcConnUnitPortStatLANErrors OCTET STRING, fcConnUnitPortStatLANTxPackets OCTET STRING, fcConnUnitPortStatLANRxPackets OCTET STRING, fcConnUnitPortStatLANTxBytes OCTET STRING, fcConnUnitPortStatLANRxBytes OCTET STRING } fcConnUnitPortStatLANUnitId OBJECT-TYPE SYNTAX OCTET STRING (SIZE (16)) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The fcConnUnitId of the connectivity unit that contains this port stat table." ::= { fcConnUnitPortStatLANEntry 1 } -- XXX I think this object is not needed (see comment above). If it -- XXX is needed, please consider to define a TC for the type and -- XXX use it throughout the MIB. fcConnUnitPortStatLANIndex OBJECT-TYPE SYNTAX Integer32 (0..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "A unique value among all entrys in this table, between 0 and fcConnUnitNumPort." ::= { fcConnUnitPortStatLANEntry 2 } -- XXX I think this object is not needed (see comment above). If it -- XXX is needed, please consider to define a TC for the type and -- XXX use it throughout the MIB. fcConnUnitPortStatLANErrors OBJECT-TYPE SYNTAX OCTET STRING (SIZE (8)) MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the errors that have occured on this port." ::= { fcConnUnitPortStatLANEntry 3 } -- XXX I think this should be a counter. fcConnUnitPortStatLANTxPackets OBJECT-TYPE SYNTAX OCTET STRING (SIZE (8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets that have been transmitted by this port." ::= { fcConnUnitPortStatLANEntry 4 } -- XXX I think this should be a counter. fcConnUnitPortStatLANRxPackets OBJECT-TYPE SYNTAX OCTET STRING (SIZE (8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of packets that have been received by this port." ::= { fcConnUnitPortStatLANEntry 5 } -- XXX I think this should be a counter. fcConnUnitPortStatLANTxBytes OBJECT-TYPE SYNTAX OCTET STRING (SIZE (8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of bytes that have been transmitted by this port." ::= { fcConnUnitPortStatLANEntry 6 } -- XXX I think this should be a counter. fcConnUnitPortStatLANRxBytes OBJECT-TYPE SYNTAX OCTET STRING (SIZE (8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The number of bytes that have been received by this port." ::= { fcConnUnitPortStatLANEntry 7 } -- XXX I think this should be a counter. -- SNMP trap registration group -- XXX The whoe fcMgmtNotifyFilter group below is very questionable. -- XXX Despite technical shortcomings (unflexible addressing which -- XXX only works with IPv4, no RowStatus (RFC 2579) where there -- XXX should be a RowStatus), I have serious concerns that you -- XXX redo work which has been done in the SNMP-NOTIFICATION-MIB -- XXX (RFC 2573). Sure, I see that you want to filter on severity. -- XXX But this should be doable by extending what has already been -- XXX defined rather than reinventing the wheel again. -- XXX There are also the typical problems like Integer32 types -- XXX where you probably do not want/need negative numbers and -- XXX so on. I did not comment the stuff below in detail because -- XXX I think it should go away and I want to save some of my time. trapMaxClients OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of SNMP trap recipients supported by the connectivity unit." ::= { fcMgmtNotifyFilter 1 } trapClientCount OBJECT-TYPE SYNTAX Integer32 MAX-ACCESS read-only STATUS current DESCRIPTION "The current number of rows in the trap table." ::= { fcMgmtNotifyFilter 2 } trapRegTable OBJECT-TYPE SYNTAX SEQUENCE OF TrapRegEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A table containing a row for each IP address/port number that traps will be sent to." ::= { fcMgmtNotifyFilter 3 } trapRegEntry OBJECT-TYPE SYNTAX TrapRegEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Ip/Port pair for a specific client." INDEX { trapRegIpAddress, trapRegPort } ::= { trapRegTable 1 } TrapRegEntry ::= SEQUENCE { trapRegIpAddress IpAddress, trapRegPort Integer32, trapRegFilter FcEventSeverity, trapRegRowState INTEGER } trapRegIpAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The Ip address of a client registered for traps." ::= { trapRegEntry 1 } trapRegPort OBJECT-TYPE SYNTAX Integer32 (1..2147483647) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The UDP port to send traps to for this host. Normally this would be the standard trap port (162). This object is an index and must be specified to create a row in this table." ::= { trapRegEntry 2 } trapRegFilter OBJECT-TYPE SYNTAX FcEventSeverity MAX-ACCESS read-write STATUS current DESCRIPTION "This value defines the trap severity filter for this trap host. The connUnit will send traps to this host that have a severity level less than or equal to this value. The default value of this object is 'warning'." ::= { trapRegEntry 3} trapRegRowState OBJECT-TYPE SYNTAX INTEGER { rowDestroy(1), -- Remove row from table. rowInactive(2), -- Row exists, but TRAPs disabled rowActive(3) -- Row exists and is enabled for -- sending traps } MAX-ACCESS read-write STATUS current DESCRIPTION "Specifies the state of the row. rowDestroy READ: Can never happen. WRITE: Remove this row from the table. rowInactive READ: Indicates that this row does exist, but that traps are not enabled to be sent to the target. WRITE: If the row does not exist, and the agent allows writes to the trap table, then a new row is created. The values of the optional columns will be set to default values. Traps are not enabled to be sent to the target. If the row already existed, then traps are disabled from being sent to the target. rowActive READ: Indicates that this row exists, and that traps are enabled to be sent to the target. WRITE: If the row does not exist, and the agent allows writes to the trap table, then a new row is created. The values of the optional columns will be set to default values. Traps are enabled to be sent to the target. If the row already exists, then traps are enabled to be sent to the target. A value of rowActive or rowInactive must be specified to create a row in the table." ::= { trapRegEntry 4} -- XXX End of ugly trap forwarding mechanism. See the lengthy comment -- XXX above why I consider this ugly. -- Notifications fcConnUnitStatusChange NOTIFICATION-TYPE OBJECTS { fcConnUnitStatus, fcConnUnitState } STATUS current DESCRIPTION "The overall status of the connectivity unit has changed. Recommended severity level (for filtering): alert" ::= { fcMgmtNotifications 1 } -- XXX Should the severity be a parameter of the notification? fcConnUnitDeleted NOTIFICATION-TYPE OBJECTS { fcConnUnitId } STATUS current DESCRIPTION "A connectivity unit has been deleted from this agent. Recommended severity level (for filtering): warning" ::= { fcMgmtNotifications 2 } -- XXX You may want to report something more useful than fcConnUnitId -- XXX since this valued can be infered from whatever column you -- XXX return. (Note that a manager can not go to the table to -- XXX retrieve any further details because the table entry will be -- XXX gone when the manager processes the notification. -- XXX Should the severity be a parameter of the notification? fcConnUnitEvent NOTIFICATION-TYPE OBJECTS { fcConnUnitEventType, fcConnUnitEventObject, fcConnUnitEventDescr } STATUS current DESCRIPTION "An event has been generated by the connectivity unit. Recommended severity level (for filtering): info" ::= { fcMgmtNotifications 3 } -- XXX Should the severity be a parameter of the notification? -- XXX Why do you not model the events as notifications themself? fcConnUnitSensorStatusChange NOTIFICATION-TYPE OBJECTS { fcConnUnitSensorStatus } STATUS current DESCRIPTION "The overall status of the connectivity unit has changed. Recommended severity level (for filtering): alert" ::= { fcMgmtNotifications 4 } -- XXX Should the severity be a parameter of the notification? fcConnUnitPortStatusChange NOTIFICATION-TYPE OBJECTS { fcConnUnitPortStatus, fcConnUnitPortState } STATUS current DESCRIPTION "The overall status of a port of a connectivity unit has changed. Recommended severity level (for filtering): alert" ::= { fcMgmtNotifications 5 } -- XXX object group and notification group definitions need to go here. -- XXX module compliance defintions need to go here. END -- Local Variables: -- compile-command: "smilint -c ./smilint.cfg ./FIBRE-CHANNEL-MGMT-MIB" -- End: From owner-ipfc@standards.gadzoox.com Mon Apr 17 14:08:30 2000 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07032 for ; Mon, 17 Apr 2000 14:08:29 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id KAA14853 for ipfc-list; Mon, 17 Apr 2000 10:54:59 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from gordan.pl.gadzoox.com (gordan.pl.gadzoox.com [209.95.220.16]) by standards.gadzoox.com (8.8.7/8.8.7) with ESMTP id KAA14850 for ; Mon, 17 Apr 2000 10:54:58 -0700 Received: by gordan.pl.gadzoox.com with Internet Mail Service (5.5.2650.21) id <2JS0KK9F>; Mon, 17 Apr 2000 11:04:35 -0700 Message-ID: <312419998E3CD211A52900A0C991A47A225681@gordan.pl.gadzoox.com> From: Murali Rajagopal To: "'ipfc@standards.gadzoox.com'" Subject: Call for RFC 2625 Interoperability Testing Participation Date: Mon, 17 Apr 2000 11:04:34 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Call for RFC 2625 Interoperability Testing Participation The place and Testing date for IPFC RFC 2625 has been advanced to coincide with the Group Test Period event at UNH. GTP is scheduled for week of June 12. The information on this can be found at http://www.iol.unh.edu/fciatesting/. You may call email Barry Reinhold for details on the IPFC Test Suite at bbr@unh.edu. Please email your interest to participate on the ipfc@standards.gadzoox.com mail list. Regards, Murali Rajagopal From owner-ipfc@standards.gadzoox.com Thu Apr 20 14:49:20 2000 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18559 for ; Thu, 20 Apr 2000 14:49:20 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id LAA16393 for ipfc-list; Thu, 20 Apr 2000 11:35:34 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from gordan.pl.gadzoox.com (gordan.pl.gadzoox.com [209.95.220.16]) by standards.gadzoox.com (8.8.7/8.8.7) with ESMTP id LAA16390 for ; Thu, 20 Apr 2000 11:35:32 -0700 Received: by gordan.pl.gadzoox.com with Internet Mail Service (5.5.2650.21) id <2JS0KMR0>; Thu, 20 Apr 2000 11:45:10 -0700 Message-ID: <312419998E3CD211A52900A0C991A47A225699@gordan.pl.gadzoox.com> From: Murali Rajagopal To: "'ipfc@standards.gadzoox.com'" Subject: RFC 2526 Interoperability Testing Date: Thu, 20 Apr 2000 11:45:09 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk -----Original Message----- From: Barry Reinhold [mailto:bbr@unh.edu] Sent: Thursday, April 20, 2000 11:43 AM To: Jon.Infante@emulex.com Cc: Murali Rajagopal; cwl@iol.unh.edu Subject: Error testing Jon, Well, no I wasn't thinking that hard...but we could try some things. Here is my first set of ideas: 1. Technology level - recovery of a TCP or UDP session when there is: LIP on a loop removal/insertion on both a loop and a fabric (with change of AL_PA?) movement between ports on a fabric (FRAP) 2. Frame level - Selective destruction of frames by jamming the CRC. We would have to figure out a way to identify TCP or UDP frames in a particular session (port number) and blow away a percentage of them. This might be a bit involved to set up and it would mostly exercise the TCP stack vs. anything Fibre Channel. 3. Protocol level - Duplicate IP address that arrives before the original on a removal/insertion process I don't have a problem with doing some stress testing/performance measures with ttcp Other ideas? "Infante, Jon" wrote: > Barry, > > Besides running various applications (ping, NFS, FTP, DHCP) are you > going > to do any error testing? > > For example, switching ports on a Fabric between 2 IP NPorts to check > FARP interoperability. > > What about ttcp, or some other public domain test program, to test > performance between 2 IP NPorts. > > Jon Infante > Emulex > > > Murali Rajagopal wrote: > >> Call for RFC 2625 Interoperability Testing Participation >> >> The place and Testing date for IPFC RFC 2625 has been advanced to >> coincide >> with the Group Test Period event at UNH. >> GTP is scheduled for week of June 12. The information on this can be >> found >> at http://www.iol.unh.edu/fciatesting/. >> >> You may call email Barry Reinhold for details on the IPFC Test Suite >> at >> bbr@unh.edu. >> >> Please email your interest to participate on the >> ipfc@standards.gadzoox.com >> mail list. >> >> Regards, >> >> Murali Rajagopal > From owner-ipfc@standards.gadzoox.com Thu Apr 20 15:12:25 2000 Received: from standards.gadzoox.com (standards.gadzoox.com [216.52.31.24]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA19193 for ; Thu, 20 Apr 2000 15:12:24 -0400 (EDT) Received: (from majordom@localhost) by standards.gadzoox.com (8.8.7/8.8.7) id LAA16404 for ipfc-list; Thu, 20 Apr 2000 11:59:19 -0700 X-Authentication-Warning: standards.gadzoox.com: majordom set sender to owner-ipfc@standards.gadzoox.com using -f Received: from gordan.pl.gadzoox.com (gordan.pl.gadzoox.com [209.95.220.16]) by standards.gadzoox.com (8.8.7/8.8.7) with ESMTP id LAA16401 for ; Thu, 20 Apr 2000 11:59:18 -0700 Received: by gordan.pl.gadzoox.com with Internet Mail Service (5.5.2650.21) id <2JS0KMS3>; Thu, 20 Apr 2000 12:08:56 -0700 Message-ID: <312419998E3CD211A52900A0C991A47A22569D@gordan.pl.gadzoox.com> From: Murali Rajagopal To: "'ipfc@standards.gadzoox.com'" Subject: RFC 2625 Interoperability Registration Date: Thu, 20 Apr 2000 12:08:55 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipfc@standards.gadzoox.com Precedence: bulk Please Register at the following UNH site: http://www.iol.unh.edu. So far we have the following companies that have responded: QLOGIC EMULEX I will keep you posted on the registered companies periodically. -Regards, Murali