[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