From imss-bounces@ietf.org Mon Dec 03 17:25:22 2007 Return-path: 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, 3 Dec 2007 23:24:02 +0100 Message-ID: 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: from "WIJNEN, Bert \(Bert\)" at Nov 26, 2007 06:08:52 PM <200711291805.KAA07634@cisco.com> From: "WIJNEN, Bert \(Bert\)" To: "Keith McCloghrie" 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: imss-bounces@ietf.org Inline Bert Wijnen =20 > -----Original Message----- > From: Keith McCloghrie [mailto:kzm@cisco.com]=20 > 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): >=20 > Bert >=20 > Thanks for your first (of many, I'm sure!!) sets of comments=20 > on the document. >=20 > > Here are my comments/questions on the T11-FC-SP-TC-MIB module > > > > 1. I find it somewhat weird to see: > >=20 > > t11FcTcMIB MODULE-IDENTITY > > LAST-UPDATED "200708130000Z" > > ORGANIZATION "For the initial versions, T11. > > For later versions, the IETF's IMSS Working=20 > > Group." > >=20 > > The one version that gets formally published is the one in the > > upcoming RFC. At that time there are basically no=20 > "initial" versions > > other than the one in the RFC.=20 >=20 > First, I feel it's valuable to acknowledge T11 in the MIB=20 > module itself, not just in the RFC, because: a) they deserve=20 > the acknowledgement, and b) it indicates that this MIB=20 > benefitted from their Fibre Channel expertise. >=20 > Second, RFC 2578 says: >=20 > The ORGANIZATION clause, which must be present, contains a textual > description of the organization under whose auspices this=20 > information > module was developed. >=20 > and there were two such organizations: an initial one and a later one. > So, we could change the word "version" to something else if=20 > you like, but otherwise, I think it's kosher. >=20 > Would you prefer it to say something like: >=20 > ORGANIZATION "This MIB module was a coordinated development > of two organizations: T11 began the=20 > development > and the IETF's IMSS Working Group=20 > finished it." >=20 Sounds fine to me. > > 2. looking at T11FcSpPolicyHashFormat and T11FcSpPolicyHashValue I=20 > > wonder > > if/how often the TCS will need to be updated? And when=20 > that is done, > > a. do we then want to create a new RFC or > > b. should this become an iana maintained module?=20 > =20 > The definition is intentionally designed such that the=20 > answers to your questions are: never, no, and no. That is,=20 > the TC provides a REFERENCE to the location in FC-SP where=20 > values are defined, the syntax of both objects is based on=20 > the field sizes, not on assigned values, and the DESCRIPTION=20 > lists the "first two" assignments, but only as an FYI, not as=20 > the definitive specification. In other words, the TCs are=20 > written so that they do not have to be updated when new=20 > assignments are made, which avoids the work of creating a new=20 > RFC and avoids creating extra work for IANA. >=20 > > 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: > >=20 > > SYNTAX OCTET STRING (SIZE (20 | 32)) > >=20 > > because there are no other lengths possible given the currently > > specified/valid formats. > =20 > See above -- the syantax is based on the field size, not on=20 > the currently assigned values. That is, it is based on Table=20 > 106, not on Table 107, of FC-SP (06-157v3) >=20 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. > > =20 > > T11FcSpAuthRejectReasonCode > > T11FcSpAuthRejReasonCodeExp > >=20 > > 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. > >=20 > > Maybe it is OK, but I am somewhat worried. >=20 > If they were three unrelated values, then I would share your concern.=20 > However, all three types are potential values of a reason=20 > code (or reason code explanation). In effect, the merge here=20 > is the same as woudl be done by using a C-language "union"=20 > construct, but the > SMIv2 doesn't have one. The merge is possible in this case=20 > because the combined set of potential values can all be=20 > included uniquely by assigning a unique named-number=20 > 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. =20 > > 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). >=20 > Perhaps, Claudio and David can take this comment back to T11=20 > for consideration in FC-SP2. > I think that would be good =20 > > 5. Personal and subjective preference: I would rename > >=20 > > T11FcSpAlphaNumNameOrNull > >=20 > > into > >=20 > > T11FcSpAlphaNumNameOrNone > >=20 > > The "Null" often makes people think of 0 (zero). > =20 > I checked existing RFCs, and I found one xxOrNull and four=20 > xxOrNone TCs, two of which (VlanIdOrNone and=20 > VlanIdOrAnyOrNone) are integer-valued with "None"=20 > representing zero !! So, the precedent is not that clear=20 > (except for the one you defined yourself:-). Perhaps the=20 > 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. =20 > > 6. As reported by the SYNTAX checkers, I would change the underlying > > SYNTAX for T11FcSpiIndex and T11FcSpPrecedence to be > >=20 > > SYNTAX Unsigned32 (0..4294967295) > >=20 > > instead of: > >=20 > > SYNTAX Unsigned32 -- the default range: (0..4294967295) >=20 > I did change them, but please note that RFC 2578 defines it as: >=20 > Unsigned32 ::=3D > [APPLICATION 2] > IMPLICIT INTEGER (0..4294967295) >=20 > so the change is unquestionably redundant. >=20 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. >=20 > It will be somewhat repetitious because all of the ENCR_xxx=20 > are in Table 70, and all of the AUTH_xxx are in Table 71, but=20 > if you're concerned that the macros could be extracted and=20 > displayed individually rather than as part of the MIB, then=20 > yes, there is a circumstance where it would be advantageous. >=20 That is what the REFERENCE clause is intended for I think. Bert > Thanks, > Keith. >=20 _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Mon Dec 03 17:53:44 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzKAX-0007tN-Nl; Mon, 03 Dec 2007 17:53:41 -0500 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1IzKAX-0007rX-2M for imss-confirm+ok@megatron.ietf.org; Mon, 03 Dec 2007 17:53:41 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IzKAW-0007np-1P for imss@ietf.org; Mon, 03 Dec 2007 17:53:40 -0500 Received: from ihemail2.lucent.com ([135.245.0.35]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1IzKAS-0005Jq-0b for imss@ietf.org; Mon, 03 Dec 2007 17:53:37 -0500 Received: from ilexp03.ndc.lucent.com (h135-3-39-50.lucent.com [135.3.39.50]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id lB3MrNoR002098; Mon, 3 Dec 2007 16:53:23 -0600 (CST) Received: from DEEXP02.DE.lucent.com ([135.248.187.66]) by ilexp03.ndc.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 16:53:23 -0600 Received: from DEEXC1U02.de.lucent.com ([135.248.187.26]) by DEEXP02.DE.lucent.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 3 Dec 2007 23:53:20 +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] imss WG Last Call: FC-SP MIB Date: Mon, 3 Dec 2007 23:53:09 +0100 Message-ID: In-Reply-To: <200711281834.KAA14355@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [imss] imss WG Last Call: FC-SP MIB Thread-Index: Acgx7YG6XW48IktvRMCl2IwFkJTYMQEEZWUA References: from "WIJNEN, Bert \(Bert\)" at Nov 27, 2007 10:35:47 AM <200711281834.KAA14355@cisco.com> From: "WIJNEN, Bert \(Bert\)" To: "Keith McCloghrie" X-OriginalArrivalTime: 03 Dec 2007 22:53:20.0886 (UTC) FILETIME=[4D3D6160:01C835FF] X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35 X-Spam-Score: 0.0 (/) X-Scan-Signature: c8d1e86bb8f49de8156b6392faa4a63b Cc: imss@ietf.org, Black_David@emc.com, dromasca@avaya.com X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: imss-bounces@ietf.org New MIB modules pass the SYNTAX Check nearly clean. Only one warning: ./T11-FC-SP-TC-MIB:327: warning: type `T11FcSpiIndex' has no format specification Bert Wijnen =20 > -----Original Message----- > From: Keith McCloghrie [mailto:kzm@cisco.com]=20 > Sent: Wednesday, November 28, 2007 10:34 AM > To: WIJNEN, Bert (Bert) > Cc: Keith McCloghrie; Black_David@emc.com; imss@ietf.org;=20 > dromasca@avaya.com > Subject: Re: [imss] imss WG Last Call: FC-SP MIB >=20 > Bert, >=20 > There's an updated version at: >=20 > ftp://ftpeng.cisco.com/ftp/kzm/draft-ietf-imss-fc-fcsp-mib-01.txt >=20 > I included (see the Change Log) updates based on several of=20 > the emails in which you have already sent comments. (I'll=20 > reply to those emails in another message after this one, re:=20 > chnages that I haven't made.) >=20 > I can't submit it as an updated I-D because new submissions=20 > are suspended until after (the beginning? of) the IETF next=20 > week. If and when there are more changes that need to be=20 > made before the submission, the submitted version will be=20 > different to this version. Thus, on page 1, I list the filename as: >=20 > "(preliminary) draft-ietf-imss-fc-fcsp-mib-01.txt" >=20 > Keith. > =20 > > Sure. Pls go ahead and make the changes (I am used for you=20 > doing that=20 > > pretty quick normally). > >=20 > > Bert Wijnen > >=20 > > > -----Original Message----- > > > From: Keith McCloghrie [mailto:kzm@cisco.com] > > > Sent: Tuesday, November 27, 2007 3:00 AM > > > To: Black_David@emc.com > > > Cc: kzm@cisco.com; WIJNEN, Bert (Bert); imss@ietf.org;=20 > > > dromasca@avaya.com > > > Subject: Re: [imss] imss WG Last Call: FC-SP MIB > > >=20 > > > I agree. > > >=20 > > > Bert, that's one less MIB module for you to review, and=20 > there will=20 > > > be a number of editorial changes associated with removing=20 > > > T11-FC-SP-CERTS-MIB > > > -- is it worth me making those editorial changes before=20 > you continue=20 > > > your review, so that your review will check that I found all the=20 > > > ones in the parts that you haven't yet reviewed ? > > >=20 > > > Keith. > > > =20 > > > > Keith, > > > >=20 > > > > At this juncture, I favor approach 3: > > > >=20 > > > > > 3. Decide that the value of the one extra piece of information > > > > > (t11FcSpCertUsage) is not important enough for this MIB > > > to have any > > > > sort > > > > > of dependency, and to decide not to define the > > > T11-FC-SP-CERTS-MIB > > > > > at the present time. > > > >=20 > > > > The extra information classifies a certificate as=20 > authentication=20 > > > > (entity has private key) vs. trust anchor (used to verify > > > certificates > > > > presented by other entities) and indicates which of the > > > certificates > > > > is the default. Both of these are generic to=20 > certificates (i.e.,=20 > > > > there's nothing special to FC that requires them), and > > > hence arguably > > > > belong in a certificate MIB somewhere as opposed to an=20 > FC MIB. In=20 > > > > addition, I expect that the PKIX folks will probably=20 > have things=20 > > > > to say about how to do certificate usage "right" which=20 > won't have=20 > > > > much resemblance to what's in the MIB ;-). Finally, starting > > > work on trust > > > > anchor management is on the PKIX agenda for Vancouver,=20 > and hence=20 > > > > staying out of that entire area is probably a prudent=20 > step towards=20 > > > > getting this MIB done in the nearer future. > > > >=20 > > > > Unless there's objection from anyone else on the mailing > > > list, I think > > > > we should just drop the CERTS-MIB. > > > >=20 > > > > Thanks, > > > > --David > > > > ---------------------------------------------------- > > > > David L. Black, Distinguished Engineer EMC Corporation, 176 > > > South St., > > > > Hopkinton, MA 01748 > > > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > > > black_david@emc.com Mobile: +1 (978) 394-7754 > > > > ---------------------------------------------------- > > > >=20 > > > > > -----Original Message----- > > > > > From: Keith McCloghrie [mailto:kzm@cisco.com] > > > > > Sent: Monday, November 26, 2007 12:21 PM > > > > > To: bwijnen@alcatel-lucent.com > > > > > Cc: Keith McCloghrie; Black, David; imss@ietf.org;=20 > > > > > dromasca@avaya.com > > > > > Subject: Re: [imss] imss WG Last Call: FC-SP MIB > > > > >=20 > > > > >=20 > > > > > Here are three alternatives for what we could do: > > > > >=20 > > > > > 1. Continue with the "dependency" as-is, but with the=20 > additional=20 > > > > > note on compliance that you suggest. > > > > >=20 > > > > > 2. Generalize the "dependency" so that it doesn't > > > actually refer to > > > > > [IPSP-IKE-ACTION] or [IPSP-IPSEC-ACTION], but instead > > > says something > > > > > like: > > > > >=20 > > > > > Prior to the definition of the T11-FC-SP-CERTS-MIB, > > > work had started > > > > > in the IETF to specify a set of MIBs for managing > > > IPsec/IKEv2. The > > > > > work was far enough along for the definition of=20 > FC-SP MIBs to > > > > > leverage them as prior work, and to define a small=20 > extension of > > > > > importance in the Fibre Channel environment. However, > > > the approval > > > > > process for the IPsec/IKEv2 MIBs was delayed such that the=20 > > > > > definition > > > > > of FC-SP MIBs caught-up with and was expected to > > > overtake those for > > > > > IPsec/IKEv2. In order not to create a dependency,=20 > this document > > > > > defines only the extension, and it does so in a generic > > > manner so > > > > > that the extension can be applied to any MIB for > > > IPsec/IKEv2, either > > > > > the completion of the previously-begun work or any > > > alternative which > > > > > might begin in the future. > > > > >=20 > > > > > I think a simple technical change is all that is required to=20 > > > > > make the definitions (in T11-FC-SP-CERTS-MIB) generic. > > > Specifcially, I > > > > > suggest we change syntax of t11FcSpCertPointer to be an OID,=20 > > > > > such that it can point to any table, i.e., not only into the=20 > > > > > ipsaCredentialTable, but also into any other MIB's table. > > > > >=20 > > > > > I think the above would allow the references to be=20 > Informational. > > > > >=20 > > > > > 3. Decide that the value of the one extra piece of information > > > > > (t11FcSpCertUsage) is not important enough for this MIB > > > to have any > > > > > sort of dependency, and to decide not to define the=20 > > > > > T11-FC-SP-CERTS-MIB at the present time. > > > > >=20 > > > > > Keith. > > > > >=20 > > > > > =20 > > > > > > W.r.t. > > > > > > > > One thing I do see that may need some action is the > > > > > fact that this > > > > > > > > document has normative dependencies on these 2=20 > documents: > > > > > > > >=20 > > > > > > > > [IPSP-IKE-ACTION] > > > > > > > > Baer, M., Charlet, R., Hardaker, W., Story, R., > > > > > and C. Wang, > > > > > > "IPsec > > > > > > > > Security Policy IKE Action MIB", > > > > > draft-ietf-ipsp-ikeaction-mib- > > > > > > > > nn.txt, work-in-progress, 19 October 2006. > > > > > > > >=20 > > > > > > > > [IPSP-IPSEC-ACTION] > > > > > > > > Baer, M., Charlet, R., Hardaker, W., Story, R., > > > > > and C. Wang, > > > > > > "IPsec > > > > > > > > Security Policy IPsec Action MIB", > > > > > > draft-ietf-ipsp-ipsecaction-mib- > > > > > > > > nn.txt, work-in-progress, 19 October 2006. > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > However, I do not see that any IMPORT is done for those > > > > > 2 IPSP MIB > > > > > > > > modules, so maybe the dependency is not really=20 > normative? > > > > > > >=20 > > > > > > > I agree that such a "dependency" is a little=20 > risky, because=20 > > > > > > > I too submitted some comments on those MIBs. The > > > reason that I'm > > > > > > > using quotes around "dependency" is because it is not the=20 > > > > > > > definitions in this MIB which depend on any > > > definitions in those > > > > > > > MIBs, but rather the explanation of why this MIB has > > > the set of > > > > > > > (certificate-related) objects that it does. > > > > > > > Without such explanations, the definitions in=20 > this MIB would=20 > > > > > > > appear incomplete, and it seems to me that making it=20 > > > > > > > complete requires either: > > > > > > >=20 > > > > > > > 1. the reference to the IPSP MIB modules that it > > > currently has, > > > > > > > or 2. definition of new MIB objects which > > > duplicate/overlap with > > > > > > > the IPSP MIB modules. > > > > > > >=20 > > > > > > > Given that the IPSP MIB modules are still expected to get=20 > > > > > > > approved (in the future), then I'd say #2 is at least=20 > > > > > > > undesirable, and probably unacceptable. > > > > > > >=20 > > > > > >=20 > > > > > > yep... that sounds unacceptable. At the other hand, you > > > may end up > > > > > > having you approved I-D in the RFC-Editor queue for > > > many years to > > > > > > come waiting for the dependent IPSP MIB module > > > documents to come > > > > > > through (sorry... even though there was a message about > > > the status > > > > > > of IPSP MIB modules in August this year, I have seen no > > > activity > > > > > > since. I keep being very pessimistic about a reasonable > > > result in > > > > > > this space). > > > > > >=20 > > > > > > Maybe one of the ADs (possibly security ADs) can=20 > say something=20 > > > > > > about this issue or about the "dependency". As long as the=20 > > > > > > docs are listed as normative references, your doc will get > > > block at the > > > > > > RFC-Editor gates till those normative docs are ready to > > > become an > > > > > > RFC as well. > > > > > >=20 > > > > > >=20 > > > > > > > So, if you can provide guidance on how to reference > > > the IPSP MIB > > > > > > > modules in a way which avoids creating normative > > > dependencies, > > > > > > > then please do. > > > > > > >=20 > > > > > >=20 > > > > > > If I read your section 4.6, then it seems that the=20 > > > > > > ipsaCredentialTable, the ipsaCredentialSegmentTable and the=20 > > > > > > ipiaCredMngCRLTable are needed to manage CAs and CRLs. > > > > > > So that to me seems quite a dependency. Are you guys > > > aware of how > > > > > > your implementations will/might run without those=20 > tables? Have=20 > > > > > > they currently been implemented in prorpietary ways? > > > > > > Or have pre-RFC implementations been fielded?=20 > > > > > >=20 > > > > > > >From sect 4.6, it seems that your=20 > MODULE-COMPLIANCE ought to=20 > > > > > > >state > > > > > > that those tables from IPSP MIB modules have to be=20 > supported=20 > > > > > > in order to let your MIB modules/security-features work, no? > > > > > >=20 > > > > > > Bert > > > > > > > Keith. > > > > > > >=20 > > > > > > >=20 > > > > > > > > I will find out when > > > > > > > > I read the whole FC-SP MIB document. Sofar I did notice: > > > > > > > >=20 > > > > > > > > - 4.8.6. The T11-FC-SP-CERTS-MIB Module > > > > > > > >=20 > > > > > > > > This MIB module specifies extensions to IPSP MIBs > > > > > > > [IPSP-IPSEC-ACTION] > > > > > > > > and [IPSP-IKE-ACTION] which are specific to Fibre > > > > > Channel. In > > > > > > > > particular, it specifies one table,=20 > t11FcSpCertsTable, > > > > > > > with a row per > > > > > > > > certificate indicating how that certificate is being > > > > > used, and > > > > > > > > containing the "name" of the certificate. =20 > This "name"=20 > > > > > > > can be used to > > > > > > > > obtain information, which is independent of > > > FC-SP, about the > > > > > > > > certificate from the ipsaCredentialTable=20 > (and from the > > > > > > > > ipsaCredentialSegmentTable if the certificate is > > > > > longer than 1024 > > > > > > > > bytes). > > > > > > > >=20 > > > > > > > > - In the T11-FC-SP-CERTS-MIB (page 230/231: > > > > > > > >=20 > > > > > > > > Since FC-SP leverages a subset of IPsec and > > > > > > > IKEv2 (see RFC > > > > > > > > 4595), a subset of the management > > > > > information defined for > > > > > > > > the use of certificates with IPsec/IKEv2 is=20 > > > > > > > > also > > > > > > > applicable > > > > > > > > to FC-SP. Thus, this MIB module leverages > > > > > RFC wwww and > > > > > > > > RFC xxxx for the management of certificates,=20 > > > > > > > > CAs > > > > > > > and CRLs. > > > > > > > > -- RFC Editor: replace wwww with actual RFC=20 > number for > > > > > > > > -- [IPSP-IPSEC-ACTION], and replace xxxx with actual=20 > > > > > > > > RFC > > > > > > > number for > > > > > > > > -- [IPSP-IKE-ACTION] & remove this note > > > > > > > >=20 > > > > > > > > Specifically, the information defined in > > > > > this MIB module > > > > > > > > consists of a pointer into the IPsec/IKEv2 > > > > > MIB modules, > > > > > > > > plus minimal additional item(s) of > > > > > information which are > > > > > > > > considered to be important in a Fibre Channel > > > > > > > environment. > > > > > > > >=20 > > > > > > > > So it does sound normative. So I have a warning: > > > > > > > >=20 > > > > > > > > I have been reviewing those 2 IPSP documents a few times > > > > > > > over the last > > > > > > > > (mmmm probably) 2-3 or 2-4 years, and I must=20 > warn you that > > > > > > > the cycle > > > > > > > > times on those documents are EXTREMELY slow. The > > > > > current revisions > > > > > > > > are: > > > > > > > >=20 > > > > > > > > draft-ietf-ipsp-ikeaction-mib-02.txt > > > > > > > > draft-ietf-ipsp-ipsecaction-mib-02.txt > > > > > > > >=20 > > > > > > > > which showed up as I-D on 10 Nov 2006, and both=20 > are still > > > > > > > in Revised > > > > > > > > ID needed. Those MIB documents are also pretty complex,=20 > > > > > > > > and > > > > > > > so if/when > > > > > > > > a new revision will eventually show up (if at all), then > > > > > > > whoever needs > > > > > > > > to re-review will need a serious block of time to > > > > > actually do so. > > > > > > > > My personal experience is pretty bad/sad with those 2 > > > > > > > documents, and I > > > > > > > > must admit that I am completely de- or un-motivated at=20 > > > > > > > > this > > > > > > > point in > > > > > > > > time to re-review them a again if/when they do show up.=20 > > > > > > > > But > > > > > > > possibly > > > > > > > > Dan can convince me otherwise at that time. > > > > > > > >=20 > > > > > > > > Anyway, I just wanted the=20 > authors/editors/wg-chair and WG > > > > > > > members to > > > > > > > > be aware of this risky normative dependency. > > > > > > > >=20 > > > > > > > > Bert Wijnen > > > > > > > >=20 > > > > > > > > > -----Original Message----- > > > > > > > > > From: Black_David@emc.com [mailto:Black_David@emc.com] > > > > > > > > > Sent: Wednesday, October 10, 2007 2:18 AM > > > > > > > > > To: imss@ietf.org > > > > > > > > > Cc: dromasca@avaya.com; Black_David@emc.com > > > > > > > > > Subject: [imss] imss WG Last Call: FC-SP MIB > > > > > > > > > Importance: High > > > > > > > > >=20 > > > > > > > > > This is to announce an imss WG Last Call on the=20 > > > > > > > > > following > > > > > > > MIB draft: > > > > > > > > >=20 > > > > > > > > > MIB for Fibre-Channel Security > > > Protocols (FC-SP) > > > > > > > > > draft-ietf-imss-fc-fcsp-mib-00.txt > > > > > > > > >=20 > > > > > > > > > This WG Last Call will run through 12 midnight > > > > > Eastern Time on > > > > > > > > > Friday, October 26, 2007 (your WG chair hopes to deal > > > > > > > with Last Call > > > > > > > > > results during the week of October 29th and hopes that > > > > > > > any revisions > > > > > > > > > can be completed prior to the November 19th > > > Internet Draft > > > > > > > > > submission cutoff for the Vancouver meeting). > > > > > > > > >=20 > > > > > > > > > Technical comments *must* be sent to the imss > > > mailing list. > > > > > > > > > Editorial comments may be sent directly to the draft > > > > > editor (but > > > > > > > > > please cc: me): > > > > > > > > >=20 > > > > > > > > > Keith McCloghrie [kzm@cisco.com] > > > > > > > > >=20 > > > > > > > > > In order to try to set a good example, I have=20 > completed > > > > > > > my WG chair > > > > > > > > > review of the MIB prior to announcing this Last Call. > > > > > > > > >=20 > > > > > > > > > I found two technical concerns: > > > > > > > > > (1) The MIB defines precedence values for traffic > > > selectors > > > > > > > > > as opposed to implicitly presenting=20 > them in order of > > > > > > > > > precedence. I guess this is ok, but=20 > Section 4.7 should > > > > > > > > > explain why this approach was chosen. > > > > > > > > > (2) Section 4.9 defines rate control for=20 > Authentication > > > > > > > > > failures on a per-fabric granularity. =20 > That strikes > > > > > > > > > me as overly coarse, and I wonder if=20 > per-SA would > > > > > > > > > be a more appropriate/useful granularity. > > > > > > > > >=20 > > > > > > > > > I also found a number of editorial concerns: > > > > > > > > >=20 > > > > > > > > > Section 1, 2nd paragraph. Remove the=20 > sentence starting > > > > > > > with "This > > > > > > > > > latest draft" or insert an instruction to the=20 > RFC Editor > > > > > > > to remove > > > > > > > > > it before publication as an RFC. > > > > > > > > >=20 > > > > > > > > > Section 3.1 - Delete "The" at the start of the first > > > > > paragraph. > > > > > > > > >=20 > > > > > > > > > Should Section 3.5 and subsequent subsections of > > > > > Section 3 all be > > > > > > > > > subsections of Section 3.4 Security? > > > > > > > > >=20 > > > > > > > > > Section 3.10 - "To provide better scaling, the Switch > > > > > Connectivity > > > > > > > > > Objects are not Fabric-wide information such > > > that they are > > > > > > > > > distributed only to where they are needed." > > > > > > > > >=20 > > > > > > > > > "information such that they are" ->=20 > information, but are" > > > > > > > > >=20 > > > > > > > > > Section 3.10 introduces "Active Zone Set" but does not > > > > > > > explain what > > > > > > > > > this term means. > > > > > > > > >=20 > > > > > > > > > T11FcSpPolicyNameType - the DESCRIPTION needs=20 > to explain > > > > > > > the concept > > > > > > > > > of "restricted" - how does a "restricted" entity > > > > > differ from the > > > > > > > > > corresponding unrestricted entity? > > > > > > > > >=20 > > > > > > > > > Thanks, > > > > > > > > > --David > > > > > > > > > ---------------------------------------------------- > > > > > > > > > David L. Black, Senior Technologist EMC=20 > Corporation, 176=20 > > > > > > > > > South St., Hopkinton, MA 01748 > > > > > > > > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > > > > > > > > black_david@emc.com Mobile: +1 (978) 394-7754 > > > > > > > > > ---------------------------------------------------- > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > >=20 > > > > > > > > > _______________________________________________ > > > > > > > > > imss mailing list > > > > > > > > > imss@ietf.org > > > > > > > > > https://www1.ietf.org/mailman/listinfo/imss > > > > > > > > >=20 > > > > > > > >=20 > > > > > > > >=20 > > > > > > > > _______________________________________________ > > > > > > > > imss mailing list > > > > > > > > imss@ietf.org > > > > > > > > https://www1.ietf.org/mailman/listinfo/imss > > > > > > > >=20 > > > > > > >=20 > > > > > >=20 > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > >=20 >=20 _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Fri Dec 28 10:29:23 2007 Return-path: 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" To: Date: Fri, 28 Dec 2007 16:29:27 +0100 Message-ID: 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 , Keith McCloghrie , Black_David 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 List-Unsubscribe: , List-Post: List-Help: List-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 From imss-bounces@ietf.org Fri Dec 28 11:19:12 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8HvR-0002vH-O6; Fri, 28 Dec 2007 11:19:09 -0500 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1J8HvR-0002vC-9p for imss-confirm+ok@megatron.ietf.org; Fri, 28 Dec 2007 11:19:09 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8HvQ-0002v4-Uj for imss@ietf.org; Fri, 28 Dec 2007 11:19:08 -0500 Received: from mexforward.lss.emc.com ([128.222.32.20]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J8HvQ-0003t6-Cq for imss@ietf.org; Fri, 28 Dec 2007 11:19:08 -0500 Received: from hop04-l1d11-si02.isus.emc.com (HOP04-L1D11-SI02.isus.emc.com [10.254.111.55]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id lBSGJ7lG005724 for ; Fri, 28 Dec 2007 11:19:07 -0500 (EST) Received: from mailhub.lss.emc.com (nagas.lss.emc.com [10.254.144.11]) by hop04-l1d11-si02.isus.emc.com (Tablus Interceptor) for ; Fri, 28 Dec 2007 11:19:02 -0500 Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id lBSGIlfO023884 for ; Fri, 28 Dec 2007 11:19:01 -0500 (EST) From: Black_David@emc.com Received: from CORPUSMX20A.corp.emc.com ([128.221.62.13]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 28 Dec 2007 11:18:56 -0500 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: Fri, 28 Dec 2007 11:18:00 -0500 Message-ID: <8CC6CEAB44F131478D3A7B429ECACD91085E15@CORPUSMX20A.corp.emc.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MIB doctor review for T11-FC-SP-AUTHENTICATION-MIB thread-index: AchJZm4eZRDpURDyQ6q3ITkqc+TGTgABrkmg To: X-OriginalArrivalTime: 28 Dec 2007 16:18:56.0274 (UTC) FILETIME=[585BE720:01C8496D] X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.1.298604, Antispam-Data: 2007.8.30.53115 X-PerlMx-Spam: Gauge=, SPAM=1%, Reason='EMC_FROM_0+ -3, NO_REAL_NAME 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' X-Tablus-Inspected: yes X-Tablus-Classifications: public X-Tablus-Action: allow X-Spam-Score: 0.0 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a Subject: [imss] FW: 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: imss-bounces@ietf.org Forwarding to the list ... --David -----Original Message----- From: Bert Wijnen - IETF [mailto:bertietf@bwijnen.net]=20 Sent: Friday, December 28, 2007 10:29 AM To: imss@ietf.org Cc: Keith McCloghrie; Black, David; Dan Romascanu Subject: MIB doctor review for T11-FC-SP-AUTHENTICATION-MIB 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 ::=3D { t11FcSpAuthenticationMIB 1 = } t11FcSpAuMIBObjects OBJECT IDENTIFIER ::=3D { t11FcSpAuthenticationMIB 2 = } t11FcSpAuMIBConformance OBJECT IDENTIFIER ::=3D { t11FcSpAuthenticationMIB 3 = } t11FcSpAuMIBNotifications OBJECT IDENTIFIER ::=3D { 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 ::=3D { t11FcSpAuthenticationMIB 0 = } t11FcSpAuMIBObjects OBJECT IDENTIFIER ::=3D { t11FcSpAuthenticationMIB 1 = } t11FcSpAuMIBConformance OBJECT IDENTIFIER ::=3D { t11FcSpAuthenticationMIB 2 = } t11FcSpAuMIBIdentities OBJECT IDENTIFIER ::=3D { 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=3D0." 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 From imss-bounces@ietf.org Fri Dec 28 18:58:53 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8P6L-0006nX-Ch; Fri, 28 Dec 2007 18:58:53 -0500 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1J8P6J-0006nM-Ez for imss-confirm+ok@megatron.ietf.org; Fri, 28 Dec 2007 18:58:51 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8P6J-0006n4-2H for imss@ietf.org; Fri, 28 Dec 2007 18:58:51 -0500 Received: from relay.versatel.net ([62.250.3.110]) by chiedprmail1.ietf.org with smtp (Exim 4.43) id 1J8P6G-0004Or-PX for imss@ietf.org; Fri, 28 Dec 2007 18:58:49 -0500 Received: (qmail 80354 invoked from network); 28 Dec 2007 23:58:46 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 28 Dec 2007 23:58:46 -0000 From: "Bert Wijnen - IETF" To: Date: Sat, 29 Dec 2007 00:58:54 +0100 Message-ID: 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: 6a45e05c1e4343200aa6b327df2c43fc Cc: Dan Romascanu , Black_David , Keith McCloghrie Subject: [imss] MIB Doctor review for: T11-FC-SP-POLICY-MIB X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: imss-bounces@ietf.org [bcc: to MIB doctors list] This is a review of the module as extracted from the prelimenary draft-ietf-imss-fc-fcsp-mib-01.txt document - I see: t11FcSpPolicyMIB MODULE-IDENTITY LAST-UPDATED "200702190000Z" ORGANIZATION "T11" I think that IETF IMSS WG should be included as one of the ORGANIZATIONs that worked on this MIB module - I see: t11FcSpPoAdminFabricName OBJECT-TYPE SYNTAX FcNameIdOrZero (SIZE (8)) MAX-ACCESS read-only STATUS current DESCRIPTION "The administratively-specified name for this Fabric, as specified in the active Switch Membership List Object. This value is meaningful only when Static Domain_IDs are in use in a Fabric (see FC-SW-4). Static Domain_IDs are administratively enabled by a setting of the Switch Flags in each Switch Entry in the Switch Membership List Object. If Static Domain_IDs are not in use, this value might be '0000000000000000'h. The t11FamEnable, t11FamFabricName and t11FamConfigDomainIdType objects defined in the T11-FC-FABRIC-ADDR-MGR-MIB module are also concerned with the use of an administratively-specified name for a Fabric and Static Domain_IDs. When FC-SP Policy is in use in a Fabric, the values of t11FamEnable, t11FamFabricName and t11FamConfigDomainIdType must be read-only and reflect the active Policy Objects. For example, the value of t11FamFabricName must reflect the value of t11FcSpPoAdminFabricName." And I then wonder if the SIZE (8) is indeed intended or if it ought to be SIZE (8 | 16). Futher, when reading the restrinctions on t11FamEnable, t11FamFabricName and t11FamConfigDomainIdType that this MIB module imposes on another MIB module, I wonder - is that for all entries in the t11FamTable? In other words, once you use the POLICY-MIB, would it apply to all Fabrics, or just to the ones fro which there are entries in this Table. - And is that a "must be read-only" a dynamic thing? In other words, once an Active Policy gets deactivated, doe the objects in the t11FamTable then become read-write again? - Depending on the answers, would it make sense to add more to the DESCRIPTION clause? - Depending on the answers, would it make sense to IMPORT these obecjts and use them in the MODULE-CONFORMANCE to indicate that MAX-ACCESS is read-only ?? - I find this a bit confusing: t11FcSpPoSummaryPolicyType OBJECT-TYPE SYNTAX T11FcSpPolicyObjectType MAX-ACCESS read-only STATUS current DESCRIPTION "The 'Identifier' which specifies the type of this Policy Object." It is just the "type" is it not? ANd it is indicated by the valu of this object whioch is an enumeration. So wht is the 'Identifier'? Why no just say: DESCRIPTION "The type of this Policy Object." - When I read (in the TC-MIB about T11FcSpPolicyNameType and T11FcSpPolicyName, I sort of assumed/thought that these two would always be used in combination. However in this POLICY-MIB I see the T11FcSpPolicyNameType (subtypef in OBJECT-TYPE t11FcSpPoSwMembSwitchNameType) being used together with: t11FcSpPoSwMembSwitchName OBJECT-TYPE SYNTAX FcNameIdOrZero (SIZE (8)) Is that not at least somewhat weird and possibly confusing? I can see that it is not absolutely flawed, but I am not sure we want to do this sort of thing, do we? Further in the POLICY-MIB I see how I expected it to see, namely when t11FcSpPoSwConnAllowedNameType and t11FcSpPoSwConnAllowedName are bing used. And in this case it has the same subtypes as above. So t11FcSpPoSwConnAllowedName OBJECT-TYPE SYNTAX T11FcSpPolicyName Could possibly be changed to t11FcSpPoSwConnAllowedName OBJECT-TYPE SYNTAX T11FcSpPolicyName (SIZE (8)) In any event, here we see already inconsistency within the same MIB Module. - I see: t11FcSpPoIpMgmtEntryNameType OBJECT-TYPE SYNTAX InetAddressType MAX-ACCESS not-accessible STATUS current DESCRIPTION "The combination of t11FcSpPoIpMgmtNameType, t11FcSpPoIpMgmtNameLow and t11FcSpPoIpMgmtNameHigh specify the IP Address range of this IP Management Entry in the IP Management List Object. The FC-SP specification does not allow the use of a DNS domain name to specify the address at the lower end or at the higher end of the IP Address range, nor does it allow the specification of a zone index. Therefore, the type of address must be one of: 'ipv4', or 'ipv6'." You are not using MUST (as in RFC2119), yet, when I read Therefore, the type of address must be one of: 'ipv4', or 'ipv6' then I think I would subtype the SYNTAX as SYNTAX InetAddressType (ipv4(1), ipv6(2)) That makes the requirement machine readable. By using t11FcSpPoIpMgmtEntryNameLow OBJECT-TYPE SYNTAX InetAddress (SIZE(4 | 16)) You basically do the same. - When I read t11FcSpPoWkpDescrDestPort OBJECT-TYPE SYNTAX Unsigned32 (0..65535) and its DESCRIPTION clause, I wonder why you do not use InetPortNumber TC?? - I am surprised/confused by this: t11FcSpPoWkpDescrWkpNumber OBJECT-TYPE SYNTAX Unsigned32 (0..255) MAX-ACCESS read-only STATUS current DESCRIPTION "When the 'wkpWildcard' bit is set in the corresponding instance of t11FcSpPoWkpDescrFlags, this object specifies the IP protocol number of the Well-Known Protocol." REFERENCE "- INCITS xxx/200x, T11/Project 1570-D/Rev 1.8, Fibre Channel - Security Protocols (FC-SP), 13 June 2006, section 7.1.7.1 and table 131. - http://www.iana.org/assignments/protocol-numbers." In those protocol numbers listed at IANA, is there any other protocol that one would sensibly use except TCP and UDP ??? I do see that you just represent what table 130 (not 131) on page 138 in the T11 document shows. I still find it strange - For this t11FcSpPoAttribExtension OBJECT-TYPE SYNTAX OBJECT IDENTIFIER MAX-ACCESS read-only STATUS current DESCRIPTION "For some types of Attribute Policy Object, the value of this MIB object points to type-specific MIB objects which contain individual/broken-out parts of the Attribute Policy Object's value. If this object doesn't point to such type-specific MIB objects, then it contains the value: zeroDotZero. In particular, when the value of t11FcSpPoAttribType indicates 'AUTH_Negotiate Message Payload', one or more Authentication Protocol Identifiers and their associated Authentication Protocol Parameters are embedded within the value of the corresponding instance of t11FcSpPoAttribValue; MIB objects to contain these individual values are defined in the t11FcSpPoAuthProtTable. Thus, for an 'AUTH_Negotiate Message Payload' Attribute, the value of this object contains the OID of t11FcSpPoAuthProtTable." Is it really the idea that you would point to the table, or would you rather point to the relevant first part of t11FcSpPoAuthProtParams Some of the above comments apply equally well to the Non-Active Policy Objects. I won't repeat them. - I see: t11FcSpPoNaSummaryHashStatus OBJECT-TYPE SYNTAX INTEGER { calculate(1), correct(2), stale(3) } MAX-ACCESS read-create STATUS current DESCRIPTION "When read, the value of this object is either: correct -- the corresponding instance of t11FcSpPoNaSummaryHashValue contains the correct value; or stale -- the corresponding instance of t11FcSpPoNaSummaryHashValue contains a stale (possibly incorrect) value; Writing a value of 'calculate' is a request to re-calculate and update the value of the corresponding instance of t11FcSpPoNaSummaryHashValue. Writing a value of 'correct' or 'stale' to this object is a ('wrongValue') error." DEFVAL { stale } And the STorageType object t11FcSpPoStorageType that is controlling this table entry states: Even if an instance of this object has the value 'permanent(4)', none of the information defined in this MIB module for the given Fabric needs to be writable." So how does a stale value for a permanent row get re-calculated? - For your counters, you write: This counter has no discontinuities other than those which all Counter32's have when sysUpTime=0." So if the instrumentation restarts, it keeps track of the values? Of is the instrunmentation alsways a monolithic entity together with the main/master SNMP agent? Bert Wijnen _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Sat Dec 29 06:53:42 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8aG0-0004zk-Qo; Sat, 29 Dec 2007 06:53:36 -0500 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1J8aFz-0004zC-Eg for imss-confirm+ok@megatron.ietf.org; Sat, 29 Dec 2007 06:53:35 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8aFz-0004yz-4Z for imss@ietf.org; Sat, 29 Dec 2007 06:53:35 -0500 Received: from relay.versatel.net ([62.250.3.110]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J8aFx-000585-FM for imss@ietf.org; Sat, 29 Dec 2007 06:53:35 -0500 Received: (qmail 34044 invoked from network); 29 Dec 2007 11:53:31 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 29 Dec 2007 11:53:31 -0000 From: "Bert Wijnen - IETF" To: Date: Sat, 29 Dec 2007 12:53:40 +0100 Message-ID: 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: 3002fc2e661cd7f114cb6bae92fe88f1 Cc: Dan Romascanu , Keith McCloghrie , Black_David Subject: [imss] MIB doctor review for: T11-FC-SP-SA-MIB X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: imss-bounces@ietf.org [bcc to mib doctors] This is a review of the module as extracted from the prelimenary draft-ietf-imss-fc-fcsp-mib-01.txt document - I see: t11FcSpSaMIB MODULE-IDENTITY LAST-UPDATED "200702190000Z" ORGANIZATION "T11" I think that IETF IMSS WG should be included as one of the ORGANIZATIONs that worked on this MIB module - Similar question w.r.t. discontinuity of timers as in my earlier MIB reviews yesterday - t11FcSpSaPropSecurityProt OBJECT-TYPE SYNTAX INTEGER { espHeader(1), ctAuth(2) } I see this SYNTAX 3 times. Possibly candidate for a TC. Just a subjective thought. - FOr t11FcSpSaPropTSelListIndex and t11FcSpSaPropTransListIndex, I assume that a zero value means that there is no such list? Although from the DESCRIPTION clause of the t11FcSpSaPropRowStatus object I get the impression that a row with a zero value for either of these 2 objects cannot be made active. So maybe zero is not a valid value? - For t11FcSpSaTSelPropEntry I am a bit confused by: The StorageType of a row in this table is specified by the instance of t11FcSpSaIfStorageType which is INDEX-ed by the same values of fcmInstanceIndex, t11FcSpSaIfIndex and t11FcSpSaIfFabricIndex." INDEX { fcmInstanceIndex, t11FcSpSaIfIndex, t11FcSpSaTSelPropListIndex, t11FcSpSaTSelPropIndex } The t11FcSpSaIfFabricIndex is not part of this INDEX clause, is it? So how can it be the same? - Same question for t11FcSpSaTransEntry - I think that for t11FcSpSaPairTransListIndex and t11FcSpSaPairTransIndex a vlue of zero is impossible (or makes no sense). If I am correct you may want to exclude that via a RANGE spec. - I have seen thos combination multipel times (in the set of MIB modules) t11FcSpSaPairLifetimeLeft OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS read-only STATUS current DESCRIPTION "The remaining lifetime of this SA pair, given in the units specified by the value of the corresponding instance of t11FcSpSaPairLifetimeLeft." ::= { t11FcSpSaPairEntry 6 } t11FcSpSaPairLifetimeLeftUnits OBJECT-TYPE SYNTAX INTEGER { seconds(1), -- seconds kiloBytes(2), -- 10^^3 bytes megaBytes(3), -- 10^^6 bytes gigaBytes(4), -- 10^^9 bytes teraBytes(5), -- 10^^12 bytes petaBytes(6), -- 10^^15 bytes exaBytes(7), -- 10^^18 bytes zettaBytes(8), -- 10^^21 bytes yottaBytes(9) -- 10^^24 bytes } Possibel candidates for a TC? - I have seen t11FcSpSaPairTerminate OBJECT-TYPE SYNTAX INTEGER { noop(1), terminate(2) } That SYNTAX a few times. Candidate for a TC? Bert Wijnen _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Sat Dec 29 09:01:20 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8cFb-0003L8-Vf; Sat, 29 Dec 2007 09:01:20 -0500 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1J8cFX-0003BY-Qi for imss-confirm+ok@megatron.ietf.org; Sat, 29 Dec 2007 09:01:15 -0500 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J8cFX-0003Af-6s for imss@ietf.org; Sat, 29 Dec 2007 09:01:15 -0500 Received: from relay.versatel.net ([62.250.3.110]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1J8cFV-0001DC-KJ for imss@ietf.org; Sat, 29 Dec 2007 09:01:15 -0500 Received: (qmail 82886 invoked from network); 29 Dec 2007 14:01:11 -0000 Received: from unknown (HELO bwMedion) (87.215.199.34) by relay.versatel.net with SMTP; 29 Dec 2007 14:01:11 -0000 From: "Bert Wijnen - IETF" To: Date: Sat, 29 Dec 2007 15:01:20 +0100 Message-ID: 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: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: Dan Romascanu , Keith McCloghrie , Black_David Subject: [imss] MIB doctor review for T11-FC-SP-ZONING-MIB X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: imss-bounces@ietf.org [bcc to mib doctors] This is a review of the module as extracted from the prelimenary draft-ietf-imss-fc-fcsp-mib-01.txt document - I see: t11FcSpZoningMIB MODULE-IDENTITY LAST-UPDATED "200702190000Z" ORGANIZATION "T11" I think that IETF IMSS WG should be included as one of the ORGANIZATIONs that worked on this MIB module - I have seen t11FcSpZoneSetHashStatus OBJECT-TYPE SYNTAX INTEGER { calculate(1), correct(2), stale(3) } That SYNTAX a number of times in the set of MIB modules. Candidate for a TC? - FOr that same object, I wonder how a re-calculate can be done for a permanent row, since the storage type states: If an instance of this object has the value 'permanent(4)', the Zone Set database for the given fabric on the given switch is not required to be writeable." - Same question about counter discontinuities as in my earlier MIB reviews yesterday. Bert Wijnen _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Mon Dec 31 11:52:34 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9NsM-0006yW-QQ; Mon, 31 Dec 2007 11:52:30 -0500 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1J9NsL-0006yP-Kj for imss-confirm+ok@megatron.ietf.org; Mon, 31 Dec 2007 11:52:29 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9NsL-0006yH-8f for imss@ietf.org; Mon, 31 Dec 2007 11:52:29 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J9NsK-0001Cv-BU for imss@ietf.org; Mon, 31 Dec 2007 11:52:29 -0500 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 31 Dec 2007 08:52:27 -0800 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id lBVGqRIr021274; Mon, 31 Dec 2007 08:52:27 -0800 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id lBVGqQ2T010205; Mon, 31 Dec 2007 16:52:27 GMT Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id IAA04108; Mon, 31 Dec 2007 08:50:21 -0800 (PST) From: Keith McCloghrie Message-Id: <200712311650.IAA04108@cisco.com> To: bertietf@bwijnen.net (Bert Wijnen - IETF) Date: Mon, 31 Dec 2007 08:50:21 -0800 (PST) In-Reply-To: from "Bert Wijnen - IETF" at Dec 28, 2007 04:29:27 PM X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4134; t=1199119947; x=1199983947; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kzm@cisco.com; z=From:=20Keith=20McCloghrie=20 |Subject:=20Re=3A=20MIB=20doctor=20review=20for=20T11-FC-SP -AUTHENTICATION-MIB |Sender:=20; bh=f4GKsiOcPBV7w4wxngIsSiu/2DnzpcV+R1iY0+jsPZ8=; b=OP7jIa3/9q6PWJxGD5h7XeTmJ3+zYNDlBYezuVZofx0nL03Lkw0uDa4wMB zFeoWgxd2bXe0zBXXz4Mp0rb+lAikoCqr++FpzxZ9bJFwss9l33Z/yANs63r cpRcoLcmjd; Authentication-Results: sj-dkim-3; header.From=kzm@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: imss@ietf.org, Dan Romascanu , Keith McCloghrie , Black_David Subject: [imss] Re: 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 List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: imss-bounces@ietf.org Hi Bert, Thanks for your reviews. Here is my response to the first: > 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 Done. > - 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. Done. > - 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. Section 5.3.3 of FC-SP restricts the length to 8 bytes, so I believe the restriction is correct. I will add section 5.3.3 to the REFERENCE clause. > - 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? I'm saying is that sysUpTime gets reset to zero in any MIB view which includes this MIB whenever this Counter32 has a discontinutity. Yes, this can achieved by "a monolithic entity" and by "persistent storage of the value" but it can also be achieved in other ways as well. The alternative is to define one or more additional discontinuity timestamps. The number (of these additional timestamps) required is dependent on the architecture of the implementation. One possibility would be to add a TimeStamp object to fcmInstanceTable (defined in RFC 4044), but if we were going to do that, I think we should have done it three years ago, before RFCs 4438, 4439, 4625, 4626, 4747, 4935, 4936 and 4983 were approved without referencing such a TimeStamp object. Thanks, Keith. PS. I'll make the updated document available after I've responded to your other reviews. _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss From imss-bounces@ietf.org Mon Dec 31 15:24:38 2007 Return-path: Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9RBe-0005hH-AC; Mon, 31 Dec 2007 15:24:38 -0500 Received: from imss by megatron.ietf.org with local (Exim 4.43) id 1J9RBd-0005h7-A1 for imss-confirm+ok@megatron.ietf.org; Mon, 31 Dec 2007 15:24:37 -0500 Received: from [10.90.34.44] (helo=chiedprmail1.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1J9RBc-0005gz-Ti for imss@ietf.org; Mon, 31 Dec 2007 15:24:37 -0500 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1J9RBb-0005ki-2W for imss@ietf.org; Mon, 31 Dec 2007 15:24:36 -0500 Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 31 Dec 2007 12:24:34 -0800 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id lBVKOYPP016042; Mon, 31 Dec 2007 12:24:34 -0800 Received: from cisco.com (pita.cisco.com [171.71.177.199]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id lBVKOXsm014220; Mon, 31 Dec 2007 20:24:33 GMT Received: (from kzm@localhost) by cisco.com (8.8.8-Cisco List Logging/8.8.8) id MAA10683; Mon, 31 Dec 2007 12:22:28 -0800 (PST) From: Keith McCloghrie Message-Id: <200712312022.MAA10683@cisco.com> To: bertietf@bwijnen.net (Bert Wijnen - IETF) Date: Mon, 31 Dec 2007 12:22:28 -0800 (PST) In-Reply-To: from "Bert Wijnen - IETF" at Dec 29, 2007 12:58:54 AM X-Mailer: ELM [version 2.5 PL5] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=13968; t=1199132674; x=1199996674; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=kzm@cisco.com; z=From:=20Keith=20McCloghrie=20 |Subject:=20Re=3A=20MIB=20Doctor=20review=20for=3A=20=20T11 -FC-SP-POLICY-MIB |Sender:=20; bh=xoCN2Hl6DmwjJdsPLq6wwNopMtDP3oO1DG7SIMpis88=; b=CLh3KHfG1ZsjjC9/99iULfmYWTOD2+s9tsB0IJvuQOz2E8jga1oHhZY+Fc 1xmMjwa9YiUAx1PF+M7zVarT1IKxX8jRT87FYVBO5vSHbSczHUVT6bjVuUO9 XlaZlpGBTkMKGBw22VdU3EpursT6UMCQJAIx5IkXIZc0zg7RHFB9w=; Authentication-Results: sj-dkim-1; header.From=kzm@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); X-Spam-Score: 0.0 (/) X-Scan-Signature: 90e8b0e368115979782f8b3d811b226b Cc: imss@ietf.org, Dan Romascanu , Black_David , Keith McCloghrie Subject: [imss] Re: MIB Doctor review for: T11-FC-SP-POLICY-MIB X-BeenThere: imss@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Internet and Management Support for Storage Working Group List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: imss-bounces@ietf.org Bert, > This is a review of the module as extracted from the > prelimenary draft-ietf-imss-fc-fcsp-mib-01.txt document > > - I see: > > t11FcSpPolicyMIB MODULE-IDENTITY > LAST-UPDATED "200702190000Z" > ORGANIZATION "T11" > > I think that IETF IMSS WG should be included as one of > the ORGANIZATIONs that worked on this MIB module Done. > - I see: > > t11FcSpPoAdminFabricName OBJECT-TYPE > SYNTAX FcNameIdOrZero (SIZE (8)) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The administratively-specified name for this Fabric, as > specified in the active Switch Membership List Object. > This value is meaningful only when Static Domain_IDs are > in use in a Fabric (see FC-SW-4). Static Domain_IDs are > administratively enabled by a setting of the Switch Flags > in each Switch Entry in the Switch Membership List Object. > If Static Domain_IDs are not in use, this value might be > '0000000000000000'h. > > The t11FamEnable, t11FamFabricName and > t11FamConfigDomainIdType objects defined in the > T11-FC-FABRIC-ADDR-MGR-MIB module are also concerned with > the use of an administratively-specified name for a Fabric > and Static Domain_IDs. When FC-SP Policy is in use in a > Fabric, the values of t11FamEnable, t11FamFabricName and > t11FamConfigDomainIdType must be read-only and reflect the > active Policy Objects. For example, the value of > t11FamFabricName must reflect the value of > t11FcSpPoAdminFabricName." > > And I then wonder if the SIZE (8) is indeed intended or if it ought > to be SIZE (8 | 16). Table 108 of FC-SP (which in this case is listed in the REFERENCE clause) limits the size to 8 bytes. > Futher, when reading the restrinctions on t11FamEnable, t11FamFabricName > and t11FamConfigDomainIdType that this MIB module imposes on another > MIB module, I wonder > - is that for all entries in the t11FamTable? In other words, once > you use the POLICY-MIB, would it apply to all Fabrics, or just to the > ones fro which there are entries in this Table. Just the ones which reference Fabrics which have entries in this table. > - And is that a "must be read-only" a dynamic thing? In other words, > once an Active Policy gets deactivated, doe the objects in the > t11FamTable then become read-write again? Yes. > - Depending on the answers, would it make sense to add more to the > DESCRIPTION clause? I think the phrase "When FC-SP Policy is in use in a Fabric," is a concise way of stating when (and for which instances) the dependence exists. > - Depending on the answers, would it make sense to IMPORT these > obecjts and use them in the MODULE-CONFORMANCE to indicate that > MAX-ACCESS is read-only ?? I think the relationship is on a per-instance basis, i.e., if FC-SP Policy is only being used on some (virtual) Fabrics, then only some of the t11FamXxxx objects must be read-only. However, consideration of your comment exposes two related issues: The first is that there's a minor flaw in RFC 4439, in that a MIN-ACCESS clause is defined for t11FamConfigDomainIdType but did not get added (as it should have) for t11FamEnable and t11FamFabricName. In other words, I think fixing RFC 4439 would be the way to address your comment (even though that probably won't happen). The second is that t11FcSpPoAdminFabricNameis read-only, as indeed it must be because it's part of the Active Policy which cannot be modified once it's active. So, how is the Fabric name specified when Policy is in use ?? I believe the answer is that t11FcSpPoNaSummaryFabricName needs to be added as a read-create object in the t11FcSpPoNaSummaryTable. If the WG agrees, then I will add this new object. > - I find this a bit confusing: > > t11FcSpPoSummaryPolicyType OBJECT-TYPE > SYNTAX T11FcSpPolicyObjectType > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "The 'Identifier' which specifies the type of this > Policy Object." > > It is just the "type" is it not? ANd it is indicated by the valu of this > object whioch is an enumeration. So wht is the 'Identifier'? > Why no just say: > > DESCRIPTION > "The type of this Policy Object." I used "'Identifier'" because that it is the term used in FC-SP. I too believe think it is confusing, but it is a type, because the REFERENCE clause lists section 7.1.3.1 which says: Policy Object Identifier fields: the identifier of a Policy Object (see table 102). and table 102 enumerates the six possible values. (I guess that for those types which have at most one active policy object, the type can be used as an implicit identifier.) Would you prefer the DESCRIPTION to say: "The 'Identifier' (i.e., the type) of this Policy Object." > - When I read (in the TC-MIB about T11FcSpPolicyNameType and > T11FcSpPolicyName, > I sort of assumed/thought that these two would always be used in > combination. > However in this POLICY-MIB I see the T11FcSpPolicyNameType (subtypef in > OBJECT-TYPE t11FcSpPoSwMembSwitchNameType) being used together with: > t11FcSpPoSwMembSwitchName OBJECT-TYPE > SYNTAX FcNameIdOrZero (SIZE (8)) > Is that not at least somewhat weird and possibly confusing? > I can see that it is not absolutely flawed, but I am not sure we want to > do this sort of thing, do we? > > Further in the POLICY-MIB I see how I expected it to see, namely when > t11FcSpPoSwConnAllowedNameType and t11FcSpPoSwConnAllowedName are bing > used. > And in this case it has the same subtypes as above. So > t11FcSpPoSwConnAllowedName OBJECT-TYPE > SYNTAX T11FcSpPolicyName > Could possibly be changed to > t11FcSpPoSwConnAllowedName OBJECT-TYPE > SYNTAX T11FcSpPolicyName (SIZE (8)) > > In any event, here we see already inconsistency within the same MIB > Module. You are correct. I'll fix it such that: SYNTAX T11FcSpPolicyName (SIZE (8)) is used consistently in these situations. > - I see: > > t11FcSpPoIpMgmtEntryNameType OBJECT-TYPE > SYNTAX InetAddressType > MAX-ACCESS not-accessible > STATUS current > DESCRIPTION > "The combination of t11FcSpPoIpMgmtNameType, > t11FcSpPoIpMgmtNameLow and t11FcSpPoIpMgmtNameHigh > specify the IP Address range of this IP Management > Entry in the IP Management List Object. > > The FC-SP specification does not allow the use of a > DNS domain name to specify the address at the lower end > or at the higher end of the IP Address range, nor does it > allow the specification of a zone index. Therefore, the > type of address must be one of: 'ipv4', or 'ipv6'." > > You are not using MUST (as in RFC2119), yet, when I read > > Therefore, the > type of address must be one of: 'ipv4', or 'ipv6' > > then I think I would subtype the SYNTAX as > > SYNTAX InetAddressType (ipv4(1), ipv6(2)) > > That makes the requirement machine readable. > By using > > t11FcSpPoIpMgmtEntryNameLow OBJECT-TYPE > SYNTAX InetAddress (SIZE(4 | 16)) > > You basically do the same. You haven't mentioned t11FcSpPoNaIpMgmtEntryNameType, which is defined like this: t11FcSpPoNaIpMgmtEntryNameType OBJECT-TYPE SYNTAX InetAddressType -- INTEGER { ipv4(1), ipv6(2) } where the subtype is put in an ASN.1 comment as a convenience for developers because it avoids the compile error which SMICng generates for "InetAddressType (ipv4(1), ipv6(2))". So, I suggest I add the same ASN.1 comment for t11FcSpPoIpMgmtEntryNameType. > - When I read > t11FcSpPoWkpDescrDestPort OBJECT-TYPE > SYNTAX Unsigned32 (0..65535) > and its DESCRIPTION clause, I wonder why you do not use InetPortNumber > TC?? I will change it. > - I am surprised/confused by this: > > t11FcSpPoWkpDescrWkpNumber OBJECT-TYPE > SYNTAX Unsigned32 (0..255) > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "When the 'wkpWildcard' bit is set in the corresponding > instance of t11FcSpPoWkpDescrFlags, this object specifies > the IP protocol number of the Well-Known Protocol." > REFERENCE > "- INCITS xxx/200x, T11/Project 1570-D/Rev 1.8, > Fibre Channel - Security Protocols (FC-SP), 13 June 2006, > section 7.1.7.1 and table 131. > - http://www.iana.org/assignments/protocol-numbers." > > In those protocol numbers listed at IANA, is there any other protocol > that one would sensibly use except TCP and UDP ??? > I do see that you just represent what table 130 (not 131) on page 138 > in the T11 document shows. I still find it strange As you note, the intent was to reproduce what FC-SP allows, and that does have the future potential of an SCTP-based protocol. > - For this > > t11FcSpPoAttribExtension OBJECT-TYPE > SYNTAX OBJECT IDENTIFIER > MAX-ACCESS read-only > STATUS current > DESCRIPTION > "For some types of Attribute Policy Object, the value of > this MIB object points to type-specific MIB objects which > contain individual/broken-out parts of the Attribute Policy > Object's value. If this object doesn't point to such > type-specific MIB objects, then it contains the value: > zeroDotZero. > > In particular, when the value of t11FcSpPoAttribType > indicates 'AUTH_Negotiate Message Payload', one or more > Authentication Protocol Identifiers and their associated > Authentication Protocol Parameters are embedded within the > value of the corresponding instance of t11FcSpPoAttribValue; > MIB objects to contain these individual values are defined > in the t11FcSpPoAuthProtTable. Thus, for an 'AUTH_Negotiate > Message Payload' Attribute, the value of this object > contains the OID of t11FcSpPoAuthProtTable." > > Is it really the idea that you would point to the table, or would > you rather point to the relevant first part of t11FcSpPoAuthProtParams This pointer needs to apply generically in any/all cases, and so its definition cannot be too specific. E.g., for the example given in the DESCRIPTION, it needs to point to "one or more ... Identifiers and ...". So, I think the problem you've identified is that the example is too specific. How about I fix it like this: .... Thus, for an 'AUTH_Negotiate Message Payload' Attribute, the value of this object contains an OID within the t11FcSpPoAuthProtTable, e.g., of the whole table, of an individual row, or of an individual instance within the table." > Some of the above comments apply equally well to the Non-Active Policy > Objects. I won't repeat them. > > - I see: > > t11FcSpPoNaSummaryHashStatus OBJECT-TYPE > SYNTAX INTEGER { > calculate(1), > correct(2), > stale(3) > } > MAX-ACCESS read-create > STATUS current > DESCRIPTION > "When read, the value of this object is either: > > correct -- the corresponding instance of > t11FcSpPoNaSummaryHashValue contains > the correct value; or > stale -- the corresponding instance of > t11FcSpPoNaSummaryHashValue contains > a stale (possibly incorrect) value; > > Writing a value of 'calculate' is a request to re-calculate > and update the value of the corresponding instance of > t11FcSpPoNaSummaryHashValue. Writing a value of 'correct' > or 'stale' to this object is a ('wrongValue') error." > DEFVAL { stale } > > And the STorageType object t11FcSpPoStorageType that is controlling this > table entry states: > Even if an instance of this object has the value > 'permanent(4)', none of the information defined in > this MIB module for the given Fabric needs to be > writable." > > So how does a stale value for a permanent row get re-calculated? A hash value only becomes 'stale' after a modification of the Policy object(s) for which it is the hash value. (The intent of havign this separate object is so that teh hash doesn't have to be re-calculated after each and every modification of multiple Policy Objects.) So, for Policy objects in a 'permanent(4)' row, their hash value will be 'correct' permanently. > - For your counters, you write: > > This counter has no discontinuities other than those > which all Counter32's have when sysUpTime=0." > > So if the instrumentation restarts, it keeps track of the values? > Of is the instrunmentation alsways a monolithic entity together with > the main/master SNMP agent? Not necessarily. See my response to your same comment for the previous MIB module. Thanks, Keith. _______________________________________________ imss mailing list imss@ietf.org https://www1.ietf.org/mailman/listinfo/imss