Network Working Group M. Chadalapaka, Ed.
Request for Comments: 5048 Hewlett-Packard Co.
Updates: 3720 October 2007
Category: Standards Track
Internet Small Computer System Interface (iSCSI)
Corrections and Clarifications
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Abstract
抽象
The Internet Small Computer System Interface (iSCSI) is a SCSI transport protocol and 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.
インターネット小型コンピュータシステムインタフェース（iSCSIは）SCSIトランスポートプロトコルで、TCP / IP上でSCSIアーキテクチャとコマンドセットをマッピングします。 RFC 3720は、iSCSIプロトコルを定義します。この文書では、iSCSI実装のための仲間ドキュメントとして機能するようにRFC 3720の元のプロトコル定義に明確化をコンパイルします。このドキュメントの更新RFC 3720と2が異なる場合、この文書内のテキストは、RFC 3720でテキストを優先します。
Table of Contents
目次
1. Introduction ....................................................3
2. Definitions, Acronyms, and Document Summary .....................3
2.1. Definitions ................................................3
2.2. Acronyms ...................................................4
2.3. Clarifications, Changes, and New Semantics .................5
3. iSCSI Semantics for SCSI Tasks ..................................7
3.1. Residual Handling ..........................................7
3.1.1. Overview ............................................7
3.1.2. SCSI REPORT LUNS and Residual Overflow ..............7
3.2. R2T Ordering ...............................................9
3.3. Model Assumptions for Response Ordering ....................9
3.3.1. Model Description ..................................10
3.3.2. iSCSI Semantics with the Interface Model ...........10
3.3.3. Current List of Fenced Response Use Cases ..........11
4. Task Management ................................................12
4.1. Requests Affecting Multiple Tasks .........................12
4.1.1. Scope of Affected Tasks ............................12
4.1.2. Clarified Multi-Task Abort Semantics ...............13
4.1.3. Updated Multi-Task Abort Semantics .................14
4.1.4. Affected Tasks Shared across RFC 3720 and
FastAbort Sessions .................................16
4.1.5. Implementation Considerations ......................17
4.1.6. Rationale behind the New Semantics .................17
5. Discovery Semantics ............................................19
5.1. Error Recovery for Discovery Sessions .....................19
5.2. Reinstatement Semantics of Discovery Sessions .............19
5.2.1. Unnamed Discovery Sessions .........................20
5.2.2. Named Discovery Sessions ...........................20
5.3. Target PDUs during Discovery ..............................20
6. Negotiation and Others .........................................21
6.1. TPGT Values ...............................................21
6.2. SessionType Negotiation ...................................21
6.3. Understanding NotUnderstood ...............................21
6.4. Outstanding Negotiation Exchanges .........................22
7. iSCSI Error Handling and Recovery ..............................22
7.1. ITT .......................................................22
7.2. Format Errors .............................................22
7.3. Digest Errors .............................................22
7.4. Message Error Checking ....................................23
8. iSCSI PDUs .....................................................23
8.1. Asynchronous Message ......................................23
8.2. Reject ....................................................24
9. Login/Text Operational Text Keys ...............................24
9.1. TaskReporting .............................................24
10. Security Considerations .......................................25
11. IANA Considerations ...........................................26
11.1. iSCSI-Related IANA Registries ............................26
11.2. iSCSI Opcodes ............................................26
11.3. iSCSI Login/Text Keys ....................................28
11.4. iSCSI Asynchronous Events ................................30
11.5. iSCSI Task Management Function Codes .....................31
11.6. iSCSI Login Response Status Codes ........................32
11.7. iSCSI Reject Reason Codes ................................34
11.8. iSER Opcodes .............................................35
12. References ....................................................36
12.1. Normative References .....................................36
12.2. Informative References ...................................36
Acknowledgements ..................................................37
Several iSCSI implementations have been built since [RFC3720] was published and the iSCSI community is now richer by the resulting implementation expertise. The goal of this document is to leverage this expertise both to offer clarifications to the [RFC3720] semantics and to address defects in [RFC3720] as appropriate. This document intends to offer critical guidance to implementers with regard to non-obvious iSCSI implementation aspects so as to improve interoperability and accelerate iSCSI adoption. This document, however, does not purport to be an all-encompassing iSCSI how-to guide for implementers, nor a complete revision of [RFC3720]. Instead, this document is intended as a companion document to [RFC3720] for the iSCSI implementers.
[RFC3720]が公開され、iSCSIのコミュニティは今やその結果、実装の専門知識により、より豊かでたので、いくつかのiSCSI実装が構築されています。このドキュメントの目標は、[RFC3720]の意味に明確化を提供し、必要に応じて、[RFC3720]の欠陥に対処するために、両方の、この専門知識を活用することです。この文書では、相互運用性を向上し、iSCSIの採用を加速するように非自明のiSCSI実装の側面に関して、実装者への重要な指針を提供する予定。この文書では、しかし、どのように-する実装のためのガイドのすべての包括的なのiSCSI、また[RFC3720]の完全な改定であることを意味しません。代わりに、この文書はのiSCSI実装のための[RFC3720]への仲間ドキュメントとして意図されています。
iSCSI implementers are required to reference [RFC3722] and [RFC3723] in addition to [RFC3720] for mandatory requirements. In addition, [RFC3721] also contains useful information for iSCSI implementers. The text in this document, however, updates and supersedes the text in [RFC3720] whenever there is such a question.
iSCSI実装は、必須の要件のために[RFC3720]に加えて、[RFC3722]及び[RFC3723]を参照するために必要とされます。また、[RFC3721]ものiSCSI実装のために有用な情報を含んでいます。この文書内のテキストは、しかし、アップデートおよび[RFC3720]にテキストがあるたびに、このような質問を優先します。
I/O Buffer A buffer that is used in a SCSI Read or Write operation so SCSI data may be sent from or received into that buffer. For a read or write data transfer to take place for a task, an I/O Buffer is required on the initiator and at least one is required on the target.
I / OバッファSCSIデータから送られてきたか、そのバッファ内に受信することができるようにSCSI読み取りに使用されるか、または操作を書いているバッファ。読み取りまたはタスクに対して、場所を取るために、データ転送を書き、I / Oバッファは、開始剤に必要とされ、少なくとも一つは、ターゲット上で必要とされます。
SCSI-Presented Data Transfer Length (SPDTL) SPDTL is the aggregate data length of the data that the SCSI layer logically "presents" to the iSCSI layer for a Data-In or Data-Out transfer in the context of a SCSI task. For a bidirectional task, there are two SPDTL values -- one for Data-In and one for Data-Out. Note that the notion of "presenting" includes immediate data per the data transfer model in [SAM2], and excludes overlapping data transfers, if any, requested by the SCSI layer.
SCSI-提示されたデータ転送長（SPDTL）SPDTLは、データの集計データ長であるデータインまたはSCSIタスクのコンテキストでのデータアウト転送用のiSCSI層に論理的にSCSI層「プレゼント」。データイン用とデータ出力のための1 - 双方向のタスクでは、2つのSPDTL値があります。 [SAM2]のデータ転送モデルごとに即値データを含み、データ転送を重複除外は、もしあれば、SCSI層により要求された「提示」の概念ことに留意されたいです。
Third-party A term used in this document to denote nexus objects (I_T or I_T_L) and iSCSI sessions that reap the side effects of actions that take place in the context of a separate iSCSI session, while being third parties to the action that caused the side effects. One example of a third-party session is an iSCSI session hosting an I_T_L nexus to an LU that is reset with an LU Reset TMF via a separate I_T nexus.
サードパーティの原因となったアクションに第三者にありながら、ネクサスオブジェクト（I_TまたはI_T_L）と独立したiSCSIセッションのコンテキスト内で行われたアクションの副作用を享受iSCSIセッションを示すために、このドキュメントで使用される用語副作用。サードパーティセッションの一例は、LU別I_Tネクサスを介しTMFをリセットしてリセットされるLUにI_T_LネクサスをホストiSCSIセッションです。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Acronym Definition
-------------------------------------------------------------
EDTL Expected Data Transfer Length
EDTL予想データ転送長
IANA Internet Assigned Numbers Authority
IANAインターネット割り当て番号機関
IETF Internet Engineering Task Force
IETFインターネットエンジニアリングタスクフォース
I/O Input - Output
I / O入力 - 出力
IP Internet Protocol
IPインターネットプロトコル
iSCSI Internet SCSI
iSCSIのインターネットSCSI
iSER iSCSI Extensions for RDMA
RDMAのためのiSER iSCSIの機能拡張
ITT Initiator Task Tag
ITTイニシエータタスクタグ
LO Leading Only
LOのみをリード
LU Logical Unit
LU論理ユニット
LUN Logical Unit Number
LUN論理ユニット番号
PDU Protocol Data Unit
PDUプロトコルデータユニット
RDMA Remote Direct Memory Access
RDMAリモートダイレクトメモリアクセス
R2T Ready To Transfer
転送するR2T準備
R2TSN Ready To Transfer Sequence Number
シーケンス番号を転送する準備ができてR2TSN
RFC Request For Comments
コメントのRFCリクエスト
SAM SCSI Architecture Model
SAM SCSIアーキテクチャモデル
SCSI Small Computer Systems Interface
SCSI小型コンピュータシステムインタフェース
SN Sequence Number
SNシーケンス番号
SNACK Selective Negative Acknowledgment - also Sequence Number Acknowledgement for data
SNACK選択否定応答 - データのためにもシーケンス番号謝辞
TCP Transmission Control Protocol
TCP伝送制御プロトコル
TMF Task Management Function
TMFタスク管理機能
TTT Target Transfer Tag
TTT目標伝達タグ
UA Unit Attention
AUユニットアテンション
This document specifies certain changes to [RFC3720] semantics as well as defines new iSCSI semantics. In addition, this document also clarifies the [RFC3720] semantics. This section summarizes the contents of the document, categorizing each section into one or more of a clarification, change, or new semantic.
この文書では、[RFC3720]の意味に特定の変更を指定するだけでなく、新しいiSCSIのセマンティクスを定義します。また、この文書はまた、[RFC3720]の意味を明確にしています。このセクションでは、明確化、変更、または新しいセマンティックの一つ以上に各セクションを分類、文書の内容を要約したものです。
Section 3.1.1: Clarification on iSCSI residuals computation general principles
3.1.1項：iSCSIの上の明確化は、計算の一般的な原則を残
Section 3.1.2: Clarification on iSCSI residuals computation with an example
セクション3.1.2：例とiSCSIの残差計算上の明確化
Section 3.2: Clarification on R2T ordering requirements
R2T発注要件の明確化：3.2節
Section 3.3: New Semantics for Response Ordering in multi-connection iSCSI sessions
セクション3.3：マルチ接続のiSCSIセッションでレスポンス順序のための新しいセマンティクス
Section 4.1.2: Clarifications, changes, and new semantics on multi-task abort semantics that all implementations must comply with
4.1.2：マルチタスクの明確化、変更、および新しいセマンティクスは、すべての実装が順守しなければならないセマンティクスを中止します
Section 4.1.3: Changes and new semantics (FastAbort semantics) on multi-task abort semantics that implementations should use for faster error recovery
セクション4.1.3：マルチタスクに変更して、新しい意味論（FastAbortセマンティクス）は実装が速くエラー回復のために使用すべきセマンティクスを中止します
Section 4.1.3.1: Changes in iSCSI clearing effects semantics resulting from new FastAbort semantics
セクション4.1.3.1：新しいFastAbortセマンティクス起因する効果のセマンティクスをクリアしたiSCSIの変更
Section 4.1.4: New Semantics on third-party session interactions with the new FastAbort semantics
4.1.4：新しいFastAbortのセマンティクスを持つサードパーティのセッションの相互作用に関する新たなセマンティクス
Section 4.1.5: Clarification on implementation considerations related to outstanding data transfers in order to realize correct iSCSI protocol behavior
正しいiSCSIプロトコルの動作を実現するためには、優れたデータ転送に関連する実装の考慮事項の明確化：4.1.5
Section 4.1.6: Clarification on the intent behind FastAbort semantics (not clarifications to [RFC3720] semantics)
セクション4.1.6：（[RFC3720]の意味にない明確化）FastAbort意味論の背後にある意図の明確化
Section 5.1: Clarification on error recovery semantics as applicable to Discovery sessions
セクション5.1：ディスカバリーセッションにエラー回復セマンティクスの明確化として適用可能
Section 5.2.1: Clarification and new semantics on applying the Initiator Session Identifier (ISID) RULE ([RFC3720]) to Unnamed Discovery Sessions
5.2.1：明確化と無名の検出セッションに（[RFC3720]）イニシエータセッション識別子（ISID）ルールを適用する上での新しいセマンティクス
Section 5.2.2: Clarification on applying the ISID RULE to Named Discovery Sessions
5.2.2：検出セッションにISIDルールを適用する上で明確化
Section 5.3: Clarification on allowed PDU types and target Logout notification behavior on a Discovery session
ディスカバリーセッションで許可されるPDUタイプとターゲット・ログアウト通知行動の明確化：5.3節
Section 6.1: Clarification on the legality of the Target Portal Group Tag (TPGT) value of zero
6.1節：ゼロのターゲットポータルグループタグ（TPGT）値の合法性の明確化
Section 6.2: Clarification on the negotiating order of SessionType with respect to other keys
セクション6.2：他のキーに関してSESSIONTYPEの交渉オーダーの明確化
Section 6.3: Clarification on the NotUnderstood negotiation response on declarative keys and the implied semantics
6.3節：宣言型のキーと暗黙のセマンティクスのNotUnderstood交渉応答の明確化
Section 6.4: Clarification on the number of legal outstanding negotiation PDUs (Text or Login-related)
セクション6.4：法的卓越した交渉PDUの数の明確化（テキストまたはログイン関連）
Section 7.1: Clarification on usage of the ITT value of 0xffffffff
セクション7.1：0xffffffffののITT値の使用方法の明確化
Section 7.2: Clarification on what constitutes format errors for the purpose of error recovery defined in [RFC3720]
セクション7.2：[RFC3720]で定義されたエラー回復のためにフォーマットエラーを構成するもので明確化
Section 7.3: Change in error recovery semantics for the case of discarding unsolicited PDUs
7.3節：迷惑PDUを廃棄する場合のエラー回復セマンティクスの変更
Section 7.4: Clarification on the intended level of error checking on inbound PDUs
セクション7.4：インバウンドのPDUのエラーチェックの意図レベルの明確化
Section 8.1: New semantics for a new AsyncEvent code
8.1節：新しいAsyncEventコードのための新しいセマンティクス
Section 8.2: Change of legal status for Reject reason code 0x0b; it is now deprecated
8.2節：理由コード0x0Bの拒否のための法的地位の変更。それが廃止されます
Section 9.1: New semantics for a new text key TaskReporting
セクション9.1：新しいテキストキーTaskReportingのための新しいセマンティクス
Section 10.4.1 of [RFC3720] defines the notion of "residuals" and specifies how the residual information should be encoded into the SCSI Response PDU in the Counts and Flags fields. Section 3.1.1 clarifies the intent of [RFC3720] and explains the general principles. Section 3.1.2 describes the residual handling in the REPORT LUNS scenario.
[RFC3720]のセクション10.4.1は、「残差」の概念を定義し、残留情報がカウントとフラグフィールドにSCSI応答PDUにエンコードする方法を指定します。 3.1.1項では、[RFC3720]の意図を明確にし、一般的な原則を説明しています。 3.1.2は、REPORT LUNSシナリオの残留取り扱いについて説明しています。
SCSI-Presented Data Transfer Length (SPDTL) is the term this document uses (see Section 1.1 for definition) to represent the aggregate data length that the target SCSI layer attempts to transfer using the local iSCSI layer for a task. Expected Data Transfer Length (EDTL) is the iSCSI term that represents the length of data that the iSCSI layer expects to transfer for a task. EDTL is specified in the SCSI Command PDU.
SCSI-提示されたデータ転送長（SPDTL）ターゲットSCSI層は、タスクのローカルiSCSI層を使用して転送しようとする集計データ長を表すために（定義についてはセクション1.1を参照）という用語は、この文書の使用です。予想データ転送長（EDTL）iSCSI層は、タスクの転送を期待するデータの長さを表すのiSCSI用語です。 EDTLは、SCSIコマンドPDUに指定されています。
When SPDTL = EDTL for a task, the target iSCSI layer completes the task with no residuals. Whenever SPDTL differs from EDTL for a task, that task is said to have a residual.
ときSPDTL = EDTLは、タスクのために、ターゲットのiSCSI層が無い残差でタスクを完了します。 SPDTLは、タスクのためにEDTL異なりたび、そのタスクは残留を持っていると言われています。
If SPDTL > EDTL for a task, iSCSI Overflow MUST be signaled in the SCSI Response PDU as specified in [RFC3720]. The Residual Count MUST be set to the numerical value of (SPDTL - EDTL).
タスクのSPDTL> EDTLは、iSCSIのオーバーフローがSCSI応答PDUでシグナリングする必要がある場合、[RFC3720]で指定されるように。残留カウント（ - EDTL SPDTL）の数値に設定しなければなりません。
If SPDTL < EDTL for a task, iSCSI Underflow MUST be signaled in the SCSI Response PDU as specified in [RFC3720]. The Residual Count MUST be set to the numerical value of (EDTL - SPDTL).
SPDTL <タスクのEDTLは、iSCSIのアンダーフローは、SCSI応答PDUでシグナリングする必要がある場合、[RFC3720]で指定されるように。残留カウント（ - SPDTL EDTL）の数値に設定しなければなりません。
Note that the Overflow and Underflow scenarios are independent of Data-In and Data-Out. Either scenario is logically possible in either direction of data transfer.
オーバーフローとアンダーフローのシナリオは、データインとデータアウトとは無関係であることに注意してください。どちらのシナリオでは、データ転送のいずれかの方向に論理的に可能です。
This section discusses the residual overflow issues citing the example of the SCSI REPORT LUNS command. Note however that there are several SCSI commands (e.g., INQUIRY) with ALLOCATION LENGTH fields following the same underlying rules. The semantics in the rest of the section apply to all such SCSI commands.
このセクションでは、SCSI REPORT LUNSコマンドの例を挙げて残留オーバーフローの問題について説明します。同じ基本規則に従ってアロケーション長フィールドを持ついくつかのSCSIコマンド（例えば、INQUIRY）があることに注意してください。セクションの残りの意味は、そのようなすべてのSCSIコマンドに適用されます。
The specification of the SCSI REPORT LUNS command requires that the SCSI target limit the amount of data transferred to a maximum size (ALLOCATION LENGTH) provided by the initiator in the REPORT LUNS CDB. If the Expected Data Transfer Length (EDTL) in the iSCSI header of the SCSI Command PDU for a REPORT LUNS command is set to at least as large as that ALLOCATION LENGTH, the SCSI layer truncation prevents an iSCSI Residual Overflow from occurring. A SCSI initiator can detect that such truncation has occurred via other information at the SCSI layer. The rest of the section elaborates this required behavior.
SCSI REPORT LUNSコマンドの仕様は、SCSIターゲット限界ことREPORT LUNS CDBにイニシエータによって提供される最大サイズ（アロケーション長）に転送されたデータの量を必要とします。 REPORT LUNSコマンドのSCSIコマンドPDUののiSCSIヘッダ内の予想されるデータ転送長（EDTL）はそのアロケーション長と少なくとも同じ大きさに設定されている場合は、SCSI層の切り捨てが発生するのiSCSI残留オーバーフローを防止します。 SCSIイニシエータは、そのような切り捨ては、SCSI層に他の情報を介して発生していることを検出することができます。セクションの残りの部分は、この必須動作を詳しく説明します。
iSCSI uses the (O) bit (bit 5) in the Flags field of the SCSI Response and the last SCSI Data-In PDUs to indicate that an iSCSI target was unable to transfer all of the SCSI data for a command to the initiator because the amount of data to be transferred exceeded the EDTL in the corresponding SCSI Command PDU (see Section 10.4.1 of [RFC3720]).
iSCSIは、iSCSIターゲットは、イニシエータためにコマンドのSCSIデータの全てを転送できなかったことを示すために、SCSI応答と最後のSCSIデータインPDUのFlagsフィールド内（O）ビット（ビット5）を使用し転送されるデータの量は、（[RFC3720]のセクション10.4.1を参照）は、対応するSCSIコマンドPDUにEDTLを超え。
The SCSI REPORT LUNS command requests a target SCSI layer to return a logical unit inventory (LUN list) to the initiator SCSI layer (see Section 6.21 of SPC-3 [SPC3]). The size of this LUN list may not be known to the initiator SCSI layer when it issues the REPORT LUNS command; to avoid transferring more LUN list data than the initiator is prepared for, the REPORT LUNS CDB contains an ALLOCATION LENGTH field to specify the maximum amount of data to be transferred to the initiator for this command. If the initiator SCSI layer has under-estimated the number of logical units at the target, it is possible that the complete logical unit inventory does not fit in the specified ALLOCATION LENGTH. In this situation, Section 4.3.3.6 in [SPC3] requires that the target SCSI layer "shall terminate transfers to the Data-In Buffer" when the number of bytes specified by the ALLOCATION LENGTH field have been transferred.
SCSI REPORT LUNSコマンド要求イニシエータSCSI層に論理ユニットインベントリ（LUNのリスト）を返すために、ターゲットSCSI層（SPC3のセクション6.21 [SPC3]を参照）。このLUNリストのサイズは、それがREPORT LUNSコマンドを発行するイニシエータSCSI層に知られてないかもしれません。イニシエータはのために準備されるよりも多くのLUNリストデータの転送を回避するために、REPORT LUNS CDBは、このコマンドのイニシエータに転送されるデータの最大量を指定するアロケーション長フィールドを含みます。イニシエータSCSI層がターゲットの論理ユニットの数を過小推定している場合、完全な論理ユニットの在庫は、指定されたアロケーション長に収まらない可能性があります。この状況では、[SPC3]節4.3.3.6は、ターゲットSCSI層は、アロケーション長フィールドによって指定されたバイト数が転送されている「データのバッファへの転送を停止しなければならない」ことを必要とします。
Therefore, in response to a REPORT LUNS command, the SCSI layer at the target presents at most ALLOCATION LENGTH bytes of data (logical unit inventory) to iSCSI for transfer to the initiator. For a REPORT LUNS command, if the iSCSI EDTL is at least as large as the ALLOCATION LENGTH, the SCSI truncation ensures that the EDTL will accommodate all of the data to be transferred. If all of the logical unit inventory data presented to the iSCSI layer -- i.e., the data remaining after any SCSI truncation -- is transferred to the initiator by the iSCSI layer, an iSCSI Residual Overflow has not occurred and the iSCSI (O) bit MUST NOT be set in the SCSI Response or final SCSI Data-Out PDU. This is not a new requirement but is already required by the combination of [RFC3720] with the specification of the REPORT LUNS command in [SPC3]. However, if the iSCSI EDTL is larger than the ALLOCATION LENGTH in this scenario, note that the iSCSI Underflow MUST be signaled in the SCSI Response
したがって、REPORT LUNSコマンドに応答して、ターゲットにSCSI層は、イニシエータに転送するためのiSCSIへのデータの最もアロケーション長バイト（論理ユニットインベントリ）に提示します。 iSCSIのEDTLはアロケーション長と少なくとも同じ大きさである場合REPORT LUNSコマンドについては、SCSIの切り捨てはEDTLが転送するデータの全てを収容することを保証します。 iSCSI層に提供する論理ユニットインベントリデータのすべての場合 - すなわち、任意のSCSIトランケーション後に残ったデータは - iSCSI層によってイニシエータに転送され、iSCSIの残留オーバーフローが発生していないとiSCSI（O）ビットSCSI応答または最終SCSIデータ出力PDUに設定してはいけません。これは新しい要件ではないが、すでに[SPC3]でREPORT LUNSコマンドの仕様に[RFC3720]の組み合わせによって必要とされます。 iSCSIのEDTLこのシナリオでアロケーション長よりも大きい場合には、iSCSIのアンダーフローは、SCSI応答に合図しなければならないことに注意してください
PDU. An iSCSI Underflow MUST also be signaled when the iSCSI EDTL is equal to the ALLOCATION LENGTH but the logical unit inventory data presented to the iSCSI layer is smaller than the ALLOCATION LENGTH.
PDU。 iSCSIのEDTLはアロケーション長に等しいが、iSCSI層に提供する論理ユニットインベントリデータは、アロケーション長よりも小さい場合のiSCSIアンダーフローもシグナリングされなければなりません。
The LUN LIST LENGTH field in the logical unit inventory (the first field in the inventory) is not affected by truncation of the inventory to fit in ALLOCATION LENGTH; this enables a SCSI initiator to determine that the received inventory is incomplete by noticing that the LUN LIST LENGTH in the inventory is larger than the ALLOCATION LENGTH that was sent in the REPORT LUNS CDB. A common initiator behavior in this situation is to re-issue the REPORT LUNS command with a larger ALLOCATION LENGTH.
論理ユニットインベントリ（在庫の最初のフィールド）におけるLUNのリスト長フィールドは、アロケーション長に適合するように在庫の切断によって影響されません。これは、受信されたインベントリはインベントリ内のLUNのリストの長さは、REPORT LUNS CDBで送信されたアロケーション長よりも大きくなっていることを通知することにより不完全であることを決定するために、SCSIイニシエータを可能にします。このような状況では、共通のイニシエータの動作は、より大きなアロケーション長と再発行REPORT LUNSコマンドです。
Section 10.8 in [RFC3720] says the following:
[RFC3720]で10.8節は、次のように述べています：
The target may send several R2T PDUs. It, therefore, can have a number of pending data transfers. The number of outstanding R2T PDUs is limited by the value of the negotiated key MaxOutstandingR2T. Within a connection, outstanding R2Ts MUST be fulfilled by the initiator in the order in which they were received.
ターゲットは、いくつかのR2T PDUを送信してもよいです。それは、したがって、保留中のデータ転送の数を持つことができます。優れたR2T PDUの数は、交渉され、キーMaxOutstandingR2Tの値によって制限されています。接続内、未処理R2Tsは、それらが受信された順序でイニシエータによって満たされなければなりません。
The quoted [RFC3720] text was unclear on the scope of applicability -- either per task, or across all tasks on a connection -- and may be interpreted as either. This section is intended to clarify that the scope of applicability of the quoted text is a task. No R2T ordering relationship -- either in generation at the target or in fulfilling at the initiator -- across tasks is implied. That is, outstanding R2Ts within a task MUST be fulfilled by the initiator in the order in which they were received on a connection.
タスクごとに、または接続上のすべてのタスクを横切ってのいずれか - - 引用符で囲まれた[RFC3720]のテキストは、適用の範囲に不明であったとのいずれかとして解釈することができます。このセクションでは、引用文の適用の範囲がタスクであることを明確にすることを意図しています。ターゲットでまたはイニシエータに履行中のいずれかの世代に - - いいえ、R2Tの順序関係タスク間では示唆されません。つまり、タスク内の優れたR2Tsは、それらが接続上で受信された順序でイニシエータによって満たされなければなりません。
Whenever an iSCSI session is composed of multiple connections, the Response PDUs (task responses or TMF responses) originating in the target SCSI layer are distributed onto the multiple connections by the target iSCSI layer according to iSCSI connection allegiance rules. This process generally may not preserve the ordering of the responses by the time they are delivered to the initiator SCSI layer. Since ordering is not expected across SCSI responses anyway, this approach works fine in the general case. However, to address the special cases where some ordering is desired by the SCSI layer, the following "Response Fence" semantics are defined with respect to handling SCSI response messages as they are handed off from the SCSI protocol layer to the iSCSI layer.
iSCSIセッションは、複数の接続から構成されているときはいつでも、ターゲットSCSI層における応答のPDU（タスク応答またはTMF応答）発信は、iSCSI接続忠誠規則に従って目標iSCSI層によって複数の接続に分散されています。このプロセスは、一般的に、彼らはイニシエータSCSI層に配信された時間によって応答の順序を保持しないことがあります。順序がとにかくSCSI応答渡って期待されていないので、このアプローチは、一般的な場合には正常に動作します。しかし、いくつかの順序はSCSI層が希望される特別な場合に対処するために、以下の「レスポンスフェンスは、」意味はそれらがiSCSI層にSCSIプロトコル層から渡されてSCSI応答メッセージの処理に関連して定義されています。
The target SCSI protocol layer hands off the SCSI response messages to the target iSCSI layer by invoking the "Send Command Complete" protocol data service ([SAM2], clause 5.4.2) and "Task Management Function Executed" ([SAM2], clause 6.9) service. On receiving the SCSI response message, the iSCSI layer exhibits the Response Fence behavior for certain SCSI response messages (Section 3.3.3 describes the specific instances where the semantics must be realized). Whenever the Response Fence behavior is required for a SCSI response message, the target iSCSI layer MUST ensure that the following conditions are met in delivering the response message to the initiator iSCSI layer:
ターゲットSCSIプロトコル層の手SCSI応答メッセージオフ「コマンドを送信完了」プロトコル・データ・サービス（[SAM2]、節5.4.2）と「実行されたタスク管理機能」（[SAM2]、句を呼び出すことによって、目標のiSCSI層に6.9）サービス。 SCSI応答メッセージを受信すると、iSCSI層は、特定のSCSI応答メッセージ（セクション3.3.3セマンティクスを実現しなければならない特定のインスタンスを記述する）の応答フェンス挙動を示します。レスポンスフェンス動作がSCSI応答メッセージに必要とされるたびに、ターゲットのiSCSI層は、以下の条件がイニシエータiSCSI層に応答メッセージを配信するには満たされていることを確認する必要があります。
(1) Response with Response Fence MUST be delivered chronologically after all the "preceding" responses on the I_T_L nexus, if the preceding responses are delivered at all, to the initiator iSCSI layer.
先行応答がイニシエータiSCSI層に、全く配信された場合に応答フェンス（1）応答がI_T_Lネクサス上の全ての「前の」応答の後に時系列的に送達されなければなりません。
(2) Response with Response Fence MUST be delivered chronologically prior to all the "following" responses on the I_T_L nexus.
（2）応答フェンスとの回答は、前I_T_Lネクサス上の全ての「次」の応答に時系列に送達されなければなりません。
The "preceding" and "following" notions refer to the order of handoff of a response message from the target SCSI protocol layer to the target iSCSI layer.
「前の」および「次の」概念ターゲットiSCSI層にターゲットSCSIプロトコル層からの応答メッセージのハンドオフの順序を指します。
Whenever the TaskReporting key (Section 9.1) is negotiated to ResponseFence or FastAbort for an iSCSI session and the Response Fence behavior is required for a SCSI response message, the target iSCSI layer MUST perform the actions described in this section for that session.
TaskReportingキー（9.1節）がiSCSIセッションのためにResponseFenceまたはFastAbortに交渉され、レスポンスフェンス動作がSCSI応答メッセージに必要とされるたびに、ターゲットのiSCSI層は、そのセッションのために、このセクションで説明するアクションを実行しなければなりません。
a) If it is a single-connection session, no special processing is required. The standard SCSI Response PDU build and dispatch process happens.
それは、単一の接続セッションである場合a）に、特別な処理は必要ありません。標準のSCSI応答PDUのビルドおよびディスパッチプロセスが起こります。
b) If it is a multi-connection session, the target iSCSI layer takes note of the last-sent and unacknowledged StatSN on each of the connections in the iSCSI session, and waits for an acknowledgement (NOP-In PDUs MAY be used to solicit acknowledgements as needed in order to accelerate this process) of each such StatSN to clear the fence. The SCSI response requiring Response Fence behavior MUST NOT be sent to the initiator before acknowledgements are received for each of the unacknowledged StatSNs.
それはマルチ接続セッションである場合b）に示すように、目標のiSCSI層は、iSCSIセッション内の接続の各々に送信された最後と未確認StatSNのメモを取り、肯定応答（NOP-でのPDUを待つ勧誘するために使用されるかもしれませんフェンスをクリアするような各StatSNのこのプロセスを加速するために、必要に応じて確認応答）。確認応答が未確認StatSNsごとに受信される前に、応答フェンスの動作を必要とするSCSI応答がイニシエータに送ってはいけません。
c) The target iSCSI layer must wait for an acknowledgement of the SCSI Response PDU that carried the SCSI response requiring the Response Fence behavior. The fence MUST be considered cleared only after receiving the acknowledgement.
C）目標iSCSI層は、応答フェンスの動作を必要とするSCSI応答を行うSCSI応答PDUの確認応答を待たなければなりません。フェンスは、唯一の承認を受けた後にクリア考えなければなりません。
d) All further status processing for the LU is resumed only after clearing the fence. If any new responses for the I_T_L nexus are received from the SCSI layer before the fence is cleared, those Response PDUs MUST be held and queued at the iSCSI layer until the fence is cleared.
D）LUのためのすべてのさらなるステータス処理のみフェンスをクリアした後に再開されます。フェンスがクリアされる前に、I_T_Lネクサスのための新たな応答はSCSI層から受信している場合は、それらの応答PDUを保持しなければならないとフェンスがクリアされるまで、iSCSI層でキューに入れられました。
This section lists the fenced response use cases that iSCSI implementations MUST comply with. However, this is not an exhaustive enumeration. It is expected that as SCSI protocol specifications evolve, the specifications will specify when response fencing is required on a case-by-case basis.
このセクションでは、iSCSI実装が順守しなければならないフェンスで囲まれた応答の使用例を示しています。しかし、これは網羅的な列挙ではありません。 SCSIプロトコル仕様が進化として応答フェンシングは、ケース・バイ・ケースで必要とされている場合、仕様が指定することが期待されます。
Whenever the TaskReporting key (Section 9.1) is negotiated to ResponseFence or FastAbort for an iSCSI session, the target iSCSI layer MUST assume that the Response Fence is required for the following SCSI completion messages:
TaskReportingキー（9.1節）がiSCSIセッションのためにResponseFenceまたはFastAbortに交渉されるたびに、ターゲットのiSCSI層は、レスポンスフェンスには、次のSCSI完了メッセージのために必要であると仮定しなければなりません：
1. The first completion message carrying the UA after the multi-task abort on issuing and third-party sessions. See Section 4.1.1 for related TMF discussion.
1.マルチタスク後UAを担持する第一完了メッセージを発行し、サードパーティのセッションで中断します。関連するTMFの議論については、セクション4.1.1を参照してください。
2. The TMF Response carrying the multi-task TMF Response on the issuing session.
2. TMF応答は、発行セッションのマルチタスクTMF応答を運びます。
3. The completion message indicating ACA establishment on the issuing session.
3.発行セッション上のACAの確立を示す完了メッセージ。
4. The first completion message carrying the ACA ACTIVE status after ACA establishment on issuing and third-party sessions.
発行及びサードパーティセッションにACAの確立後ACA ACTIVE状態を運ぶまず完了メッセージ。
5. The TMF Response carrying the Clear ACA response on the issuing session.
5. TMFレスポンスが発行セッションでクリアACA応答を運びます。
6. The response to a PERSISTENT RESERVE OUT/PREEMPT AND ABORT command.
6. PERSISTENT RESERVE OUT / PREEMPTに対する応答は、コマンドを中止します。
Note: Due to the absence of ACA-related fencing requirements in [RFC3720], initiator implementations SHOULD NOT use ACA on multi-connection iSCSI sessions to targets complying only with [RFC3720]. Initiators that want to employ ACA on multi-connection iSCSI sessions
注：これにより、[RFC3720]でACA関連フェンシング要件が存在しないため、イニシエータ実装は[RFC3720]でのみ準拠ターゲットに複数接続iSCSIセッションにACAを使用しないでください。マルチ接続のiSCSIセッションにACAを採用したいイニシエータ
SHOULD first assess response-fencing behavior via negotiating for ResponseFence or FastAbort values for the TaskReporting (Section 9.1) key.
最初TaskReporting（セクション9.1）キーのResponseFence又はFastAbort値の交渉を介して応答フェンシング挙動を評価すべきです。
This section clarifies and updates the original text in Section 10.6.2 of [RFC3720]. The clarified semantics (Section 4.1.2) are a superset of the protocol behavior required in the original text and all iSCSI implementations MUST support the new behavior. The updated semantics (Section 4.1.3) on the other hand are mandatory only when the new key TaskReporting (Section 9.1) is negotiated to "FastAbort".
このセクションでは、明確にし、[RFC3720]のセクション10.6.2で、元のテキストを更新します。明らかセマンティクス（4.1.2）は、元のテキストに必要なプロトコルの動作のスーパーセットであり、すべてのiSCSI実装は、新しい動作をサポートしなければなりません。一方、更新セマンティクス（4.1.3項）は、新しいキーTaskReporting（9.1節）は「FastAbort」に交渉されている場合のみ必須です。
This section defines the notion of "affected tasks" in multi-task abort scenarios. Scope definitions in this section apply to both the clarified protocol behavior (Section 4.1.2) and the updated protocol behavior (Section 4.1.3).
このセクションでは、マルチタスクで、「影響を受けるタスク」中止のシナリオの概念を定義します。このセクションの適用範囲の定義を明確にプロトコルの動作（4.1.2項）と更新されたプロトコルの動作（4.1.3項）の両方に適用されます。
ABORT TASK SET: All outstanding tasks for the I_T_L nexus identified by the LUN field in the ABORT TASK SET TMF Request PDU.
ABORT TASK SET TMF要求PDUにLUNフィールドで識別I_T_Lネクサスのためにすべての未処理のタスク：タスクセットを中止します。
CLEAR TASK SET: All outstanding tasks in the task set for the LU identified by the LUN field in the CLEAR TASK SET TMF Request PDU. See [SPC3] for the definition of a "task set".
CLEAR TASK SET：CLEAR TASK SET TMF要求PDUにLUNフィールドによって識別されるLUに設定されたタスクのすべての未処理のタスク。 「タスクセット」の定義については、[SPC3]を参照してください。
LOGICAL UNIT RESET: All outstanding tasks from all initiators for the LU identified by the LUN field in the LOGICAL UNIT RESET Request PDU.
論理ユニットRESET：論理ユニットリセット要求PDUにLUNフィールドによって識別されるLUのためのすべてのイニシエータからのすべての未処理のタスク。
TARGET WARM RESET/TARGET COLD RESET: All outstanding tasks from all initiators across all LUs to which the TMF-issuing session has access on the SCSI target device hosting the iSCSI session.
TARGET WARM RESET / TARGET COLD RESET：すべてのLU間のすべてのイニシエータからのすべての未処理のタスクいるTMF-発行セッションはiSCSIセッションをホストしているSCSIターゲットデバイス上のアクセス権を持っているの。
Usage: An "ABORT TASK SET TMF Request PDU" in the preceding text is an iSCSI TMF Request PDU with the "Function" field set to "ABORT TASK SET" as defined in [RFC3720]. Similar usage is employed for other scope descriptions.
用法：「ABORT TASK SET TMF要求PDU」前のテキストでは[RFC3720]で定義される「TASK SETを中断」に設定された「機能」フィールドとのiSCSI TMF要求PDUです。同様の使用は、他のスコープの説明のために採用されています。
All iSCSI implementations MUST support the protocol behavior defined in this section as the default behavior. The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests consists of the following sequence of actions in the specified order on the specified party.
すべてのiSCSI実装は、デフォルトの動作として、このセクションで定義されたプロトコルの動作をサポートしなければなりません。 ABORT TASK SET、CLEAR TASK SET、論理ユニットRESET、TARGET WARM RESET、およびTARGET COLD RESET TMF要求の実行は、指定されたパーティに指定された順序で以下の一連の動作で構成されています。
The initiator iSCSI layer:
イニシエータiSCSI層：
a. MUST continue to respond to each TTT received for the affected tasks.
A。 TTTは、影響を受けたタスクのために受信それぞれに対応し続けなければなりません。
b. SHOULD process any responses received for affected tasks in the normal fashion. This is acceptable because the responses are guaranteed to have been sent prior to the TMF response.
B。通常の方法で影響を受けたタスクのために受け取った任意の応答を処理しなければなりません。応答は前TMF応答に送信されていることが保証されているので、これは許容可能です。
c. SHOULD receive the TMF Response concluding all the tasks in the set of affected tasks unless the initiator has done something (e.g., LU reset, connection drop) that may prevent the TMF Response from being sent or received. The initiator MUST thus conclude all affected tasks as part of this step in either case, and MUST discard any TMF Response received after the affected tasks are concluded.
C。イニシエータが送信または受信されるのTMFの応答を防止することができるもの（例えば、LUは、接続損失をリセット）を行っていない限り、影響を受けるタスクのセット内のすべてのタスクを締結TMF応答を受けるべきです。イニシエータは、このようにいずれの場合もこのステップの一部として、影響を受けるすべてのタスクを終了しなければならない、そして影響を受けたタスクが終了された後、任意のTMF応答を受信捨てなければなりません。
The target iSCSI layer:
ターゲットiSCSI層：
a. MUST wait for responses on currently valid target-transfer tags of the affected tasks from the issuing initiator. MAY wait for responses on currently valid target-transfer tags of the affected tasks from third-party initiators.
A。発行イニシエータからの影響を受けたタスクの現在有効なターゲット転送タグの応答を待たなければなりません。サードパーティのイニシエータからの影響を受けたタスクの現在有効なターゲット転送タグの応答を待つことができます。
b. MUST wait (concurrent with the wait in Step a) for all commands of the affected tasks to be received based on the CmdSN ordering. SHOULD NOT wait for new commands on third-party affected sessions -- only the instantiated tasks have to be considered for the purpose of determining the affected tasks. In the case of target-scoped requests (i.e., TARGET WARM RESET and TARGET COLD RESET), all of the commands that are not yet received on the issuing session in the command stream however can be considered to have been received with no command waiting period -- i.e., the entire CmdSN space up to the CmdSN of the task management function can be "plugged".
B。 CmdSNの順序に基づいて受信される影響を受けたタスクのすべてのコマンドについて（工程Aで待機と同時）待たなければなりません。サードパーティの影響を受けたセッションで新しいコマンドを待つべきではありません - 唯一のインスタンス化の作業は、影響を受けるタスクを決定する目的のために考慮しなければなりません。ターゲットスコープのリクエスト（すなわち、TARGET WARM RESETとTARGET COLD RESET）の場合は、まだコマンドストリームに発行セッションで受信されていないすべてのコマンドは、しかし、時間を待っていないコマンドを受信したと見なすことができます - つまり、タスク管理機能のCmdSNまでの全体CmdSNスペースは「プラグイン」することができます。
c. MUST propagate the TMF request to and receive the response from the target SCSI layer.
C。 TMF要求を伝播し、ターゲットSCSI層からの応答を受信しなければなりません。
d. MUST provide the Response Fence behavior for the TMF Response on the issuing session as specified in Section 3.3.2.
D。 3.3.2項で指定され、発行セッションのTMF応答の応答フェンスの動作を提供しなければなりません。
e. MUST provide the Response Fence behavior on the first post-TMF Response on third-party sessions as specified in Section 3.3.2. If some tasks originate from non-iSCSI I_T_L nexuses, then the means by which the target ensures that all affected tasks have returned their status to the initiator are defined by the specific non-iSCSI transport protocol(s).
電子。 3.3.2項で指定されているサードパーティのセッションの最初のポストTMFレスポンスのレスポンスフェンスの動作を提供しなければなりません。いくつかのタスクが非iSCSIのI_T_L nexuses起源場合、ターゲットは、影響を受けるすべてのタスクがイニシエータにそのステータスを返したことを保証する手段は、特定の非iSCSIのトランスポートプロトコル（単数または複数）によって定義されます。
Technically, the TMF servicing is complete in Step d. Data transfers corresponding to terminated tasks may however still be in progress on third-party iSCSI sessions even at the end of Step e. The TMF Response MUST NOT be sent by the target iSCSI layer before the end of Step d, and MAY be sent at the end of Step d despite these outstanding data transfers until after Step e.
技術的には、TMFのサービスは、手順dで完了です。終了したタスクに対応したデータ転送は、しかし、まださえ工程eの終わりに、サードパーティのiSCSIセッションの進捗状況にあってもよいです。 TMFレスポンスは、ステップdの終了前に、ターゲットのiSCSI層で送ってはいけません、そして工程e後まで、これらの優れたデータ転送にもかかわらず、ステップdの終わりに送るかもしれません。
Protocol behavior defined in this section MUST be implemented by all iSCSI implementations complying with this document. Protocol behavior defined in this section MUST be exhibited by iSCSI implementations on an iSCSI session when they negotiate the TaskReporting (Section 9.1) key to "FastAbort" on that session. The execution of ABORT TASK SET, CLEAR TASK SET, LOGICAL UNIT RESET, TARGET WARM RESET, and TARGET COLD RESET TMF Requests consists of the following sequence of actions in the specified order on the specified party.
このセクションで定義されたプロトコルの動作は、この文書に準拠するすべてのiSCSI実装によって実装されなければなりません。彼らはそのセッションの「FastAbort」にTaskReporting（9.1節）キーを交渉する際に、このセクションで定義されたプロトコルの動作では、iSCSIセッションのiSCSI実装で展示されなければなりません。 ABORT TASK SET、CLEAR TASK SET、論理ユニットRESET、TARGET WARM RESET、およびTARGET COLD RESET TMF要求の実行は、指定されたパーティに指定された順序で以下の一連の動作で構成されています。
The initiator iSCSI layer:
イニシエータiSCSI層：
a. MUST NOT send any more Data-Out PDUs for affected tasks on the issuing connection of the issuing iSCSI session once the TMF is sent to the target.
A。 TMFは、ターゲットに送信されると、発行するiSCSIセッションの発行接続に影響を受けたタスクのための任意のより多くのデータアウトPDUを送ってはいけません。
b. SHOULD process any responses received for affected tasks in the normal fashion. This is acceptable because the responses are guaranteed to have been sent prior to the TMF response.
B。通常の方法で影響を受けたタスクのために受け取った任意の応答を処理しなければなりません。応答は前TMF応答に送信されていることが保証されているので、これは許容可能です。
c. MUST respond to each Async Message PDU with AsyncEvent=5 as defined in Section 8.1.
C。セクション8.1で定義されるようAsyncEvent = 5の各非同期メッセージPDUに応答しなければなりません。
d. MUST treat the TMF response as terminating all affected tasks for which responses have not been received, and MUST discard any responses for affected tasks received after the TMF response is passed to the SCSI layer (although the semantics defined in this section ensure that such an out-of-order scenario will never happen with a compliant target implementation).
D。応答が受信されていないため、影響を受けるすべてのタスクを終了するようにTMF応答を扱わなければなりませんし、このセクションで定義された意味は、出ていることを確認したがTMF応答は（SCSI層に渡された後に受信し、影響を受けたのタスクの応答を捨てなければなりません-of次のシナリオは）準拠のターゲット実装で発生することはありません。
The target iSCSI layer:
ターゲットiSCSI層：
a. MUST wait for all commands of the affected tasks to be received based on the CmdSN ordering on the issuing session. SHOULD NOT wait for new commands on third-party affected sessions -- only the instantiated tasks have to be considered for the purpose of determining the affected tasks. In the case of target-scoped requests (i.e., TARGET WARM RESET and TARGET COLD RESET), all the commands that are not yet received on the issuing session in the command stream can be considered to have been received with no command waiting period -- i.e., the entire CmdSN space up to the CmdSN of the task management function can be "plugged".
A。発行セッションのCmdSN順序に基づいて受信される影響を受けるタスクの全てのコマンドを待機しなければなりません。サードパーティの影響を受けたセッションで新しいコマンドを待つべきではありません - 唯一のインスタンス化の作業は、影響を受けるタスクを決定する目的のために考慮しなければなりません。ターゲットスコープのリクエスト（すなわち、TARGET WARM RESETとTARGET COLD RESET）の場合は、まだコマンドストリームに発行セッションで受信されていないすべてのコマンドは、コマンドなしの待機期間で受信されたと考えることができます - すなわち、タスク管理機能のCmdSNまでの全体CmdSNスペースは「プラグイン」することができます。
b. MUST propagate the TMF request to and receive the response from the target SCSI layer.
B。 TMF要求を伝播し、ターゲットSCSI層からの応答を受信しなければなりません。
c. MUST leave all active "affected TTTs" (i.e., active TTTs associated with affected tasks) valid.
C。有効なすべてのアクティブな「影響を受けるTTTS」（影響を受けたタスクに関連付けられている、すなわち、アクティブTTTS）を残しておく必要があります。
d. MUST send an Asynchronous Message PDU with AsyncEvent=5 (Section 8.1) on:
D。 AsyncEvent = 5（8.1節）上で非同期メッセージPDUを送信しなければなりません。
i) each connection of each third-party session to which at
least one affected task is allegiant if
TaskReporting=FastAbort is operational on that third-party
session, and
ii) each connection except the issuing connection of the issuing session that has at least one allegiant affected task.
ii）の少なくとも一つのAllegiant影響を受けるタスクを有する発行セッションの発行接続を除く各接続。
If there are multiple affected LUs (say, due to a target reset), then one Async Message PDU MUST be sent for each such LU on each connection that has at least one allegiant affected task. The LUN field in the Asynchronous Message PDU MUST be set to match the LUN for each such LU.
（ターゲットリセットのために、例えば）のLU影響複数存在する場合、1非同期メッセージPDUは、少なくとも一つのAllegiant影響タスクを有する各接続に対して、このような各LUのために送られなければなりません。非同期メッセージPDU内のLUNフィールドは、このような各LUのLUNと一致するように設定されなければなりません。
e. MUST address the Response Fence flag on the TMF Response on the issuing session as defined in Section 3.3.2.
電子。 3.3.2項で定義されている発行セッションのTMFレスポンスにレスポンスフェンスフラグに対処しなければなりません。
f. MUST address the Response Fence flag on the first post-TMF Response on third-party sessions as defined in Section 3.3.2. If some tasks originate from non-iSCSI I_T_L nexuses, then the means by which the target ensures that all affected tasks have returned their status to the initiator are defined by the specific non-iSCSI transport protocol(s).
F。 3.3.2項で定義されているサードパーティのセッションの最初のポストTMFレスポンスのレスポンスフェンスフラグに対処しなければなりません。いくつかのタスクが非iSCSIのI_T_L nexuses起源場合、ターゲットは、影響を受けるすべてのタスクがイニシエータにそのステータスを返したことを保証する手段は、特定の非iSCSIのトランスポートプロトコル（単数または複数）によって定義されます。
g. MUST free up the affected TTTs (and STags, if applicable) and the corresponding buffers, if any, once it receives each associated NOP-Out acknowledgement that the initiator generated in response to each Async Message.
グラム。それは、イニシエータが各非同期メッセージに応答して生成した各関連NOPアウト肯定応答を受信すると、もしあれば、影響を受けたTTTS（及びスタッグス、該当する場合）と対応するバッファを解放しなければなりません。
Technically, the TMF servicing is complete in Step e. Data transfers corresponding to terminated tasks may however still be in progress even at the end of Step f. A TMF Response MUST NOT be sent by the target iSCSI layer before the end of Step e, and MAY be sent at the end of Step e despite these outstanding Data transfers until Step g. Step g specifies an event to free up any such resources that may have been reserved to support outstanding data transfers.
技術的には、TMFのサービスは、ステップeで完了です。終了したタスクに対応するデータ転送は、しかしながら、依然としてさえ工程fの終了時に進行中であってもよいです。 TMFレスポンスは、ステップeの終了前に、ターゲットのiSCSI層で送ってはいけません、とステップgまで、これらの優れたデータ転送にもかかわらず、工程eの終わりに送るかもしれません。ステップgは、優れたデータ転送をサポートするために予約されている可能性があり、そのようなリソースを解放するイベントを指定します。
Appendix F.1 of [RFC3720] specifies the clearing effects of target and LU resets on "Incomplete TTTs" as "Y". This meant that a target warm reset or a target cold reset or an LU reset would clear the active TTTs upon completion. However, the TaskReporting=FastAbort (Section 9.1) semantics defined by this section do not guarantee that the active TTTs are cleared by the end of the reset operations. In fact, the new semantics are designed to allow clearing the TTTs in a "lazy" fashion after the TMF Response is delivered. Thus, when TaskReporting=FastAbort is operational on a session, the clearing effects of reset operations on "Incomplete TTTs" is "N".
[RFC3720]の付録F.1は、目標のクリアエフェクトを指定し、LUは、「Y」のように「不完全なTTTS」にリセットされます。これは、ターゲットウォームリセットまたはターゲットコールドリセットまたはLUのリセットが完了すると、アクティブTTTSをクリアすることを意味しました。しかし、TaskReporting = FastAbort（9.1節）この節で定義された意味は、アクティブTTTSがリセット動作の終了によってクリアされることを保証するものではありません。実際には、新しい意味はTMF応答が配信された後、「怠惰な」方式でTTTSをクリアできるように設計されています。 TaskReporting = FastAbortセッションで動作しているときにこのように、「不完全TTTS」にリセット動作の透明効果は「N」です。
If an iSCSI target implementation is capable of supporting TaskReporting=FastAbort functionality (Section 9.1), it may end up in a situation where some sessions have TaskReporting=RFC3720 operational (RFC 3720 sessions) while some other sessions have TaskReporting=FastAbort operational (FastAbort sessions) even while accessing a shared set of affected tasks (Section 4.1.1).
iSCSIターゲット実装はTaskReporting = FastAbort機能（セクション9.1）をサポートすることが可能である場合、それはいくつかのセッションが動作TaskReporting = RFC3720（RFC 3720セッション）を有する状況で終わるかもしれないいくつかの他のセッションがTaskReporting = FastAbort動作（FastAbortセッションを有するが）影響を受けたタスク（4.1.1）の共有セットにアクセスしながらも。
If the issuing session is an RFC 3720 session, the iSCSI target implementation is FastAbort-capable, and the third-party affected session is a FastAbort session, the following behavior SHOULD be exhibited by the iSCSI target layer:
発行セッションは、RFC 3720のセッションである場合は、iSCSIターゲットの実装はFastAbort-可能であり、サードパーティの影響を受けたセッションはFastAbortセッションで、次の動作は、iSCSIターゲット層によって発揮させることが必要です。
a. Between Steps c and d of the target behavior in Section 4.1.2, send an Asynchronous Message PDU with AsyncEvent=5 (Section 8.1) on each connection of each third-party session to which at least one affected task is allegiant. If there are multiple affected LUs, then send one Async Message PDU for each such LU on each connection that has at least one allegiant affected task. When sent, the LUN field in the Asynchronous Message PDU MUST be set to match the LUN for each such LU.
A。 4.1.2における標的行動のステップcおよびdの間に、少なくとも一つの影響を受けたタスクがあるのAllegiant、各サードパーティセッションの各接続にAsyncEventと非同期メッセージPDU = 5（8.1節）を送信します。複数影響LUが存在する場合、少なくとも一つのAllegiant影響を受けたタスクを有し、各接続上でそのような各LUための一非同期メッセージPDUを送信します。送信されたときに、非同期メッセージPDU内のLUNフィールドは、このような各LUのLUNと一致するように設定されなければなりません。
b. After Step e of the target behavior in Section 4.1.2, free up the affected TTTs (and STags, if applicable) and the corresponding buffers, if any, once each associated NOP-Out acknowledgement is received that the third-party initiator generated in response to each Async Message sent in Step a.
B。 4.1.2における標的行動のステップeの後、影響を受けたTTTS（及びスタッグス、該当する場合）、対応するバッファを解放し、もしあれば、一度各関連NOPアウト肯定応答は、サードパーティのイニシエータがで発生することを受信されます手順aで送信された各非同期メッセージに対する応答。
If the issuing session is a FastAbort session, the iSCSI target implementation is FastAbort-capable, and the third-party affected session is an RFC 3720 session, the following behavior MUST be exhibited by the iSCSI target layer: Asynchronous Message PDUs MUST NOT be sent on the third-party session to prompt the FastAbort behavior.
発行セッションはFastAbortセッションの場合、iSCSIターゲットの実装はFastAbort-可能であり、サードパーティの影響を受けたセッションは、RFC 3720のセッションで、次の動作は、iSCSIターゲット層によって示されなければなりません：非同期メッセージPDUは送ってはいけませんサードパーティのセッションでFastAbort行動に促します。
If the third-party affected session is a FastAbort session and the issuing session is a FastAbort session, the initiator in the third-party role MUST respond to each Async Message PDU with AsyncEvent=5 as defined in Section 8.1. Note that an initiator MAY thus receive these Async Messages on a third-party affected session even if the session is a single-connection session.
サードパーティの影響セッションはFastAbortセッションであり、発行セッションはFastAbortセッションである場合、セクション8.1で定義されるように、サードパーティの役割における開始剤はAsyncEvent = 5の各非同期メッセージPDUに応答しなければなりません。イニシエータは、このようにセッションがシングル接続セッションであっても、サードパーティの影響を受けたセッションでこれらの非同期メッセージを受け取ることができることに注意してください。
Both in clarified semantics (Section 4.1.2) and updated semantics (Section 4.1.3), there may be outstanding data transfers even after the TMF completion is reported on the issuing session. In the case of iSCSI/iSER [iSER], these would be tagged data transfers for STags not owned by any active tasks. Whether or not real buffers support these data transfers is implementation-dependent. However, the data transfers logically MUST be silently discarded by the target iSCSI layer in all cases. A target MAY, on an implementation-defined internal timeout, also choose to drop the connections on which it did not receive the expected Data-Out sequences (Section 4.1.2) or NOP-Out acknowledgements (Section 4.1.3) so as to reclaim the associated buffer, STag, and TTT resources as appropriate.
清澄化セマンティクス（4.1.2）と、更新セマンティクス（セクション4.1.3）の両方において、TMF完了が発行セッションで報告された後も未処理のデータ転送があってもよいです。 iSCSIの/のiSER【のiSER]の場合には、これらは、任意のアクティブなタスクによって所有されていないスタッグスのデータ転送をタグ付けされることになります。実際のバッファは、これらのデータ転送をサポートするかどうかは、実装依存です。しかし、データ転送は、論理的にサイレントすべての場合において、ターゲットiSCSI層によって廃棄されなければなりません。それが予想されるデータアウトシーケンス（4.1.2）またはするようにNOPアウトの確認応答（セクション4.1.3）を受信しなかった上、対象MAYは、実装定義の内部タイムアウトに、また、接続をドロップすることを選択します必要に応じて関連するバッファ、のSTag、及びTTTリソースを再利用。
There are fundamentally three basic objectives behind the semantics specified in Sections 4.1.2 and 4.1.3.
セクション4.1.2と4.1.3で指定された意味論の背後にある基本的に三つの基本的な目的があります。
1. Maintaining an ordered command flow I_T nexus abstraction to the target SCSI layer even with multi-connection sessions.
1.さえマルチ接続セッションでターゲットSCSI層に注文したコマンドフローI_Tネクサスの抽象化を維持します。
o Target iSCSI processing of a TMF request must maintain the single flow illusion. Target behavior in Step b of Section 4.1.2 and Step a of Section 4.1.3 correspond to this objective.
O TMF要求の対象iSCSI処理は、単一の流れ幻想を維持しなければなりません。セクション4.1.2のステップbにおける挙動を標的とし、セクション4.1.3のこの目的に対応するステップ。
2. Maintaining a single ordered response flow I_T nexus abstraction to the initiator SCSI layer even with multi-connection sessions when one response (i.e., TMF response) could imply the status of other unfinished tasks from the initiator's perspective.
2.も複数接続セッションとイニシエータSCSI層に単一の順序付けられた応答フローI_Tネクサス抽象化を維持する場合つの応答（すなわち、TMF応答）がイニシエータの観点から、他の未完了のタスクのステータスを意味する可能性があります。
o The target must ensure that the initiator does not see "old" task responses (that were placed on the wire chronologically earlier than the TMF Response) after seeing the TMF response. The target behavior in Step d of Section 4.1.2 and Step e of Section 4.1.3 correspond to this objective.
Oターゲットは、イニシエータがTMF応答を見た後（TMF応答よりも時系列的に以前のワイヤーの上に置かれた）「古い」タスクの回答を見ていないことを確認する必要があります。 4.1.2と4.1.3項の工程eのステップdのターゲットの行動は、この目的に対応しています。
o Whenever the result of a TMF action is visible across multiple I_T_L nexuses, [SAM2] requires the SCSI device server to trigger a UA on each of the other I_T_L nexuses. Once an initiator is notified of such an UA, the application client on the receiving initiator is required to clear its task state (clause 5.5 in [SAM2]) for the affected tasks. It would thus be inappropriate to deliver a SCSI Response for a task after the task state is cleared on the initiator, i.e., after the UA is notified. The UA notification contained in the first SCSI Response PDU on each affected Third-party I_T_L nexus after the TMF action thus MUST NOT pass the affected task responses on any of the iSCSI sessions accessing the LU. The target behavior in Step e of Section 4.1.2 and Step f of Section 4.1.3 correspond to this objective.
TMF作用の結果は、複数I_T_Lのnexuses横切って表示されるたびに、O、[SAM2]他I_T_LのnexusesのそれぞれにUAをトリガするSCSIデバイスサーバを必要とします。開始剤は、このようなUAが通知されると、受信側イニシエータ上のアプリケーションクライアントは、影響を受けるタスクのために（[SAM2]に節5.5）そのタスクの状態をクリアするために必要とされます。 UAが通知された後、タスクの状態は、すなわち、イニシエータにクリアされた後、したがって、タスクのSCSI応答を実現することは不適切だろう。これTMFアクション後の各影響を受けたサードパーティのI_T_Lネクサス上の最初のSCSI応答PDUに含まれるUAの通知は、LUにアクセスするiSCSIセッションのいずれかに影響を受けたタスクの応答を渡してはなりません。セクション4.1.3のFセクション4.1.2ステップの工程eにおいて、ターゲット動作は、この目的に対応しています。
3. Draining all active TTTs corresponding to affected tasks in a deterministic fashion.
3.決定論的な方法で影響を受けたタスクに対応するすべてのアクティブなTTTSを排出。
o Data-Out PDUs with stale TTTs arriving after the tasks are terminated can create a buffer management problem even for traditional iSCSI implementations, and is fatal for the connection for iSCSI/iSER implementations. Either the termination of affected tasks should be postponed until the TTTs are retired (as in Step a of Section 4.1.2), or the TTTs and the buffers should stay allocated beyond task termination to be deterministically freed up later (as in Steps c and g of Section 4.1.3).
Oタスクが終了した後に到着古いTTTSとデータアウトPDUはさえ、従来のiSCSI実装のためのバッファ管理の問題を作成し、およびiSCSI /のiSER実装のための接続のために致命的であることができます。 TTTSは（4.1.2節のステップのように）引退するまで、影響を受けたタスクの終了のいずれかを延期しなければならない、またはTTTSとバッファが確定後に解放されるようにタスク終了を超えて割り当てられたままにすべきである（ステップCでとのように4.1.3項のグラム）。
The only other notable optimization is the plugging. If all tasks on an I_T nexus will be aborted anyway (as with a target reset), there is no need to wait to receive all commands to plug the CmdSN holes. The target iSCSI layer can simply plug all missing CmdSN slots and move on with TMF processing. The first objective (maintaining a single ordered command flow) is still met with this optimization because the target SCSI layer only sees ordered commands.
唯一の他の注目すべき最適化が目詰まりです。 I_Tネクサス上のすべてのタスクが（ターゲットリセットのように）とにかく中止された場合は、CmdSN穴をプラグインするすべてのコマンドの受信を待機する必要はありません。ターゲットiSCSI層は、単に、すべての欠落CmdSNスロットプラグとTMF処理とに移動することができます。ターゲットSCSI層のみが注文したコマンドを見ているので、（単一命じたコマンドの流れを維持する）第一の目的は、まだこの最適化で満たされています。
The negotiation of the key ErrorRecoveryLevel is not required for Discovery sessions -- i.e., for sessions that negotiated "SessionType=Discovery" -- because the default value of 0 is necessary and sufficient for Discovery sessions. It is however possible that some legacy iSCSI implementations might attempt to negotiate the ErrorRecoveryLevel key on Discovery sessions. When such a negotiation attempt is made by the remote side, a compliant iSCSI implementation MUST propose a value of 0 (zero) in response. The operational ErrorRecoveryLevel for Discovery sessions thus MUST be 0. This naturally follows from the functionality constraints that [RFC3720] imposes on Discovery sessions.
キーErrorRecoveryLevelのネゴシエーションは発見セッションのために必要とされていない - すなわち、「SESSIONTYPE =ディスカバリー」をネゴシエートするためのセッション - 0のデフォルト値が必要とディスカバリーセッションのために十分であるからです。いくつかのレガシーiSCSI実装は、ディスカバリーセッションのErrorRecoveryLevelキーを交渉しようとするかもしれないことは可能です。このようなネゴシエーションの試行がリモート側によって行われる場合、対応のiSCSI実装は応答して0（ゼロ）の値を提案しなければなりません。ディスカバリーセッションの操作ErrorRecoveryLevelは、このように0でなければなりません。これは当然[RFC3720]は発見セッションに課すことの機能上の制約から、次の。
Discovery sessions are intended to be relatively short-lived. Initiators are not expected to establish multiple Discovery sessions to the same iSCSI Network Portal (see [RFC3720]). An initiator may use the same iSCSI Initiator Name and ISID when establishing different unique sessions with different targets and/or different portal groups. This behavior is discussed in Section 9.1.1 of [RFC3720] and is, in fact, encouraged as conservative reuse of ISIDs. The ISID RULE in [RFC3720] states that there must not be more than one session with a matching 4-tuple: <InitiatorName, ISID, TargetName, TargetPortalGroupTag>. While the spirit of the ISID RULE applies to Discovery sessions the same as it does for Normal sessions, note that some Discovery sessions differ from the Normal sessions in two important aspects:
ディスカバリーセッションは比較的短命であることを意図しています。イニシエータは、（[RFC3720]を参照）と同じiSCSIのネットワークポータルに複数の検出セッションを確立することが期待されていません。異なるターゲットおよび/または異なるポータルグループと異なるユニークなセッションを確立するときに、イニシエータは、同じiSCSIイニシエータ名とISIDを使用することができます。この現象は、[RFC3720]のセクション9.1.1に記載されていると、実際には、ISIDsの保存的再利用として奨励されています。 <InitiatorName、ISID、TargetNameは、TargetPortalGroupTag>：[RFC3720]でISIDルールが一致する4タプルを持つ複数のセッションがあってはならないと述べています。それは通常のセッションの場合と同様にISIDルールの精神は発見セッションに同じ適用されますが、いくつかの発見セッションは二つの重要な面で通常のセッションと異なることに注意してください。
Because [RFC3720] allows a Discovery session to be established without specifying a TargetName key in the Login Request PDU (let us call such a session an "Unnamed" Discovery session), there is no Target Node context to enforce the ISID RULE.
[RFC3720]は発見セッションがログイン要求PDUでTargetNameはキーを指定せずに確立することを可能にするので（私たちは、このようなセッション「名前」ディスカバリーセッションを呼びましょう）、ISIDのルールを強制するいかなるターゲット・ノードのコンテキストはありません。
Portal Groups are defined only in the context of a Target Node. When the TargetName key is NULL-valued (i.e., not specified), the TargetPortalGroupTag thus cannot be ascertained to enforce the ISID RULE.
ポータルグループにのみターゲットノードのコンテキストで定義されています。 TargetNameはキーがNULL値（即ち、指定されていない）である場合、TargetPortalGroupTagしたがってISIDルールを適用する確認することができません。
The following sections describe the two scenarios -- Named Discovery sessions and Unnamed Discovery sessions -- separately.
個別 - 検出セッションと名前ディスカバリーセッション - 次のセクションでは、2つのシナリオについて説明します。
For Unnamed Discovery sessions, neither the TargetName nor the TargetPortalGroupTag is available to the targets in order to enforce the ISID RULE. So the following rule applies.
名前ディスカバリーセッションでは、TargetNameはもTargetPortalGroupTagどちらもISID規則を施行するために、ターゲットに利用可能です。したがって、次のルールが適用されます。
UNNAMED ISID RULE: Targets MUST enforce the uniqueness of the following 4-tuple for Unnamed Discovery sessions: <InitiatorName, ISID, NULL, TargetAddress>. The following semantics are implied by this uniqueness requirement.
UNNAMED ISIDのRULE：ターゲットは無名の検出セッションのために、以下の4タプルの一意性を強制する必要があります。<InitiatorName、ISID、NULL、のTargetAddress>。以下のセマンティクスは、このユニークさの要件によって暗示されています。
Targets SHOULD allow concurrent establishment of one Discovery session with each of its Network Portals by the same initiator port with a given iSCSI Node Name and an ISID. Each of the concurrent Discovery sessions, if established by the same initiator port to other Network Portals, MUST be treated as independent sessions -- i.e., one session MUST NOT reinstate the other.
目標は、与えられたiSCSIノード名とISIDと同じイニシエータポートによって、そのネットワークポータルのそれぞれと1つのディスカバリーセッションの同時確立を許可する必要があります。同時ディスカバリセッションの各々は、他のネットワークポータルと同じイニシエータポートによって確立された場合には、独立したセッションとして処理されなければならない - すなわち、一つのセッションは、他を回復してはいけません。
A new Unnamed Discovery session that has a matching <InitiatorName, ISID, NULL, TargetAddress> to an existing Discovery session MUST reinstate the existing Unnamed Discovery session. Note thus that only an Unnamed Discovery session may reinstate an Unnamed Discovery session.
既存のディスカバリーセッションにマッチング<InitiatorName、ISID、NULL、のTargetAddress>を持つ新しい名前ディスカバリーセッションは、既存の名前ディスカバリーセッションを回復しなければなりません。唯一の名前ディスカバリーセッションが無名の検出セッションを復元することにように注意してください。
For a Named Discovery session, the TargetName key is specified by the initiator and thus the target can unambiguously ascertain the TargetPortalGroupTag as well. Since all the four elements of the 4- tuple are known, the ISID RULE MUST be enforced by targets with no changes from [RFC3720] semantics. A new session with a matching <InitiatorName, ISID, TargetName, TargetPortalGroupTag> thus will reinstate an existing session. Note in this case that any new iSCSI session (Discovery or Normal) with the matching 4-tuple may reinstate an existing Named Discovery iSCSI session.
名前付きディスカバリーセッションの場合、TargetNameはキーは、イニシエータによって指定されるので、ターゲットが明確にもTargetPortalGroupTagを確認することができます。 4-タプルのすべての4つの要素が知られているので、ISIDルールは[RFC3720]のセマンティクスから変更せずにターゲットによって実施されなければなりません。マッチング<InitiatorName、ISID、TargetNameは、TargetPortalGroupTag>との新しいセッションは、このように既存のセッションを復元します。一致する4タプルを有する任意の新しいiSCSIセッション（ディスカバリーまたはノーマル）という名前の既存の検出iSCSIセッションを回復することができる。この場合に注意してください。
Targets SHOULD NOT send any responses other than a Text Response and Logout Response on a Discovery session, once in Full Feature Phase.
ターゲットは一度フル機能のフェーズで、ディスカバリーセッションのテキストレスポンスとログアウトレスポンス以外のレスポンスを送るべきではありません。
Implementation Note: A target may simply drop the connection in a Discovery session when it would have requested a Logout via an Async Message on Normal sessions.
実装ノート：それは通常のセッションで非同期メッセージを介してログアウトを要求していたときの目標は、単にディスカバリーセッションで接続をドロップすることがあります。
[SAM2] and [SAM3] specifications incorrectly note in their informative text that TPGT value should be non-zero, although [RFC3720] allows the value of zero for TPGT. This section is to clarify that a zero value is expressly allowed as a legal value for TPGT. This discrepancy currently stands corrected in [SAM4].
[SAM2]と[SAM3】仕様が誤っ[RFC3720]はTPGTゼロの値を可能にするがTPGT値は、非ゼロであることを、それらの有益なテキストに注意します。このセクションでは、ゼロ値を明示TPGTための有効な値として許可されていることを明らかにすることです。この不一致は、現在、[SAM4]で修正立っています。
During the Login Phase, the SessionType key is offered by the initiator to choose the type of session it wants to create with the target. The target may accept or reject the offer. Depending on the type of the session, a target may decide on resources to allocate and the security to enforce, etc. for the session. If the SessionType key is thus going to be offered as "Discovery", it SHOULD be offered in the initial Login request by the initiator.
ログインフェイズに、SESSIONTYPEキーは、それがターゲットで作成したいセッションのタイプを選択するために、イニシエータによって提供されています。ターゲットは、提案を受け入れるか拒否することができます。セッションの種類に応じて、ターゲットがセッションに割り当てるとセキュリティを施行するためのリソースなどに決めることができます。 SESSIONTYPEキーは、このように「ディスカバリー」として提供されようとしている場合は、イニシエータによる初期ログイン要求で提供されるべきです。
[RFC3720] defines NotUnderstood as a valid answer during a negotiation text key exchange between two iSCSI nodes. NotUnderstood has the reserved meaning that the sending side did not understand the proposed key semantics. This section seeks to clarify that NotUnderstood is a valid answer for both declarative and negotiated keys. The general iSCSI philosophy is that comprehension precedes processing for any iSCSI key. A proposer of an iSCSI key, negotiated or declarative, in a text key exchange MUST thus be able to properly handle a NotUnderstood response.
[RFC3720]は2つのiSCSIノード間の交渉テキストキーの交換時に有効な回答としてNotUnderstood定義します。 NotUnderstoodは、送信側が提案されているキーの意味を理解していなかったことを、予約の意味を持っています。このセクションでは、そのNotUnderstoodは宣言と交渉し、両方のキーのための有効な回答で明らかにすることを目指しています。一般的なiSCSIの哲学は理解がどんなのiSCSIキーの処理を先行することです。テキスト鍵交換でネゴシエートまたは宣言のiSCSIキーの提案は、このように適切NotUnderstood応答を扱うことができなければなりません。
The proper way to handle a NotUnderstood response depends on where the key is specified and whether the key is declarative vs. negotiated. All keys defined in [RFC3720] MUST be supported by all compliant implementations; a NotUnderstood answer on any of the [RFC3720] keys therefore MUST be considered a protocol error and handled accordingly. For all other later keys, a NotUnderstood answer concludes the negotiation for a negotiated key whereas for a declarative key, a NotUnderstood answer simply informs the declarer of a lack of comprehension by the receiver.
NotUnderstood応答を処理するための適切な方法は、キーが指定されている場所に、キーが宣言型対が交渉されているかどうかによって決まります。 [RFC3720]で定義されたすべてのキーは、すべての準拠した実装でサポートしなければなりません。 [RFC3720]キーのいずれかにNotUnderstood応答は、従って、プロトコルエラーを考慮しなければならず、それに応じて扱います。宣言型のキーのために、NotUnderstoodの答えは単純に受信機による理解の欠如の申告を知らせるのに対し、他のすべての後にキーの場合、NotUnderstoodの答えが交渉されたキーのネゴシエーションを終了します。
In either case, a NotUnderstood answer always requires that the protocol behavior associated with that key not be used within the scope of the key (connection/session) by either side.
いずれの場合においても、NotUnderstood回答は常に、そのキーに関連付けられたプロトコルの動作ではないいずれかの側のキー（接続/セッション）の範囲内で使用されることを必要とします。
There was some uncertainty around the number of outstanding Login Response PDUs on a connection. [RFC3720] offers the analogy of SCSI linked commands to Login and Text negotiations in Sections 5.3 and 10.10.3, respectively, but does not make it fully explicit. This section is to offer a clarification in this regard.
接続に優れログイン応答PDUの数の周りにいくつかの不確実性がありました。 [RFC3720]はSCSIのアナロジーは、それぞれ、セクション5.3および10.10.3にログインするためのコマンドとテキスト交渉をリンクし、それは完全には明示的なことはありません提供しています。このセクションでは、この点で明確化を提供することです。
There MUST NOT be more than one outstanding Login Request, Login Response, Text Request, or Text Response PDU on an iSCSI connection. An outstanding PDU in this context is one that has not been acknowledged by the remote iSCSI side.
iSCSI接続で複数の優れたログイン要求、ログイン応答、テキスト要求、またはテキストレスポンスPDUがあってはなりません。この文脈での優れたPDUは、リモートiSCSI側で確認されていないものです。
An ITT value of 0xffffffff is reserved and MUST NOT be assigned for a task by the initiator. The only instance in which it may be seen on the wire is in a target-initiated NOP-In PDU (and in the initiator response to that PDU, if necessary). Section 10.19 in [RFC3720] mentions this in passing but is noted here again to make it obvious since the semantics apply to the initiators in general.
0xFFFFFFFFのITTの値が予約されており、イニシエータによってタスクに割り当ててはいけません。 （必要であれば、そのPDUにイニシエータ応答して）、それがワイヤ上で見ることのできる唯一のインスタンスは、ターゲット開始NOPインPDUです。 [RFC3720]でのセクション10.19を渡すことでこれを言及したがセマンティクスは、一般的にイニシエータに適用されますので、それは明らかにするために、ここで再び注目されます。
Section 6.6 of [RFC3720] discusses format error handling. This section elaborates on the "inconsistent" PDU field contents noted in [RFC3720].
[RFC3720]の6.6節は、フォーマットエラー処理について説明します。このセクションでは、[RFC3720]で述べた「矛盾」PDUフィールドの内容について詳しく説明します。
All initiator-detected PDU construction errors MUST be considered as format errors. Some examples of such errors are:
すべてのイニシエータ検出PDU構造エラーはフォーマットエラーと見なされなければなりません。このようなエラーのいくつかの例は以下のとおりです。
- NOP-In with a valid TTT but an invalid LUN
- 有効なTTTとNOP-ではなく、無効なLUN
- NOP-In with a valid ITT (i.e., a NOP-In response) and also a valid TTT
- 有効ITT（すなわち、NOP-Inの応答）と、有効なTTTとNOPイン
- SCSI Response PDU with Status=CHECK CONDITION, but DataSegmentLength = 0
- SCSI応答PDUステータス= CHECK条件に、しかしDataSegmentLength = 0
Section 6.7 of [RFC3720] discusses digest error handling. It states that "No further action is necessary for initiators if the discarded PDU is an unsolicited PDU (e.g., Async, Reject)" on detecting a payload digest error. This is incorrect.
[RFC3720]の6.7節には、エラー処理をダイジェストについて説明します。これは、ペイロードエラーダイジェストを検出の「廃棄PDUが求められていないPDU（例えば、非同期、拒否）であればそれ以上のアクションは、イニシエータのために必要ではない」と述べています。これは正しくありません。
An Asynchronous Message PDU or a Reject PDU carries the next StatSN value on an iSCSI connection, advancing the StatSN. When an initiator discards one of these PDUs due to a payload digest error, the entire PDU including the header MUST be discarded. Consequently, the initiator MUST treat the exception like a loss of any other solicited response PDU -- i.e., it MUST use one of the following options noted in [RFC3720]:
非同期メッセージPDUまたは拒否PDUはStatSNを前進、iSCSI接続に次StatSN値を運びます。イニシエータは、エラーを消化によるペイロードにこれらのPDUのいずれかを破棄する場合、ヘッダを含む全体のPDUは廃棄されなければなりません。従って、イニシエータは、他の要請応答PDUの損失のような例外を処置しなければならない - すなわち、それは[RFC3720]で述べた次のいずれかのオプションを使用する必要があります。
a) Request PDU retransmission with a status SNACK.
ステータスSNACKとa）の要求PDU再送。
b) Logout the connection for recovery and continue the tasks on a different connection instance.
b）の回復のための接続をログアウトし、別の接続インスタンス上で作業を続けます。
c) Logout to close the connection (abort all the commands associated with the connection).
C）（接続に関連するすべてのコマンドをアボート）接続を閉じるようにログアウト。
There has been some uncertainty on the extent to which incoming messages have to be checked for protocol errors, beyond what is strictly required for processing the inbound message. This section addresses this question.
着信メッセージは、厳密にインバウンドメッセージを処理するために必要なものを超えて、プロトコル・エラーのためにチェックする必要がどの程度にいくつかの不確実性がありました。このセクションでは、この問題に対処しています。
Unless [RFC3720] or this document requires it, an iSCSI implementation is not required to do an exhaustive protocol conformance check on an incoming iSCSI PDU. The iSCSI implementation especially is not required to double-check the remote iSCSI implementation's conformance to protocol requirements.
[RFC3720]やこの文書は、それを必要としない限り、iSCSI実装が入ってくるのiSCSI PDUの徹底的なプロトコルの適合性チェックを行うために必要とされていません。 iSCSI実装は、特にプロトコル要件にリモートiSCSI実装の適合性をダブルチェックする必要はありません。
This section defines additional semantics for the Asynchronous Message PDU defined in Section 10.9 of [RFC3720] using the same conventions.
このセクションでは、同じ規則を使用して、[RFC3720]のセクション10.9で定義された非同期メッセージPDUのための追加のセマンティクスを定義します。
The following new legal value for the AsyncEvent is defined:
AsyncEventのための次の新しい法的な値が定義されています。
5: all active tasks for LU with a matching LUN field in the Async Message PDU are being terminated.
5：非同期メッセージPDU内の一致するLUNフィールドとLUのすべてのアクティブタスクが終了されています。
The receiving initiator iSCSI layer MUST respond to this Message by taking the following steps in order.
受信イニシエータiSCSI層は、順序で次の手順を取ることによって、このメッセージに応答する必要があります。
i) Stop Data-Out transfers on that connection for all active TTTs
for the affected LUN quoted in the Async Message PDU.
ii) Acknowledge the StatSN of the Async Message PDU via a NOP-Out PDU with ITT=0xffffffff (i.e., non-ping flavor), while copying the LUN field from the Async Message to NOP-Out.
NOP-Outに非同期メッセージからLUNフィールドをコピーしながらII）、（すなわち、非ピングフレーバー）ITT = 0xFFFFFFFFの持つNOPアウトPDUを介して非同期メッセージPDUのStatSNアクノリッジ。
The new AsyncEvent defined in this section however MUST NOT be used on an iSCSI session unless the new TaskReporting text key defined in Section 9.1 was negotiated to FastAbort on the session.
セクション9.1で定義された新しいTaskReportingテキストキーがセッションにFastAbortに交渉された場合を除きしかし、このセクションで定義された新しいAsyncEventは、iSCSIセッションで使用してはいけません。
Section 10.17.1 of [RFC3720] specifies the Reject reason code of 0x0b with an explanation of "Negotiation Reset". At this point, we do not see any legitimate iSCSI protocol use case for using this reason code. Thus, reason code 0x0b MUST be considered as deprecated and MUST NOT be sent by implementations that comply with the requirements of this document. An implementation receiving reason code 0x0b MUST treat it as a negotiation failure that terminates the Login Phase and the TCP connection, as specified in Section 6.10 of [RFC3720].
[RFC3720]のセクション10.17.1をインクルードは、「交渉のリセット」の説明と0x0Bのの理由コードを拒否指定します。この時点で、我々はこの理由コードを使用するための任意の正当なiSCSIプロトコルを使用する場合は表示されません。このように、理由コード0x0Bのは非推奨とみなされなければならないと、この文書の要件に準拠実装で送ってはいけません。 [RFC3720]のセクション6.10で指定されているような実装受ける理由コード0x0Bのは、ログインフェーズを終了し、交渉の障害とTCPコネクションとしてそれを扱わなければなりません。
Section 5.4 of [RFC3720] states:
[RFC3720]のセクション5.4で述べています：
Neither the initiator nor the target should attempt to declare or negotiate a parameter more than once during any negotiation sequence without an intervening operational parameter negotiation reset, except for responses to specific keys that explicitly allow repeated key declarations (e.g., TargetAddress).
イニシエータもターゲットはいずれも、明示的に繰り返さキー宣言（例えば、のTargetAddress）を可能にする特定のキーへの応答を除き、介入動作パラメータネゴシエーションリセットせずに任意の交渉シーケンスの間に何度もパラメーターを複数宣言するか、交渉を試みる必要があります。
The deprecation of reason code 0x0b eliminates the possibility of an operational parameter negotiation reset, causing the phrase "without an intervening operational parameter negotiation reset" in [RFC3720] to refer to an impossible event. The quoted phrase SHOULD be ignored by receivers that handle reason code 0x0b in the manner specified in this section.
理由コード0x0Bのの廃止は不可能イベントを参照するために、[RFC3720]で「介在動作パラメータのネゴシエーションリセットせずに」というフレーズを引き起こし、動作パラメータのネゴシエーションリセットの可能性を排除します。引用されたフレーズは、このセクションで指定された方法で、理由コード0x0Bのを扱う受信機によって無視されるべきです。
This section follows the same conventions as Section 12 of [RFC3720].
このセクションでは、[RFC3720]のセクション12と同じ規則に従います。
Use: LO Senders: Initiator and Target Scope: SW
用途：LO差出人：イニシエータとターゲットスコープ：SW
Irrelevant when: SessionType=Discovery TaskReporting=<list-of-values>
無関係なとき：SESSIONTYPE =ディスカバリーTaskReporting = <リスト-の値>
Default is RFC3720. Result function is AND.
デフォルトはRFC3720です。結果関数はANDです。
This key is used to negotiate the task completion reporting semantics from the SCSI target. The following table describes the semantics that an iSCSI target MUST support for respective negotiated key values. Whenever this key is negotiated, at least the RFC3720 and ResponseFence values MUST be offered as options by the negotiation originator.
このキーは、SCSIターゲットからのセマンティクスを報告するタスクの完了を交渉するために使用されます。次の表は、iSCSIターゲットがそれぞれ交渉し、キーの値のためにサポートしなければならない意味を説明しています。このキーがネゴシエートされるたびに、少なくともRFC3720とResponseFence値は交渉創始者でオプションとして提供されなければなりません。
+--------------+------------------------------------------+
| Name | Description |
+--------------+------------------------------------------+
| RFC3720 | RFC 3720-compliant semantics. Response |
| | fencing is not guaranteed and fast |
| | completion of multi-task aborting is not |
| | supported |
+--------------+------------------------------------------+
| ResponseFence| Response Fence (Section 3.3.1) semantics |
| | MUST be supported in reporting task |
| | completions |
+--------------+------------------------------------------+
| FastAbort | Updated fast multi-task abort semantics |
| | defined in Section 4.1.3 MUST be |
| | supported. Support for Response Fence is|
| | implied -- i.e., Section 3.3.1 semantics |
| | MUST be supported as well |
+--------------+------------------------------------------+
When TaskReporting is not negotiated to FastAbort, the [RFC3720] TMF semantics as clarified in Section 4.1.2 MUST be used.
TaskReportingがFastAbortにネゴシエートされていない場合、セクション4.1.2に明らかなように[RFC3720] TMFセマンティクスを使用しなければなりません。
This document does not introduce any new security considerations other than those already noted in [RFC3720]. Consequently, all the iSCSI-related security text in [RFC3723] is also directly applicable to this document.
この文書では、すでに[RFC3720]で述べたもの以外の新しいセキュリティの考慮事項を導入しません。その結果、[RFC3723]ですべてのiSCSI関連のセキュリティテキストも、この文書に直接適用されます。
This document creates the following iSCSI-related registries for IANA to manage.
IANAが管理するためにこのドキュメントでは、次のiSCSI関連のレジストリを作成します。
Each of the following sections describes a registry, its sub-registries if any, and their administration policies in more detail. IANA has registered what this document calls the main "registries" as sub-registries of a larger iSCSI registry. However, wherever registry-to-sub-registry relationships are specified by this document, they have been preserved intact.
以下の各セクションでは、より詳細に、レジストリ、そのサブレジストリがあれば、その管理の方針を説明しています。 IANAは、この文書は、より大きなiSCSIのレジストリのサブレジストリなどの主要な「登録簿」と呼ぶものを登録しました。レジストリ・ツー・サブレジストリ関係は、この文書で指定されているところはどこでもしかし、彼らはそのまま保存されています。
[RFC3720] specifies three iSCSI-related registries -- extended key, authentication methods, and digests. This document recommends that these registries be published together with the registries defined by this document. Further, this document recommends that the three [RFC3720] registries be listed in between items 6 and 7 in the registry list above.
拡大鍵、認証方式、およびダイジェスト - [RFC3720]は3のiSCSI関連のレジストリを指定します。この文書では、これらのレジストリは、この文書で定義されたレジストリと一緒に公開されることをお勧めします。さらに、この文書は、三[RFC3720]レジストリは、上記のレジストリリスト内のアイテム6と7との間に記載されていることをお勧めします。
Name of the registry: "iSCSI Opcodes"
レジストリの名称：「iSCSIのオペコード」
Namespace details: Numerical values that can fit in one octet with the most significant two bits (bits 0 and 1) already designated by [RFC3720], bit 0 being reserved and bit 1 for immediate delivery. Bit 2 is designated to identify the originator of the opcode. Bit 2 = 0 for initiator and Bit 2 = 1 for target.
ネームスペースの詳細：最上位の2ビット（ビット0と1）既にによって指定と1つのオクテットに収まる数値[RFC3720]、ビット0は予約されそして、即時配信のためのビット1。ビット2は、オペコードの発信元を特定するために指定されています。ターゲットのための開始剤とビット2 = 1のビット2 = 0。
Information that must be provided to assign a new value: An IESG-approved standards-track specification defining the semantics and interoperability requirements of the proposed new value and the fields to be recorded in the registry.
レジストリに記録することが提案された新しい値とフィールドのセマンティクスとの相互運用性の要件を定義するIESGが承認した標準トラック仕様：新しい値を割り当てるために提供されなければならない情報。
Allocation request guidance to requesters:
リクエスタへの割り当て要求ガイダンス：
1) If the initiator opcode and target opcode used to identify the request and response of a new type of protocol operation are requested, assign the same lower five bits (i.e., Bit 3 through Bit 7) for both opcodes, e.g., 0x13 and 0x33.
要求およびプロトコル動作の新しいタイプの応答を識別するために使用される開始剤のオペコードとターゲットオペコードが要求されている場合1）、両方のオペコード、例えば、0x13に及び0x33のための同一の下位5ビット（すなわち、ビット7を介してビット3）を割り当てます。
2) If only the initiator opcode or target opcode is requested to identify a one-way protocol message (i.e., request without a response or a "response" without a request), assign an unused number from the appropriate category (i.e., Bit 2 set to 0 or 1 for initiator category or target category) and add the other pair member (i.e., same opcode with Bit 2 set to 1 or 0, respectively) to "no opcode pair is available" list.
のみイニシエータオペコードまたはターゲットオペコードが一方向プロトコルメッセージを識別するために要求された場合2）（すなわち、応答又は要求せずに「応答」することなく要求）は、適切なカテゴリから未使用の番号（すなわち、ビット2を割り当てますイニシエータカテゴリまたはターゲットカテゴリ0または1に設定）と他方の対のメンバー（1又は0のビット2セットと、すなわち、同一のオペコード、それぞれ）を「Noオペコードペアが利用可能でない」リストに追加します。
3) If there are no other opcodes available in the appropriate "Reserved to IANA" list to assign on a request for a new opcode except the reserved opcodes in the "no opcode pair is available" list, allocate the opcode from the appropriate category (initiator or target) of the "no opcode pair is available" list.
3）「はオペコードペアが利用可能でない」リスト内の予約オペコード以外新しいオペコードのための要求に割り当てるための適切な「予約IANAに」リストで利用可能な他の命令コードが存在しない場合、適切なカテゴリ（からのオペコードを割り当てます「何のオペコードペアが利用できない」リストのイニシエータまたはターゲット）。
Fields to record in the registry: Assigned value, Who can originate (Initiator or Target), Operation Name, and its associated RFC reference.
発信することができます割り当てられた値、（イニシエータまたはターゲット）、操作名、およびそれに関連するRFCの参照：フィールドはレジストリに記録します。
Initial registry contents:
初期のレジストリの内容：
0x00, Initiator, NOP-Out, [RFC3720]
0x00で、イニシエータ、NOPアウト、[RFC3720]
0x01, Initiator, SCSI Command, [RFC3720]
0x01で、イニシエータ、SCSIコマンド、[RFC3720]
0x02, Initiator, SCSI Task Management function request, [RFC3720]
0x02の、イニシエータ、SCSIタスク管理機能要求、[RFC3720]
0x03, Initiator, Login Request, [RFC3720]
0x03の、イニシエータ、ログイン要求、[RFC3720]
0x04, Initiator, Text Request, [RFC3720]
0x04が、イニシエータ、テキスト要求、[RFC3720]
0x05, Initiator, SCSI Data-Out, [RFC3720]
0x05の、イニシエータ、SCSIデータアウト、[RFC3720]
0x06, Initiator, Logout Request, [RFC3720]
0x06で、イニシエータ、ログアウト要求、[RFC3720]
0x10, Initiator, SNACK Request, [RFC3720]
0x10の、イニシエータ、スナック要求、[RFC3720]
0x1c-0x1e, Initiator, Vendor specific codes, [RFC3720]
0x1cに-0x1eが表示、開始剤、ベンダー固有のコード、[RFC3720]
0x20, Target, NOP-In, [RFC3720]
0x20の、ターゲット、NOP-において、[RFC3720]
0x21, Target, SCSI Response, [RFC3720]
0x21で、ターゲット、SCSIレスポンス、[RFC3720]
0x22, Target, SCSI Task Management function response, [RFC3720]
ただし0x22、ターゲット、SCSIタスク管理機能の応答、[RFC3720]
0x23, Target, Login Response, [RFC3720]
0x23、ターゲット、ログイン応答、[RFC3720]
0x24, Target, Text Response, [RFC3720]
0x24を、ターゲット、テキスト応答、[RFC3720]
0x25, Target, SCSI Data-In, [RFC3720]
0x25、ターゲット、SCSIデータイン、[RFC3720]
0x26, Target, Logout Response, [RFC3720]
0x26、ターゲット、ログアウト応答、[RFC3720]
0x31, Target, Ready To Transfer (R2T), [RFC3720]
0x31、ターゲット、（R2T）、[RFC3720]を転送する準備ができ
0x32, Target, Asynchronous Message, [RFC3720]
0x32の、ターゲット、非同期メッセージ、[RFC3720]
0x3c-0x3e, Target, Vendor specific codes, [RFC3720]
0x3cの-0x3e、ターゲット、ベンダー固有のコード、[RFC3720]
0x3f, Target, Reject, [RFC3720]
0x3fを、ターゲット、拒否、[RFC3720]
Reserved to IANA: 0x07-0x0f, 0x13-0x1b (initiator codes) 0x27-0x2f, 0x33-0x3b (target codes)
IANAに予約：0x07-0x0f、0x13-0x1b（開始コード）0x27-0x2f、0x33-0x3b（ターゲットコード）
No opcode pair is available: 0x11, 0x12, 0x1f (initiator codes) 0x30 (target codes)
いいえオペコードペアが利用可能でない：0x11を、0x12を、0x1Fの（開始コード）0x30から（ターゲットコード）
Allocation Policy:
割り当てポリシー：
Standards Action ([IANA]): This is required for defining the semantics of the opcode.
標準アクション（[IANAは]）：これは、オペコードの意味を定義するために必要とされます。
Expert Review ([IANA]): This is required for selecting the specific opcode(s) to allocate in order to ensure compliance with the earlier "Allocation request guidance to requesters".
エキスパートレビュー（[IANAは]）：これは、以前の「リクエスタへの割り当て要求ガイダンス」の遵守を確保するために割り当てるための特定のオペコード（複数可）を選択するために必要です。
Name of the registry: "iSCSI Text Keys"
レジストリの名前：「iSCSIのテキストキー」
Namespace details: Key=value pairs with "Key" names in UTF-8 Unicode, and the permissible "value" options for the "Key" are Key-dependent. [RFC3720] defines the rules on key names and allowed values.
名前空間の詳細：UTF-8 Unicodeで「キー」の名前、および「キー」の許容「値」オプションを使用して、=キーと値のペアは、キーに依存しています。 [RFC3720]はキー名と許容値に規則を定義します。
Information that must be provided to assign a new value: An IESG-approved standards-track specification defining the semantics and interoperability requirements of the proposed new Key per [RFC3720] key specification template and the fields to be recorded in the registry.
[RFC3720]キー仕様のテンプレートやレジストリに記録するフィールドごとに提案された新しいキーのセマンティクスとの相互運用性の要件を定義するIESGが承認した標準トラック仕様：新しい値を割り当てるために提供されなければならない情報。
Assignment policy:
割り当てポリシー：
If the requested Key name is not already assigned and is roughly representative of its proposed semantics, it may be assigned to the requester.
要求されたキー名がすでに割り当てられ、おおよそその提案の意味を表しているされていない場合は、要求者に割り当てることができます。
Given the arbitrary nature of text strings, there is no maximum reserved by IANA for assignment in this registry.
テキスト文字列の任意の性質を考えると、このレジストリ内の割り当てのためにIANAによって予約数に制限はありません。
Fields to record in the registry: Assigned Key Name and its associated RFC reference.
割り当てられたキーの名前とその関連RFC参照：フィールドはレジストリに記録します。
Initial registry contents:
初期のレジストリの内容：
AuthMethod, [RFC3720]
AuthMethod、[RFC3720]
HeaderDigest, [RFC3720]
たHeaderDigest、[RFC3720]
DataDigest, [RFC3720]
DataDigest [RFC3720]
MaxConnections, [RFC3720]
MaxConnectionsを、[RFC3720]
SendTargets, [RFC3720]
SendTargets、[RFC3720]
TargetName, [RFC3720]
TargetNameは、[RFC3720]
InitiatorName, [RFC3720]
InitiatorName、[RFC3720]
TargetAlias, [RFC3720]
targetAliasの、[RFC3720]
InitiatorAlias, [RFC3720]
InitiatorAlias、[RFC3720]
TargetAddress, [RFC3720]
TargetAddress、[RFC3720]
TargetPortalGroupTag, [RFC3720]
TargetPortalGroupTag、[RFC3720]
InitialR2T, [RFC3720]
InitialR2T、[RFC3720]
ImmediateData, [RFC3720]
ImmediateData、[RFC3720]
MaxRecvDataSegmentLength, [RFC3720]
MaxRecvDataSegmentLength、[RFC3720]
MaxBurstLength, [RFC3720]
MaxBurstLength、[RFC3720]
FirstBurstLength, [RFC3720]
FirstBurstLength、[RFC3720]
DefaultTime2Wait, [RFC3720]
DefaultTime2Wait、[RFC3720]
DefaultTime2Retain, [RFC3720]
DefaultTime2Retain、[RFC3720]
MaxOutstandingR2T, [RFC3720]
MaxOutstandingR2T、[RFC3720]
DataPDUInOrder, [RFC3720]
DataPDUInOrder、[RFC3720]
DataSequenceInOrder, [RFC3720]
DataSequenceInOrder、[RFC3720]
ErrorRecoveryLevel, [RFC3720]
ErrorRecoveryLevel、[RFC3720]
SessionType, [RFC3720]
SESSIONTYPE、[RFC3720]
RDMAExtensions, [iSER]
RDMAExtensions [微粉]
TargetRecvDataSegmentLength, [iSER]
TargetRecvDataSegmentLength、[のiSER]
InitiatorRecvDataSegmentLength, [iSER]
InitiatorRecvDataSegmentLength [微粉]
MaxOutstandingUnexpectedPDUs, [iSER]
マックス卓越した予期しないPDUは、[微粉]
TaskReporting, this document
TaskReporting、このドキュメント
Allocation Policy:
割り当てポリシー：
Standards Action ([IANA])
標準アクション（[IANA]）
Name of the registry: "iSCSI Asynchronous Events"
レジストリの名称：「iSCSIの非同期イベント」
Namespace details: Numerical values that can fit in one octet.
名前空間の詳細：1つのオクテットに収まる数値。
Information that must be provided to assign a new value: An IESG-approved standards-track specification defining the semantics and interoperability requirements of the proposed new Event and the fields to be recorded in the registry.
セマンティクスとの相互運用性の要件提案された新しいイベントのとレジストリに記録するフィールドを定義IESGが承認した標準トラック仕様：新しい値を割り当てるために提供されなければならない情報。
Assignment policy:
割り当てポリシー：
If the requested value is not already assigned, it may be assigned to the requester.
要求された値がすでに割り当てられていない場合は、要求者に割り当てることができます。
6-247: range reserved by IANA for assignment in this registry.
6から247：このレジストリ内の割り当てのためにIANAによって予約範囲。
Fields to record in the registry: Assigned Event number, Description and its associated RFC reference.
割り当てられたイベント番号、説明およびそれに関連するRFCの参照：レジストリに記録するフィールド。
Initial registry contents:
初期のレジストリの内容：
0, SCSI Async Event, [RFC3720]
0、SCSI非同期イベント、[RFC3720]
1, Logout Request, [RFC3720]
1、ログアウト要求、[RFC3720]
2, Connection drop notification, [RFC3720]
図2に示すように、接続ドロップ通知、[RFC3720]
3, Session drop notification, [RFC3720]
3、セッション通知を削除、[RFC3720]
4, Negotiation Request, [RFC3720]
4、ネゴシエーション要求、[RFC3720]
5, Task termination, this document
5、タスクの終了、このドキュメント
248-254, Vendor-unique, this document
248-254、ベンダー固有の、この文書
255, Vendor-unique, [RFC3720]
255、ベンダー固有の、[RFC3720]
Allocation Policy:
割り当てポリシー：
Standards Action ([IANA])
標準アクション（[IANA]）
Name of the registry: "iSCSI TMF Codes"
レジストリの名称：「iSCSIのTMFコード」
Namespace details: Numerical values that can fit in 7 bits.
名前空間の詳細：7ビットに収まる数値。
Information that must be provided to assign a new value: An IESG-approved standards-track specification defining the semantics and interoperability requirements of the proposed new Code and the fields to be recorded in the registry.
レジストリに記録することが提案された新しいコードとフィールドのセマンティクスとの相互運用性の要件を定義するIESGが承認した標準トラック仕様：新しい値を割り当てるために提供されなければならない情報。
Assignment policy:
割り当てポリシー：
If the requested value is not already assigned, it may be assigned to the requester.
要求された値がすでに割り当てられていない場合は、要求者に割り当てることができます。
9-127: range reserved by IANA for assignment in this registry.
9から127：このレジストリ内の割り当てのためにIANAによって予約範囲。
Fields to record in the registry: Assigned Code, Description, and its associated RFC reference.
割り当てられたコード、説明、およびそれに関連するRFCの参照：レジストリに記録するフィールド。
Initial registry contents:
初期のレジストリの内容：
1, ABORT TASK, [RFC3720]
1、ABORT TASK、[RFC3720]
2, ABORT TASK SET, [RFC3720]
2、ABORT TASK SET、[RFC3720]
3, CLEAR ACA, [RFC3720]
3、CLEAR ACA、[RFC3720]
4, CLEAR TASK SET, [RFC3720]
4、CLEAR TASK SET、[RFC3720]
5, LOGICAL UNIT RESET, [RFC3720]
図5に示すように、論理ユニットRESET、[RFC3720]
6, TARGET WARM RESET, [RFC3720]
6、TARGET WARM RESET、[RFC3720]
7, TARGET COLD RESET, [RFC3720]
7、TARGET COLD RESET、[RFC3720]
8, TASK REASSIGN, [RFC3720]
8、TASK REASSIGN、[RFC3720]
Allocation Policy:
割り当てポリシー：
Standards Action ([IANA])
標準アクション（[IANA]）
Name of the registry: "iSCSI Login Response Status Codes"
レジストリの名称：「iSCSIのログインレスポンスのステータス・コード」
Namespace details: Numerical values; Status-Class (one octet), Status-Detail (one octet) for each possible value of Status-Class except for Vendor-Unique Status-Class (0x0f).
名前空間の詳細：数値。ベンダー独自のステータスクラス（0x0Fの）以外のステータス・クラスの各値のステータス・クラス（1つのオクテット）、ステータス・ディテール（1つのオクテット）。
Information that must be provided to assign a new value: An IESG-approved specification defining the semantics and interoperability requirements of the proposed new Code, its Status-Class affiliation (only if a new Status-Detail value is being proposed for a Status-Class), Status-Class definition (only if a new Status-Class is being proposed), and the fields to be recorded in the registry.
新しいステータス・ディテール値はステータス・クラスのために提案されている場合にのみ、（提案された新しいコードの意味と相互運用性の要件を定義するIESGが承認した仕様で、そのステータスクラス所属：新しい値を割り当てるために提供されなければならない情報）、ステータス・クラス定義（新しいステータスクラスが提案されている場合のみ）、およびレジストリに記録されるフィールド。
Assignment policy:
割り当てポリシー：
If the requested value is not already assigned, it may be assigned to the requester.
要求された値がすでに割り当てられていない場合は、要求者に割り当てることができます。
4-14 and 16-255: range reserved by IANA for assignment in this registry.
4-14と16から255：このレジストリ内の割り当てのためにIANAによって予約範囲。
Fields to record in the Status-Class main registry: Assigned Code, Description, and its associated RFC reference.
ステータスクラスのメインレジストリに記録するフィールド：コード、説明、およびそれに関連するRFCの参照を割り当てられました。
Fields to record in the Status-Detail sub-registries: Status-Class, Assigned Code, Description, and its associated RFC reference.
ステータスディテール・サブレジストリに記録するフィールド：ステータスクラス、コード、説明、およびそれに関連するRFCの参照を割り当てられました。
Initial registry contents (Status-Class):
初期レジストリの内容（ステータスクラス）：
0x00, Success, [RFC3720]
0x00の、成功、[RFC3720]
0x01, Redirection, [RFC3720]
0x01で、リダイレクション、[RFC3720]
0x02, Initiator Error, [RFC3720]
0x02の、イニシエータのエラー、[RFC3720]
0x03, Target Error, [RFC3720]
0x03の、目標誤り、[RFC3720]
0x0f, Vendor-Unique, this document
0x0Fの、ベンダーユニークな、このドキュメント
Initial sub-registry contents (Status-Detail for Status-Class=0x00):
初期のサブレジストリの内容（ステータスクラス= 0x00のためのステータス・ディテール）：
0x00, 0x00, Success, [RFC3720]
$ 00、$ 00、成功、[RFC3720]
1-255: range reserved by IANA for assignment in Status-Class=0 sub-registry.
1-255：ステータスクラス= 0サブレジストリに割り当てのためにIANAによって予約範囲。
Initial sub-registry contents (Status-Detail for Status-Class=0x01):
初期のサブレジストリの内容（ステータスクラス= 0x01のためのステータス・ディテール）：
0x01, 0x01, Temporary move, [RFC3720]
が0x01、0x01の、一時的な移動、[RFC3720]
0x01, 0x02, Permanent move, [RFC3720]
が0x01、0x02の、永続的な移動、[RFC3720]
3-255: range reserved by IANA for assignment in Status-Class=1 sub-registry.
3から255：ステータスクラス= 1つのサブレジストリに割り当てのためにIANAによって予約範囲。
Initial sub-registry contents (Status-Detail for Status-Class=0x02):
初期のサブレジストリの内容（ステータスクラス= 0x02のためのステータス・ディテール）：
0x02, 0x00, Miscellaneous, [RFC3720]
0x02の0x00の、雑多、[RFC3720]
0x02, 0x01, Authentication failure, [RFC3720]
0x02の、0x01の、認証失敗、[RFC3720]
0x02, 0x02, Authorization failure, [RFC3720]
0x02の、0x02の、認可障害、[RFC3720]
0x02, 0x03, Not found, [RFC3720]
0x02の0x03の、見つかりません、[RFC3720]
0x02, 0x04, Target removed, [RFC3720]
0x02の、0x04の、ターゲットを除去、[RFC3720]
0x02, 0x05, Unsupported version, [RFC3720]
0x02の、0x05の、サポートされていないバージョン、[RFC3720]
0x02, 0x06, Too many connections, [RFC3720]
0x02の0x06の、あまりにも多くの接続、[RFC3720]
0x02, 0x07, Missing parameter, [RFC3720]
0x02の0x07の、行方不明のパラメータ、[RFC3720]
0x02, 0x08, Can't include in session, [RFC3720]
0x02の0x08に、セッション中に含めることはできません、[RFC3720]
0x02, 0x09, Unsupported session type, [RFC3720]
0x02の、0x09の、サポートされていないセッション・タイプ、[RFC3720]
0x02, 0x0a, Non-existent session, [RFC3720]
0x02の0x0Aを、存在しないセッション、[RFC3720]
0x02, 0x0b, Invalid during login, [RFC3720]
ログイン時に無効0x02で、0x0Bの、[RFC3720]
12-255: range reserved by IANA for assignment in Status-Class=2 sub-registry.
12から255：ステータスクラス= 2サブレジストリに割り当てのためにIANAによって予約範囲。
Initial sub-registry contents (Status-Detail for Status-Class=0x03):
初期のサブレジストリの内容（ステータスクラス= 0x03のためのステータス・ディテール）：
0x03, 0x00, Target error, [RFC3720]
0x03の、0x00の、目標誤り、[RFC3720]
0x03, 0x01, Service unavailable, [RFC3720]
0x03の、0x01の、サービスが利用できない、[RFC3720]
0x03, 0x02, Out of resources, [RFC3720]
資源のうち、0x03を、0x02の、[RFC3720]
3-255: range reserved by IANA for assignment in Status-Class=3 sub-registry.
3から255：ステータスクラス= 3サブレジストリに割り当てのためにIANAによって予約範囲。
Allocation Policy:
割り当てポリシー：
Standards Action ([IANA])
標準アクション（[IANA]）
Name of the registry: "iSCSI Reject Reason Codes"
レジストリの名前：「iSCSIは理由コードを拒否」
Namespace details: Numerical values that can fit in a single octet.
名前空間の詳細：単一オクテットに収まる数値。
Information that must be provided to assign a new value: A published specification defining the semantics and interoperability requirements of the proposed new Code and the fields to be recorded in the registry.
レジストリに記録することが提案された新しいコードとフィールドのセマンティクスとの相互運用性の要件を定義する公開された仕様：新しい値を割り当てるために提供されなければならない情報。
Assignment policy:
割り当てポリシー：
If the requested value is not already assigned, it may be assigned to the requester.
要求された値がすでに割り当てられていない場合は、要求者に割り当てることができます。
13-255: range reserved by IANA for assignment in this registry.
13から255：このレジストリ内の割り当てのためにIANAによって予約範囲。
Fields to record in the registry: Assigned Code, Description, and its associated RFC reference.
割り当てられたコード、説明、およびそれに関連するRFCの参照：レジストリに記録するフィールド。
Initial registry contents:
初期のレジストリの内容：
0x01, Reserved, [RFC3720]
0x01の、予約、[RFC3720]
0x02, Data digest error, [RFC3720]
0x02の、データダイジェストエラー、[RFC3720]
0x03, SNACK Reject, [RFC3720]
0x03の、スナックは、[RFC3720]を拒否します
0x04, Protocol Error, [RFC3720]
0x04が、プロトコルエラー、[RFC3720]
0x05, Command not supported, [RFC3720]
0x05の、サポートされていないコマンド、[RFC3720]
0x06, Immediate command reject, [RFC3720]
0x06で、即時コマンドは拒否し、[RFC3720]
0x07, Task in progress, [RFC3720]
0x07の、進行中のタスク、[RFC3720]
0x08, Invalid data ack, [RFC3720]
0x08に、無効データACK、[RFC3720]
0x09, Invalid PDU field, [RFC3720]
0x09の、無効なPDUのフィールド、[RFC3720]
0x0a, Long op reject, [RFC3720]
拒否するロングは0x0A、[RFC3720]
0x0b, "Deprecated reason code", this document
0x0Bの、「非推奨の理由コード」、この文書
0x0c, Waiting for Logout, [RFC3720]
0x0Cの、ログアウトを待っている、[RFC3720]
Allocation Policy:
割り当てポリシー：
Standards Action ([IANA])
標準アクション（[IANA]）
Name of the registry: "iSER Opcodes"
レジストリの名前：「のiSERオペコード」
Namespace details: Numerical values that can fit in 4 bits.
名前空間の詳細：4ビットに収まる数値。
Information that must be provided to assign a new value: An IESG-approved specification defining the semantics and interoperability requirements of the proposed new value and the fields to be recorded in the registry.
レジストリに記録することが提案された新しい値とフィールドのセマンティクスとの相互運用性の要件を定義するIESGが承認した仕様：新しい値を割り当てるために提供されなければならない情報。
Assignment policy:
割り当てポリシー：
If the requested value is not already assigned, it may be assigned to the requester.
要求された値がすでに割り当てられていない場合は、要求者に割り当てることができます。
4-15: range reserved by IANA for assignment in this registry.
4-15：このレジストリ内の割り当てのためにIANAによって予約範囲。
Fields to record in the registry: Assigned value, Operation Name, and its associated RFC reference.
割り当てられた値、操作名、およびそれに関連するRFCの参照：レジストリに記録するフィールド。
Initial registry contents:
初期のレジストリの内容：
0x1, iSCSI control-type, [iSER]
0x1の、iSCSIの制御型、[のiSER]
0x2, iSER Hello, [iSER]
0x2の、微粉こんにちは、[微粉]
0x3, iSER HelloReply, [iSER]
0x3の、微粉HelloReply [微粉]
Allocation Policy:
割り当てポリシー：
Standards Action ([IANA])
標準アクション（[IANA]）
[RFC3720] Satran, J., Meth, K., Sapuntzakis, C., Chadalapaka, M., and E. Zeidner, "Internet Small Computer Systems Interface (iSCSI)", RFC 3720, April 2004.
[RFC3720] Satran、J.、メタ、K.、Sapuntzakis、C.、Chadalapaka、M.、およびE. Zeidner、 "インターネットの小さいコンピュータシステム（のiSCSI）"、RFC 3720、2004年4月。
[SPC3] ANSI INCITS 408-2005, SCSI Primary Commands-3.
[SPC3] ANSI INCITS 408から2005、SCSIプライマリコマンド-3。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[IANA] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[IANA] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
[iSER] Ko, M., Chadalapaka, M., Hufferd, J., Elzur, U., Shah, H., and P. Thaler, "Internet Small Computer System Interface (iSCSI) Extensions for Remote Direct Memory Access (RDMA)", RFC 5046, October 2007.
[のiSER]コ、M.、Chadalapaka、M.、Hufferd、J.、Elzur、U.、シャー、H.、およびP.ターラー、「インターネット小型コンピュータシステムインタフェース（iSCSIの）リモートダイレクトメモリアクセスのための拡張機能（RDMA ）」、RFC 5046、2007年10月。
[RFC3721] Bakke, M., Hafner, J., Hufferd, J., Voruganti, K., and M. Krueger, "Internet Small Computer Systems Interface (iSCSI) Naming and Discovery", RFC 3721, April 2004.
[RFC3721] Bakke、M.、ハフナー、J.、Hufferd、J.、Voruganti、K.、およびM.クルーガー、 "インターネットスモールコンピュータシステムインタフェース（iSCSIの）命名および発見"、RFC 3721、2004年4月。
[RFC3723] Aboba, B., Tseng, J., Walker, J., Rangan, V., and F. Travostino, "Securing Block Storage Protocols over IP", RFC 3723, April 2004.
[RFC3723] Aboba、B.、ツェン、J.、ウォーカー、J.、Rangan、V.、およびF. Travostino、 "IP上のセキュリティブロックストレージプロトコル"、RFC 3723、2004年4月。
[RFC3722] Bakke, M., "String Profile for Internet Small Computer Systems Interface (iSCSI) Names", RFC 3722, April 2004.
[RFC3722] Bakke、M.、RFC 3722 "インターネット小型コンピュータシステムインタフェース（iSCSIの）名前のストリングプロフィール"、2004年4月。
[SAM2] ANSI INCITS 366-2003, SCSI Architecture Model-2 (SAM-2).
[SAM2] ANSI INCITS 366から2003、SCSIアーキテクチャモデル2（SAM2）。
[SAM3] ANSI INCITS 402-2005, SCSI Architecture Model-3 (SAM-a3).
【SAM3] ANSI INCITS 402から2005、SCSIアーキテクチャモデル3（SAM-A3）。
[SAM4] T10 Project: 1683-D, SCSI Architecture Model-4 (SAM-4), Work in Progress.
【SAM4] T10プロジェクト：1683-D、SCSIアーキテクチャモデル4（SAM4）、進行中で働いています。
Acknowledgements
謝辞
The IP Storage (IPS) Working Group in the Transport Area of the IETF has been responsible for defining the iSCSI protocol (apart from a host of other relevant IP Storage protocols). The editor acknowledges the contributions of the entire working group.
IETFの交通地域におけるIPストレージ（IPS）ワーキンググループは、（他の関連するIPストレージプロトコルのホストから離れて）iSCSIプロトコルを定義を担当してきました。編集者は全体のワーキンググループの貢献を認めています。
The following individuals directly contributed to identifying [RFC3720] issues and/or suggesting resolutions to the issues clarified in this document: David Black, Gwendal Grignou, Mike Ko, Dmitry Fomichev, Bill Studenmund, Ken Sandars, Bob Russell, Julian Satran, Rob Elliott, Joseph Pittman, Somesh Gupta, Eddy Quicksall, Paul Koning. This document benefited from all of these contributions.
デビッド・ブラック、グエンダルGrignou、マイク・コー、ドミトリーFomichev、ビルStudenmund、ケンSandars、ボブ・ラッセル、ジュリアンSatran、ロブ・エリオット：以下の個人が直接[RFC3720]の問題を特定および/または本文書で明確な問題への解決策を示唆に貢献しました、ジョセフ・ピットマン、Someshグプタ、エディQuicksall、ポールKONING。この文書では、これらの貢献のすべての恩恵を受けました。
Editor's Address
編集者の住所
Mallikarjun Chadalapaka Hewlett-Packard Company 8000 Foothills Blvd. Roseville, CA 95747-5668, USA Phone: +1-916-785-5621 EMail: cbm@rose.hp.com
Mallikarjun cadalapaka havaletta-pakkard同社は8000ブルバードをphuthils。ローズ、K 95747-5668、USA電話：+ 1-916-785-5621 Eメール：ಸಿಬ್ಮ್@ರೋಜ್.ಹಪ್.ಕಂ
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。