[Ips] iSCSI Corrections/Clarifications Publication Request
Black_David@emc.com Fri, 23 February 2007 21:36 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKi5k-0006vQ-PY; Fri, 23 Feb 2007 16:36:36 -0500
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1HKi5i-0006t1-RU for ips@ietf.org; Fri, 23 Feb 2007 16:36:34 -0500
Received: from mexforward.lss.emc.com ([128.222.32.20]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1HKi5h-0000CK-CU for ips@ietf.org; Fri, 23 Feb 2007 16:36:34 -0500
Received: from mailhub.lss.emc.com (uraeus.lss.emc.com [10.254.144.14]) by mexforward.lss.emc.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id l1NLaXAi012326 for <ips@ietf.org>; Fri, 23 Feb 2007 16:36:33 -0500 (EST)
Received: from corpussmtp3.corp.emc.com (corpussmtp3.corp.emc.com [10.254.64.53]) by mailhub.lss.emc.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id l1NLa1Rx010747 for <ips@ietf.org>; Fri, 23 Feb 2007 16:36:31 -0500 (EST)
From: Black_David@emc.com
Received: from CORPUSMX20A.corp.emc.com ([128.221.62.11]) by corpussmtp3.corp.emc.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Feb 2007 16:36:28 -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, 23 Feb 2007 16:36:27 -0500
Message-ID: <F222151D3323874393F83102D614E055068B8F03@CORPUSMX20A.corp.emc.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: iSCSI Corrections/Clarifications Publication Request
Thread-Index: AcdXkqznQZK/7UsRR+6clBQdSMv8Ew==
To: ips@ietf.org
X-OriginalArrivalTime: 23 Feb 2007 21:36:28.0536 (UTC) FILETIME=[AD295F80:01C75792]
X-PMX-Version: 4.7.1.128075, Antispam-Engine: 2.5.0.283055, Antispam-Data: 2007.2.23.125934
X-PerlMx-Spam: Gauge=, SPAM=2%, Reason='EMC_FROM_0+ -2, NO_REAL_NAME 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CTYPE_CHARSET_QUOTED 0, __CT_TEXT_PLAIN 0, __HAS_MSGID 0, __IMS_MSGID 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0'
X-Spam-Score: 0.2 (/)
X-Scan-Signature: 7a0494a0224ca59418dd8f92694c1fdb
Cc: Black_David@emc.com
Subject: [Ips] iSCSI Corrections/Clarifications Publication Request
X-BeenThere: ips@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IP Storage <ips.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ips>, <mailto:ips-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ips@ietf.org>
List-Help: <mailto:ips-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ips>, <mailto:ips-request@ietf.org?subject=subscribe>
Errors-To: ips-bounces@ietf.org
Publication of the iSCSI Corrections and Clarifications draft as a Proposed Standard RFC has been requested. Here's the PROTO writeup: iSCSI Corrections and Clarifications draft-ietf-ips-iscsi-impl-guide-06.txt Requested Publication Status: Proposed Standard ------------------------------------------------------------------------ (1.a) Who is the Document Shepherd for this document? David L. Black (ips WG Chair) Has the Document Shepherd personally reviewed this version of the document and, in particular, does he or she believe this version is ready for forwarding to the IESG for publication? Yes, mostly. The Document Shepherd has been delayed in reviewing the document, and has a number of comments on the document. The Document Shepherd is comfortable having his review comments treated as initial IETF Last Call comments in order to not further delay publication of this draft, unless the IANA registry issue requires the draft to be revised prior to IETF Last Call - see (1.i) below. (1.b) Has the document had adequate review both from key WG members and from key non-WG members? Yes. Does the Document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No. Portions of this document deal with iSCSI task management and iSCSI error handling, where there are a limited number of individuals with expertise sufficient to perform a thorough review. This document has received sufficient review from such individuals, including the document author and the principal author/editor of RFC 3720, the main iSCSI specification. (1.c) Does the Document Shepherd have concerns that the document needs more review from a particular or broader perspective, e.g., security, operational complexity, someone familiar with AAA, internationalization or XML? No. (1.d) Does the Document Shepherd have any specific concerns or issues with this document that the Responsible Area Director and/or the IESG should be aware of? For example, perhaps he or she is uncomfortable with certain parts of the document, or has concerns whether there really is a need for it. In any event, if the WG has discussed those issues and has indicated that it still wishes to advance the document, detail those concerns here. No. Has an IPR disclosure related to this document been filed? If so, please include a reference to the disclosure and summarize the WG discussion and conclusion on this issue. No. (1.e) How solid is the WG consensus behind this document? Does it represent the strong concurrence of a few individuals, with others being silent, or does the WG as a whole understand and agree with it? The WG as a whole understands and agrees with this document. (1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email messages to the Responsible Area Director. (It should be in a separate email because this questionnaire is entered into the ID Tracker.) No. (1.g) Has the Document Shepherd personally verified that the document satisfies all ID nits? (See http://www.ietf.org/ID-Checklist.html and http://tools.ietf.org/tools/idnits/). Boilerplate checks are not enough; this check needs to be thorough. idnits 2.03.6 finds no problems. Has the document met all formal review criteria it needs to, such as the MIB Doctor, media type and URI type reviews? None are applicable. (1.h) Has the document split its references into normative and informative? Yes. Are there normative references to documents that are not ready for advancement or are otherwise in an unclear state? If such normative references exist, what is the strategy for their completion? No. Are there normative references that are downward references, as described in [RFC3967]? If so, list these downward references to support the Area Director in the Last Call procedure for them [RFC3967]. No, the possible downward reference found by idnits is to a published ANSI standard (T10 SPC-3 is ANSI INCITS 408-2005), and hence is not a concern. (1.i) Has the Document Shepherd verified that the document IANA consideration section exists and is consistent with the body of the document? Yes. If the document specifies protocol extensions, are reservations requested in appropriate IANA registries? Are the IANA registries clearly identified? No, as no such registries exist. The Responsible Area Director and/ or the IESG need to determine whether this draft warrants creation of a set of iSCSI registries based on RFC 3720 and this document. If the document creates a new registry, does it define the proposed initial contents of the registry and an allocation procedure for future registrations? Does it suggest a reasonable name for the new registry? See [RFC2434]. Not applicable. If the document describes an Expert Review process has Shepherd conferred with the Responsible Area Director so that the IESG can appoint the needed Expert during the IESG Evaluation? Not applicable. (1.j) Has the Document Shepherd verified that sections of the document that are written in a formal language, such as XML code, BNF rules, MIB definitions, etc., validate correctly in an automated checker? Not applicable. (1.k) The IESG approval announcement includes a Document Announcement Write-Up. Please provide such a Document Announcement Write-Up? Recent examples can be found in the "Action" announcements for approved documents. The approval announcement contains the following sections: Technical Summary iSCSI is a SCSI transport protocol that maps the SCSI architecture and command sets onto TCP/IP. RFC 3720 defines the iSCSI protocol. This document compiles the clarifications to the original protocol definition in RFC 3720 to serve as a companion document for the iSCSI implementers. This document updates RFC 3720 and the text in this document supersedes the text in RFC 3720 when the two differ. Working Group Summary This document consists of clarification items collected during a period of more than one year based on implementation experience. A number of the items have engendered significant working group discussion about the appropriate clarification or change. The ips WG strongly supports the resulting clarifications and changes in this document. Document Quality There are numerous implementations of iSCSI, and the entire content of this document is based on issues that have arisen from implementation experience. There are a large number of individuals listed in the acknowledgements section who have contributed to this document based on their expertise and/or implementation experience. David Black (ips WG chair) and Julian Satran (RFC 3720 editor) have reviewed this document for the ips WG. Personnel Document Shepherd: David Black (ips WG chair) Responsible Area Director: Lars Eggert (Transport Area) _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips