RE: [imss] MIB doctor review part 2 (T11-FC-SP-TC-MIB):
"WIJNEN, Bert \(Bert\)" <bwijnen@alcatel-lucent.com> Mon, 03 December 2007 22:25 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 1IzJj8-0004cs-17; Mon, 03 Dec 2007 17:25:22 -0500
Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1IzJj6-0004cL-RU for imss-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 17:25:20 -0500
Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzJj6-0004aQ-E6 for imss@ietf.org; Mon, 03 Dec 2007 17:25:20 -0500
Received: from ihemail3.lucent.com ([135.245.0.37]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzJj5-0002SH-Lv for imss@ietf.org; Mon, 03 Dec 2007 17:25:20 -0500
Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id lB3MPIbn013734; Mon, 3 Dec 2007 16:25:18 -0600 (CST)
Received: from DEEXP01.de.lucent.com ([135.248.187.65]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 16:25:18 -0600
Received: from DEEXC1U02.de.lucent.com ([135.248.187.26]) by DEEXP01.de.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 23:25:15 +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
Subject: RE: [imss] MIB doctor review part 2 (T11-FC-SP-TC-MIB):
Date: Mon, 03 Dec 2007 23:24:02 +0100
Message-ID: <D4D321F6118846429CD792F0B5AF471F7E5D23@DEEXC1U02.de.lucent.com>
In-Reply-To: <200711291805.KAA07634@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [imss] MIB doctor review part 2 (T11-FC-SP-TC-MIB):
Thread-Index: AcgysqGWVv8Kz87OTpq8wVMae2pjRADR7Xzg
References: <no.id> from "WIJNEN, Bert \(Bert\)" at Nov 26, 2007 06:08:52 PM <200711291805.KAA07634@cisco.com>
From: "WIJNEN, Bert (Bert)" <bwijnen@alcatel-lucent.com>
To: Keith McCloghrie <kzm@cisco.com>
X-OriginalArrivalTime: 03 Dec 2007 22:25:15.0987 (UTC) FILETIME=[60F63230:01C835FB]
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 93df555cbdbcdae9621e5b95d44b301e
Cc: imss@ietf.org
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
Inline Bert Wijnen > -----Original Message----- > From: Keith McCloghrie [mailto:kzm@cisco.com] > Sent: Thursday, November 29, 2007 10:05 AM > To: WIJNEN, Bert (Bert) > Cc: imss@ietf.org > Subject: Re: [imss] MIB doctor review part 2 (T11-FC-SP-TC-MIB): > > Bert > > Thanks for your first (of many, I'm sure!!) sets of comments > on the document. > > > 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. > > First, I feel it's valuable to acknowledge T11 in the MIB > module itself, not just in the RFC, because: a) they deserve > the acknowledgement, and b) it indicates that this MIB > benefitted from their Fibre Channel expertise. > > Second, RFC 2578 says: > > The ORGANIZATION clause, which must be present, contains a textual > description of the organization under whose auspices this > information > module was developed. > > and there were two such organizations: an initial one and a later one. > So, we could change the word "version" to something else if > you like, but otherwise, I think it's kosher. > > Would you prefer it to say something like: > > ORGANIZATION "This MIB module was a coordinated development > of two organizations: T11 began the > development > and the IETF's IMSS Working Group > finished it." > Sounds fine to me. > > 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? > > The definition is intentionally designed such that the > answers to your questions are: never, no, and no. That is, > the TC provides a REFERENCE to the location in FC-SP where > values are defined, the syntax of both objects is based on > the field sizes, not on assigned values, and the DESCRIPTION > lists the "first two" assignments, but only as an FYI, not as > the definitive specification. In other words, the TCs are > written so that they do not have to be updated when new > assignments are made, which avoids the work of creating a new > RFC and avoids creating extra work for IANA. > > > 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. > > See above -- the syantax is based on the field size, not on > the currently assigned values. That is, it is based on Table > 106, not on Table 107, of FC-SP (06-157v3) > OK > > 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. > > If they were three unrelated values, then I would share your concern. > However, all three types are potential values of a reason > code (or reason code explanation). In effect, the merge here > is the same as woudl be done by using a C-language "union" > construct, but the > SMIv2 doesn't have one. The merge is possible in this case > because the combined set of potential values can all be > included uniquely by assigning a unique named-number > enumeration for each one. > Thanks for the explanation. If the WG is OK with that (which I guess is the ase cuase no concern was raised in WG LC), then fine. > > 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). > > Perhaps, Claudio and David can take this comment back to T11 > for consideration in FC-SP2. > I think that would be good > > 5. Personal and subjective preference: I would rename > > > > T11FcSpAlphaNumNameOrNull > > > > into > > > > T11FcSpAlphaNumNameOrNone > > > > The "Null" often makes people think of 0 (zero). > > I checked existing RFCs, and I found one xxOrNull and four > xxOrNone TCs, two of which (VlanIdOrNone and > VlanIdOrAnyOrNone) are integer-valued with "None" > representing zero !! So, the precedent is not that clear > (except for the one you defined yourself:-). Perhaps the > greatest clarity would be: T11FcSpAlphaNumNameOrAbsent ?? > I can live with Null. Absent would be somewhat better to my subjective preference; so would None. Up to you. > > 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) > > I did change them, but please note that RFC 2578 defines it as: > > Unsigned32 ::= > [APPLICATION 2] > IMPLICIT INTEGER (0..4294967295) > > so the change is unquestionably redundant. > Thanks for the change. I like it to see an explicit statement that zero is valid in the index. > > 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. > > It will be somewhat repetitious because all of the ENCR_xxx > are in Table 70, and all of the AUTH_xxx are in Table 71, but > if you're concerned that the macros could be extracted and > displayed individually rather than as part of the MIB, then > yes, there is a circumstance where it would be advantageous. > That is what the REFERENCE clause is intended for I think. Bert > Thanks, > Keith. > _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss
- [imss] Changes to draft-ietf-imss-fc-fam-mib-00.t… Keith McCloghrie
- [imss] Re: Changes to draft-ietf-imss-fc-fam-mib-… Keith McCloghrie
- Re: [imss] Re: Changes to draft-ietf-imss-fc-fam-… Keith McCloghrie
- [imss] Re: Agenda for next week's T11.5 Managemen… Keith McCloghrie
- Re: [imss] FW: MIB Doctor review draft-ietf-imss-… Keith McCloghrie
- Re: [imss] FW: MIB Doctor review draft-ietf-imss-… Keith McCloghrie
- Re: [imss] FW: MIB Doctor review draft-ietf-imss-… Keith McCloghrie
- Re: [imss] Last Call: 'Fibre-Channel Name Server … Keith McCloghrie
- Re: [imss] Last Call: 'Fibre-Channel Name Server … Keith McCloghrie
- [imss] Re: DISCUSS on Keith McCloghrie
- [imss] Re: AD review of: draft-ietf-imss-fc-fspf-… Keith McCloghrie
- [imss] Re: AD review of: draft-ietf-imss-fc-fspf-… Keith McCloghrie
- [imss] Re: AD review of: draft-ietf-imss-fc-rtm-m… Keith McCloghrie
- [imss] Re: AD review of: draft-ietf-imss-fc-fspf-… Keith McCloghrie
- [imss] Re: AD review of: draft-ietf-imss-fc-fspf-… Claudio DeSanti
- Re: [imss] RE: AD review of: draft-ietf-imss-fc-r… Keith McCloghrie
- Re: [imss] RE: AD review of: draft-ietf-imss-fc-r… Keith McCloghrie
- Re: [imss] imss WG Last Call: Fibre Channel RSCN,… Keith McCloghrie
- Re: [imss] imss WG Last Call: Fibre Channel RSCN,… Keith McCloghrie
- Re: [imss] imss WG Last Call: Fibre Channel RSCN,… Keith McCloghrie
- Re: [imss] WG last call: draft-ietf-imss-fc-rscn-… Keith McCloghrie
- Re: [imss] imss WG Last Call: Fibre Channel RSCN,… Keith McCloghrie
- Re: [imss] WG Last Call: draft-ietf-imss-fc-fcs-m… Keith McCloghrie
- [imss] A couple of loose ends Keith McCloghrie
- Re: [imss] WG last call review: T11-FC-FABRIC-LOC… Keith McCloghrie
- Re: [imss] WG last call review: T11-FC-FABRIC-LOC… Keith McCloghrie
- Re: [imss] WG last call review: T11-FC-FABRIC-LOC… Claudio DeSanti
- Re: [imss] WG last call review: T11-FC-ZONE-SERVE… Keith McCloghrie
- Re: [imss] Last Call comments on draft-ietf-imss-… Keith McCloghrie
- RE: [imss] Last Call comments on draft-ietf-imss-… Black_David
- Re: [imss] Keith McCloghrie
- Re: [imss] Keith McCloghrie
- Re: [imss] T11 MIB issue resolutions Keith McCloghrie
- Re: [imss] T11 MIB issue resolutions Keith McCloghrie
- [imss] Rereview for draft-ietf-imss-fc-rscn-mib-0… Wijnen, Bert (Bert)
- Re: [imss] Rereview of: draft-ietf-imss-fc-fcs-mi… Keith McCloghrie
- RE: [imss] Rereview of: draft-ietf-imss-fc-fcs-mi… Black_David
- Re: [imss] re-view: T11-FC-FABRIC-LOCK-MIB in Keith McCloghrie
- RE: [imss] re-view: T11-FC-FABRIC-LOCK-MIB in Wijnen, Bert (Bert)
- Re: [imss] re-review: T11-FC-ZONE-SERVER-MIB in Keith McCloghrie
- RE: [imss] re-review: T11-FC-ZONE-SERVER-MIB in Wijnen, Bert (Bert)
- Re: [imss] Acceptance of draft-kzm-imss-fc-fcsp-m… Keith McCloghrie
- RE: [imss] Acceptance of draft-kzm-imss-fc-fcsp-m… Romascanu, Dan (Dan)
- Re: [imss] imss WG Last Call: FC-SP MIB Keith McCloghrie
- RE: [imss] imss WG Last Call: FC-SP MIB Black_David
- Re: [imss] imss WG Last Call: FC-SP MIB Keith McCloghrie
- Re: [imss] imss WG Last Call: FC-SP MIB Keith McCloghrie
- RE: [imss] imss WG Last Call: FC-SP MIB WIJNEN, Bert (Bert)
- Re: [imss] imss WG Last Call: FC-SP MIB Keith McCloghrie
- RE: [imss] imss WG Last Call: FC-SP MIB Black_David
- Re: [imss] imss WG Last Call: FC-SP MIB Keith McCloghrie
- RE: [imss] imss WG Last Call: FC-SP MIB WIJNEN, Bert (Bert)
- RE: [imss] imss WG Last Call: FC-SP MIB WIJNEN, Bert (Bert)
- Re: [imss] imss WG Last Call: FC-SP MIB Keith McCloghrie
- Re: [imss] MIB doctor review part 1 (SYNTAX Check… Keith McCloghrie
- Re: [imss] MIB doctor review part 2 (T11-FC-SP-TC… Keith McCloghrie
- RE: [imss] MIB doctor review part 2 (T11-FC-SP-TC… WIJNEN, Bert (Bert)
- RE: [imss] imss WG Last Call: FC-SP MIB WIJNEN, Bert (Bert)
- Re: [imss] AD Review for draft-ietf-imss-fc-fcsp-… Keith McCloghrie
- Re: [imss] AD Review for draft-ietf-imss-fc-fcsp-… Black_David
- Re: [imss] AD Review for draft-ietf-imss-fc-fcsp-… Romascanu, Dan (Dan)