Re: [imss] AD Review for draft-ietf-imss-fc-fcsp-mib-02.txt
Black_David@emc.com Tue, 10 June 2008 22:49 UTC
Return-Path: <imss-bounces@ietf.org>
X-Original-To: imss-archive@optimus.ietf.org
Delivered-To: ietfarch-imss-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA8B73A6AE0; Tue, 10 Jun 2008 15:49:14 -0700 (PDT)
X-Original-To: imss@core3.amsl.com
Delivered-To: imss@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA87D3A6AA7 for <imss@core3.amsl.com>; Tue, 10 Jun 2008 15:49:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZtKZzo-L1H9h for <imss@core3.amsl.com>; Tue, 10 Jun 2008 15:49:11 -0700 (PDT)
Received: from mexforward.lss.emc.com (mexforward.lss.emc.com [128.222.32.20]) by core3.amsl.com (Postfix) with ESMTP id F17843A6AE0 for <imss@ietf.org>; Tue, 10 Jun 2008 15:49:10 -0700 (PDT)
Received: from hop04-l1d11-si04.isus.emc.com (HOP04-L1D11-SI04.isus.emc.com [10.254.111.24]) by mexforward.lss.emc.com (Switch-3.2.5/Switch-3.1.7) with ESMTP id m5AMnRjC005866 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 18:49:27 -0400 (EDT)
Received: from mailhub.lss.emc.com (sesha.lss.emc.com [10.254.144.12]) by hop04-l1d11-si04.isus.emc.com (Tablus Interceptor); Tue, 10 Jun 2008 18:31:55 -0400
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 m5AMn1vR026422; Tue, 10 Jun 2008 18:49:25 -0400 (EDT)
From: Black_David@emc.com
Received: from CORPUSMX20A.corp.emc.com ([128.221.62.12]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 Jun 2008 18:49:21 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 10 Jun 2008 18:49:20 -0400
Message-ID: <8CC6CEAB44F131478D3A7B429ECACD91016F63B6@CORPUSMX20A.corp.emc.com>
In-Reply-To: <200806061445.HAA25946@cisco.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [imss] AD Review for draft-ietf-imss-fc-fcsp-mib-02.txt
Thread-Index: AcjH5IEPw0kdApDKSyS8sfo2DwF8swDZNaHw
References: <no.id> from "Romascanu, Dan (Dan)" at Jun 05, 2008 04:50:31 PM <200806061445.HAA25946@cisco.com>
To: kzm@cisco.com, dromasca@avaya.com
X-OriginalArrivalTime: 10 Jun 2008 22:49:21.0198 (UTC) FILETIME=[38DC64E0:01C8CB4C]
X-Tablus-Inspected: yes
X-Tablus-Classifications: public
X-Tablus-Action: allow
Cc: imss@ietf.org
Subject: Re: [imss] AD Review for draft-ietf-imss-fc-fcsp-mib-02.txt
X-BeenThere: imss@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Internet and Management Support for Storage Working Group <imss.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/imss>, <mailto:imss-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/imss>
List-Post: <mailto:imss@ietf.org>
List-Help: <mailto:imss-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/imss>, <mailto:imss-request@ietf.org?subject=subscribe>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: imss-bounces@ietf.org
Errors-To: imss-bounces@ietf.org
> > E4. Does the notation INCITS xxx/200x mean that the x values need to be > > filled in? In this case these values should be filled in until the time > > the document is submitted for approval to the IESG, or appropriate RFC > > Editor notes should be created to instruct the RFC Editor what to do. > > Correct. David has provided the instructions to the RFC Editor for > these numbers in previous documents done by this WG. Ok, here goes ... OLD: "INCITS xxx/200x, T11/Project 1570-D/Rev 1.8, Fibre Channel - Security Protocols (FC-SP), 13 June 2006, NEW: "Fibre Channel - Security Protocols (FC-SP), INCITS 426-2007, OLD: " - Fibre Channel - Framing and Signaling-2 (FC-FS-2), INCITS xxx/200x, Project T11/1619-D Rev 1.01, 8 August 2006, NEW: " - Fibre Channel - Framing and Signaling-2 (FC-FS-2), INCITS 424-2007, OLD: [FC-SP] "Fibre Channel - Security Protocols (FC-SP)", ANSI INCITS xxx-2002, http://www.t11.org/t11/stat.nsf/upnum/1570-d, T11/Project 1570-D/Rev 1.8, 13 June 2003. NEW: [FC-SP] "Fibre Channel - Security Protocols (FC-SP)", ANSI INCITS 426-2007, http://www.t11.org/t11/stat.nsf/upnum/1570-d, June 2006. There are multiple instances of each of the first two changes. The third change corrects a reference citation. It looks like we'll need one more version of this draft after IETF Last Call is complete (June 19); these changes can be made at that time. Thanks, --David (imss WG chair) ---------------------------------------------------- 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 ---------------------------------------------------- > -----Original Message----- > From: imss-bounces@ietf.org [mailto:imss-bounces@ietf.org] On > Behalf Of Keith McCloghrie > Sent: Friday, June 06, 2008 10:46 AM > To: dromasca@avaya.com > Cc: imss@ietf.org > Subject: Re: [imss] AD Review for draft-ietf-imss-fc-fcsp-mib-02.txt > > Hi Dan, > > Thanks for your comments. My responses are below. > > > The document is mature and seems stable. As the comments in these review > > are relatively minor or editorial, I recommend sending the document to > > IETF Last Call, and consider these comments as LC comments, to be > > processed and fixed (if necessary) together with other LC comments. > > > > T1. Should not the arrows for Get Policy Summary and Get Policy Objects > > in the diagram in 3.4.4 be bi-directional? > > I think the I-D is correct because the diagram in 3.4.4 is meant to be > a copy of Figure 25 of FC-SP, and indeed it is a faithful copy in > respect to the directions of the "Get Policy Summary and Get Policy > Objects" arrows. So, I think you're asking whether FC-SP has the > arrows in the correct direction(s), and I think the answer to that > question is: the arrows indicate the movement of "data", rather than > of "messages". In other words, a "Get" (with no data) goes in one > direction and a Response (typically with data) to the Get goes in the > reverse direction, So, while the messages are bi-directional, the > diagram has arrows for the "with data", not for the "without data" > direction. > > > T2. The DESCRIPTION clause of the T11FcSpHashCalculationStatus TC - > > 'Writing a value of 'correct' or 'stale' to this object is an error > > ('wrongValue')." As a MIB module could in theory be used with other > > protocols than SNMP a better formulation is 'Writing a value of > > 'correct' or 'stale' to this object is an error (SNMP 'wrongValue' or > > the equivalent in other protocols)." > > If I recall correctly, Bert asked me to include "wrongValue", and you're > correct: I should have done so as an example. I'd prefer to change it > to be: > > 'Writing a value of 'correct' or 'stale' to this object is an > error (e.g., 'wrongValue')." > > (Note that 'worngValue' is not correct for all versions of SNMP.) > > > T3. Why is not T11FcSpAlphaNumName an SnmpAdminName with the appropriate > > size limitation? > > Because section 3.5 of RFC 2579 says: > Note that > this means that the SYNTAX clause of a Textual Convention can not > refer to a previously defined Textual Convention. > > > T4. I do not see storage defined for t11FcSpPoOperTable and no > > storageType object either > > Correct. I don't believe they are not needed because: > > 1. This is a read-write (not read-create) table. > > 2. The two write-able objects in this table are both defined as: > > When read, the value of this object is always the zero- > length string. > > So, new values of these two objects are not persistent even for the > time taken for the SetRequest (e.g., much less than across restarts). > > 3. For the two remaining objects in the table, one is defined to > have the value 'none' when "activation/de-activation has not been > attempted since the last restart of the management system", and > the other is defined to be the zero-length string in that situation. > > > E1. Running idnits results in the following references warnings: > > > > -- Obsolete informational reference (is this intentional?): RFC 2837 > > (Obsoleted by RFC 4044) > > Yes, it's intentional. The text reads: > > The first standardized MIB module for Fibre Channel [RFC2837] was > focussed on Fibre Channel Switches. It was obsoleted by the more > generic Fibre Channel Management MIB [RFC4044] which defines basic > information for Fibre Channel Nodes and Switches, including ... > > > -- No information found for draft-ietf-ipsp-ikeaction-mib-nn - is the name > > correct? > > -- No information found for draft-ietf-ipsp-ipsecaction-mib-nn - is the > > name correct? > > The names are correct because their numbers have been replaced by "nn" > so as to implictly refer to the most recent versions. It was hoped that > these two documents would have progressed in advance of the FC-SP MIB, > but it looks like FC-SP MIB is about to overtake them. The current > text which references them is: > > The management of certificates, Certification Authorities and > Certificate Revocation Lists is the same in Fibre Channel networks as > it is in other networks. Therefore, this document does not define > any MIB objects for such management. Instead, this document assumes > that appropriate MIB objects are defined elsewhere, e.g., in [IPSP- > IPSEC-ACTION] and [IPSP-IKE-ACTION]. > > I don't know of alternate references, and it seems to me better to include > them here rather than not to have any references. What would > you suggest ?? > > > E2. Please expand the following acronyms at first occurrence: HBA, ESP, > > SAID > > HBA - yes, I can expand HBA. > ESP - its first use, as an acronym, is already expanded -- when used as > "ESP_Header" it is the name of a mechanism, i.e., not an acronym. > SAID - is the name of a field in a PDU, i.e., not an acronym. > > > E3. Delete the comment on the SYNTAX line of the T11FcSpPrecedence > > definition > > My preference would be to delete the range *and* the comment because I > think the range by itself is misleading. That is, when I read a syntax > with an explicit range, my instinctive reaction is that a range other > than the default is being specified, which is untrue in this case > (because the default range is being used). However, Bert insisted that > the range be included, and therefore to mitigate the risk of confusion, > I believe that: if the range is necessary, then so is the comment. > However, I will remove the exclamation marks if you wish. > > > E4. Does the notation INCITS xxx/200x mean that the x values need to be > > filled in? In this case these values should be filled in until the time > > the document is submitted for approval to the IESG, or appropriate RFC > > Editor notes should be created to instruct the RFC Editor what to do. > > Correct. David has provided the instructions to the RFC Editor for > these numbers in previous docuemnts done by this WG. > > Keith. _______________________________________________ imss mailing list imss@ietf.org https://www.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)