[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)