[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
- [imss] MIB doctor review part 2 (T11-FC-SP-TC-MIB… WIJNEN, Bert (Bert)