[imss] MIB doctor review part 2 (T11-FC-SP-TC-MIB): draft-ietf-imss-fc-fcsp-mib-00.txt

"WIJNEN, Bert \(Bert\)" <bwijnen@alcatel-lucent.com> Mon, 26 November 2007 17:09 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 1IwhSZ-0001Ny-KZ; Mon, 26 Nov 2007 12:09:27 -0500
Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1IwhSZ-0001Ne-1K for imss-confirm+ok@megatron.ietf.org; Mon, 26 Nov 2007 12:09:27 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IwhSY-0001NN-MG; Mon, 26 Nov 2007 12:09:26 -0500
Received: from ihemail4.lucent.com ([135.245.0.39]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IwhSY-0006ca-6j; Mon, 26 Nov 2007 12:09:26 -0500
Received: from ilexp02.ndc.lucent.com (h135-3-39-2.lucent.com [135.3.39.2]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id lAQH8kYg004790; Mon, 26 Nov 2007 11:09:18 -0600 (CST)
Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp02.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 11:08:59 -0600
Received: from DEEXC1U02.de.lucent.com ([135.248.187.29]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Nov 2007 18:08:55 +0100
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Mon, 26 Nov 2007 18:08:52 +0100
Message-ID: <D4D321F6118846429CD792F0B5AF471F7E5CED@DEEXC1U02.de.lucent.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: MIB doctor review part 2 (T11-FC-SP-TC-MIB): draft-ietf-imss-fc-fcsp-mib-00.txt
Thread-Index: AcgK0vLbbD32Q+kDSKqF52DDcvyXNQR1sm7QACzkDYACxRH+oAAEOUpwAevc29AABgTmMA==
From: "WIJNEN, Bert (Bert)" <bwijnen@alcatel-lucent.com>
To: imss@ietf.org
X-OriginalArrivalTime: 26 Nov 2007 17:08:55.0986 (UTC) FILETIME=[071BA120:01C8304F]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 25620135586de10c627e3628c432b04a
Subject: [imss] MIB doctor review part 2 (T11-FC-SP-TC-MIB): draft-ietf-imss-fc-fcsp-mib-00.txt
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

[bcc to MIB doctors]

Here are my comments/questions on the T11-FC-SP-TC-MIB module

1. I find it somewhat weird to see:

     t11FcTcMIB  MODULE-IDENTITY
        LAST-UPDATED  "200708130000Z"
        ORGANIZATION  "For the initial versions, T11.
                       For later versions, the IETF's IMSS Working
Group."

   The one version that gets formally published is the one in the
   upcoming RFC. At that time there are basically no "initial" versions
   other than the one in the RFC. 

2. looking at T11FcSpPolicyHashFormat and T11FcSpPolicyHashValue I
wonder
   if/how often the TCS will need to be updated? And when that is done,
    a. do we then want to create a new RFC or
    b. should this become an iana  maintained module? 

   If we need to create a new MIB module ourselves (option a), then
   we could be more specific this time by making the SYNTAX for
   T11FcSpPolicyHashValue as follows:

       SYNTAX        OCTET STRING (SIZE (20 | 32))

   because there are no other lengths possible given the currently
   specified/valid formats.

3. I am not sure if (how) it is wise to merge values from
   3 different tables in the FC-SP spec (tables 17/18, 48 and 52)
   into one Textual Convention for the code and one for CodeExp.
 
       T11FcSpAuthRejectReasonCode
       T11FcSpAuthRejReasonCodeExp

   In some cases, not all values are valid, are they? The set of
   reasons and Reason Explanations is different for the 3
   types of messages listed in the DESCRIPTION clause.

   Maybe it is OK, but I am somewhat worried.

4. T11FcSpPolicyNameType
   I find it very unfriendly that Internationalized names are not
   defined/allowed. But I do see that the base spec [FC-SP] does
   not allow it, so I guess we can only model the spec that T11
   has approved (or will approve).

5. Personal and subjective preference: I would rename

     T11FcSpAlphaNumNameOrNull

   into

     T11FcSpAlphaNumNameOrNone

   The "Null" often makes people think of 0 (zero).

6. As reported by the SYNTAX checkers, I would change the underlying
   SYNTAX for T11FcSpiIndex and T11FcSpPrecedence to be 

    SYNTAX   Unsigned32 (0..4294967295)

   instead of:

    SYNTAX   Unsigned32  -- the default range: (0..4294967295)

7. I wonder if it would be good (I think it would be) to add a
   REFERENCE clause to each of the Encryption and Authentication
   algorithms specified by the OBKECT-IDENTITIES.

Bert


_______________________________________________
imss mailing list
imss@ietf.org
https://www1.ietf.org/mailman/listinfo/imss