[imss] MIB doctor review for T11-FC-SP-AUTHENTICATION-MIB
"Bert Wijnen - IETF" <bertietf@bwijnen.net> Fri, 28 December 2007 15:29 UTC
Return-path: <imss-bounces@ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8H9H-0005HL-57; Fri, 28 Dec 2007 10:29:23 -0500
Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1J8H9G-0005HC-5Y for imss-confirm+ok@megatron.ietf.org; Fri, 28 Dec 2007 10:29:22 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8H9F-0005H4-GK for imss@ietf.org; Fri, 28 Dec 2007 10:29:21 -0500
Received: from relay.versatel.net ([62.250.3.110]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J8H9E-0006tm-RR for imss@ietf.org; Fri, 28 Dec 2007 10:29:21 -0500
Received: (qmail 74496 invoked from network); 28 Dec 2007 15:29:19 -0000
Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 28 Dec 2007 15:29:19 -0000
From: Bert Wijnen - IETF <bertietf@bwijnen.net>
To: imss@ietf.org
Date: Fri, 28 Dec 2007 16:29:27 +0100
Message-ID: <NIEJLKBACMDODCGLGOCNKEGNEEAA.bertietf@bwijnen.net>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0)
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
Importance: Normal
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Cc: Dan Romascanu <dromasca@avaya.com>, Keith McCloghrie <kzm@cisco.com>, Black_David <Black_David@emc.com>
Subject: [imss] MIB doctor review for T11-FC-SP-AUTHENTICATION-MIB
X-BeenThere: imss@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Internet and Management Support for Storage Working Group <imss.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/imss>, <mailto:imss-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:imss@ietf.org>
List-Help: <mailto:imss-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/imss>, <mailto:imss-request@ietf.org?subject=subscribe>
Errors-To: imss-bounces@ietf.org
This is a review of the module as extracted from the prelimenary draft-ietf-imss-fc-fcsp-mib-01.txt document - I see t11FcSpAuthenticationMIB MODULE-IDENTITY LAST-UPDATED "200702190000Z" ORGANIZATION "T11" I think that IOETF IMSS WG should be included as one of the ORGANIZATIONs that worked on this MIB module - This is just a nit: t11FcSpAuMIBIdentities OBJECT IDENTIFIER ::= { t11FcSpAuthenticationMIB 1 } t11FcSpAuMIBObjects OBJECT IDENTIFIER ::= { t11FcSpAuthenticationMIB 2 } t11FcSpAuMIBConformance OBJECT IDENTIFIER ::= { t11FcSpAuthenticationMIB 3 } t11FcSpAuMIBNotifications OBJECT IDENTIFIER ::= { t11FcSpAuthenticationMIB 0 } Most MIB modules have MIBObjects as 1 and Conformace as 2. This MIB module has additional a set of Identities. SO I personally would do: t11FcSpAuMIBNotifications OBJECT IDENTIFIER ::= { t11FcSpAuthenticationMIB 0 } t11FcSpAuMIBObjects OBJECT IDENTIFIER ::= { t11FcSpAuthenticationMIB 1 } t11FcSpAuMIBConformance OBJECT IDENTIFIER ::= { t11FcSpAuthenticationMIB 2 } t11FcSpAuMIBIdentities OBJECT IDENTIFIER ::= { t11FcSpAuthenticationMIB 3 } But and OID is just an OID, so this is not a flaw. Just a consistency thing that I personally would try to follow. - It is unclear to me why t11FcSpAuEntityName OBJECT-TYPE SYNTAX FcNameIdOrZero (SIZE (8)) Has a fixed size of 8. I think I would have expected (8 | 16) You reference "fcmInstanceWwn & fcmSwitchWWN, 'Fibre Channel Management MIB', RFC 4044, May 2005." And fcmInstanceWwn and fcmSwitchWWN there (as far as I can tell also allow 8 or 16. In fact they even allows for zero, but I can see you do (or may) not want to allow that here. - So for my undestanding, when I see this: t11FcSpAuIfStatTimeouts OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The number of FC-SP Authentication Protocol messages sent by the particular entity on the particular Fabric on the particular interface, for which no response was received within a timeout period. This counter has no discontinuities other than those which all Counter32's have when sysUpTime=0." Then I understand from that that the instrumentation code for this MIB module will save these values in persistent storage, and so when it restarts it still knows the values? Or are you saying that the "master-agent" and "t11-subagent" are always a monolithic entity and will die/restart together? Bert Wijnen _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss
- [imss] MIB doctor review for T11-FC-SP-AUTHENTICA… Bert Wijnen - IETF
- [imss] FW: MIB doctor review for T11-FC-SP-AUTHEN… Black_David
- [imss] Re: MIB doctor review for T11-FC-SP-AUTHEN… Keith McCloghrie
- [imss] RE: MIB doctor review for T11-FC-SP-AUTHEN… Bert Wijnen - IETF