iSCSI: A list of all normative sentences

["Michael J. S. Smith \(iReady\)" <msmith@iready.com>]

I wrote a Perl script to extract a list of all sentences from an
RFC/draft that contain the normative words: MUST, SHOULD, and so on.
Such a list seems more useful than the concordances that I have been
sharing so far (it was actually a suggestion John made a while back).
Parsing the text is not as easy as it sounds and I am still improving
things. The current tool works pretty well on the text Internet drafts,
and is still useful on the PDF from Julo's website
(http://www.haifa.il.ibm.com/satran/ips/draft-ietf-ips-iscsi-12-95.pdf).
Here (below) is the output for12-95. This information is useful (to me
anyway) in order to focus on the areas where the draft is normative.
I'll try and include some more useful things like section numbers and so
forth, but it seemed like time was of the essence to get the draft
cleaned up going in to last call - so I included what I currently have.
Ignore the HTML markup (we just use that internally).

Mike Smith
CTO, iReady

NumberOfMUSTsFound = 331 <br>

@SentencesWithMUSTs :
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.

-IPsec transport mode is MAY and authentication MUST be used when
encryption is used.

-Padding bytes SHOULD be sent as 0 (instead of MUST be 0).

-All specified keys except X-* MUST be accepted (2.8.3).

MAY be discarded" into MUST be discarded.

iSCSI targets and initiators MUST support at least one TCP connec-tion
and MAY support several connections in a session.

For this reason the task management command MUST carry the current CmdSN
as a marker of their position in the stream of commands.

An iSCSI target MUST be able to handle at least one immediate task
management command and one immediate non-taskmanagement iSCSI request
per connection at any time.

With the exception of the commands marked for immediate delivery, the
iSCSI target layer MUST deliver the commands for execution in the order
specified by CmdSN.

On any given connection, the iSCSI initiator MUST send the commands in
increasing order of CmdSN, except for commands that are retransmitted
due to digest error recovery and connection recovery.

Comparisons and arithmetic on ExpCmdSN and MaxCmdSN MUST use Serial
Number Arithmetic as defined in [RFC1982] where SERIAL_ BITS =.

The target MUST NOT transmit a MaxCmdSN that is less than ExpCmdSN-1.

The target MUST silently ignore any non-immediate command outside of
this range or non-immediate duplicates within the range.

iSCSI initiators and targets MUST support the command numbering scheme.

If an initiator issues a command retry for a command with CmdSN R on a
connection when the session CmdSN register is Q, it MUST NOT advance the
CmdSN past R + 2** 31 -1 unless a different non-immediate command with
CmdSN equal or greater than Q was issued on the same connection if the
connection is still operational, and the reception of the command is
acknowledged by the target (see Section 8.4 Command Retry and Cleaning
Old Command Instances).

The second non-immediate command when sent, MUST be sent in-order after
the retried command on the same connection.

A target MUST NOT issue a command response or DATA-In PDU with sta-tus
before acknowledging the command.

Initiators and Targets MUST support the response-numbering scheme.

Data and R2T PDUs, transferred as part of some command execution, MUST
be sequenced.

For any given write command, a target MUST issue less than 2** 32 R2Ts.

Any input or output data sequence MUST contain less than 2** 32 numbered
PDUs.

Any other PDU, when received at initiator or target, is a protocol error
and MUST result in the connection being terminated.

Login requests and responses MUST be used exclusively during Login.

On any connection the login phase MUST immediately succeed TCP
connection establishment and a single Login Phase is allowed before
tearing down a connection.

For an iSCSI request issued over a TCP connection, the corresponding
response and/ or requested PDU( s) MUST be sent over the same
connection.

For SCSI commands that require data and/ or a parameter transfer, the
(optional) data and the status for the command MUST be sent over the
same TCP connection to which the SCSI command is currently alle-giant,
illustrating the above rule.

Thus, if an initiator issues a READ command, the target MUST send the
requested data, if any, followed by the status to the initiator over the
same TCP connection that was used to deliver the SCSI command.

If an initiator issues a WRITE command, the initiator MUST send the
data, if any, for that command over the same TCP connection that was
used to deliver the SCSI command.

The target MUST return Ready To Transfer (R2T), if any, and the status
over the same TCP connection that was used to deliver the SCSI command.

Retransmission requests (SNACK PDUs) and the data and status that they
generate MUST also use the same connection.

iSCSI initiators and targets MUST also enforce some ordering rules.

Unsolicited data MUST be sent on every connection in the same order in
which commands were sent.

Each iSCSI node, whether an initiator or target, MUST have an iSCSI
name.

Initiators and targets MUST support the receipt of iSCSI names of up to
the maximum length of 255 bytes.

The initiator MUST present both its iSCSI Initiator Name and the iSCSI
Target Name to which it wishes to connect in the first login request of
a new session or connection.

An iSCSI name MUST be a UTF-8 encoding of a string of Unicode
characters, with the following properties: -it is in Normalization Form
C (see "Unicode Normalization Forms" [UNICODE]) -it contains only the
following characters:.

One of these two type strings MUST be used when constructing an iSCSI
name; any type string not listed here is not allowed, as they cannot be
guaranteed to be unique.

This date MUST be a date during which the naming authority owned the
domain name used in this format, and SHOULD be the date on which the
domain name was acquired by this naming authority.

If a specific implementation performs PDU delivery to the Sync and
Steering layer through multiple operations, it MUST bracket an operation
set used to deliver a single PDU in a manner that the Sync and Steering
Layer can understand.

The Sync and Steering Layer (which is OPTIONAL) MUST retain the PDU end
address within the stream for every delivered iSCSI PDU.

To enable the Sync and Steering operation to perform Steering,
additional information, including identifying tags and buffer offsets,
MUST also be retained for every sent PDU.

On the outgoing path, the Sync and Steering layer MUST map the outgoing
stream addresses from iSCSI stream addresses to TCP stream sequence
numbers.

However, Sync and Steering MUST take into account the additional data
inserted in the stream by UFL.

When used in SCSI parameter data, the SCSI port name MUST be encoded
as:.

After being selected the same TSIH value MUST be used whenever initiator
or target refer to the given session and a TSIH is required.

The following definitions will be used in the rest of this document:
key-name: a string of one or more characters consisting of letters,
digits, dot, minus, plus, commercial at, and underscore, A key-name MUST
begin with a capital letter an must not exceed 63 characters.

Any iSCSI target or initiator MUST support receiving at least 16384
bytes of key= value data in a negotiation sequence except when
indicating support for very long authentication items by offering or
selecting authentication methods such as public key certificates in
which case they MUST support receiving at least 64 kilobytes of key=
value data.

All negotiations are explicit (i.e., the result MUST be based only on
newly exchanged or declared values).

However, the Text Response for a key not understood MUST be key=
NotUnderstood.

All keys in Chapter 11, except for the X-extension format, MUST be
supported by iSCSI initiators and targets and MUST NOT be answered with
NotUnderstood.

A target or initiator receiving a Text Request respective Text Response
with the C flag bit set to 1 MUST answer with a Text Response or Text
Request with no data segment (DataSegmentLength 0).

A Text Request or Text Response PDU having the C flag bit set to 1 MUST
NOT have the F bit set to 1.

The responding party MUST respond with the same key and select first
value that it supports (and is allowed to use for the specific
originator) selected from the originator list.

The constant "None" MUST always be used to indicate a missing function.

If a responder does not understand any particular value in a list it
MUST ignore it.

For simple-value negotiations, the responding party MUST respond with
the same key.

For boolean negotiations (keys taking the values Yes or No), the
responding party MUST respond with the same key and the result of the
negotiation when the received value does not determine that result by
itself.

The initial login request of any connection MUST include the
InitiatorName key= value pair.

For any connection within a session whose type is not "Discovery", the
first login request MUST also include the TargetName key= value pair.

The Login Phase MAY include a SecurityNegotiation stage and a
LoginOperationalNegotiation stage and MUST include at least one of them,
but the included stage MAY be empty except for the mandatory names.

If both stages are used, the SecurityNegotiation MUST precede the
LoginOperationalNegotiation.

Security MUST be completely negotiated within the Login Phase.

During this exchange, the next stage is selected by the target and MUST
NOT exceed the value stated by the initiator.

Targets MUST NOT submit parameters that require an additional initiator
login request in a login response with the T bit set to 1.

The Login Final-Response that accepts a Login Command can come only as a
response to a Login command with the T bit set to 1, and both the
command and response MUST have FullFeaturePhase in the NSG field.

If detected by the target this MUST result in a Login reject (initiator
error).

The initiator MUST drop the connection.

If the iSCSI target implementation supports altering the portal group
configuration (including adding, deleting, and swapping of portals in a
portal group), it MUST return the TargetPortalGroupTag key carrying the
tag value of the servicing portal group.

If the reconfiguration of iSCSI portal groups is a concern in a given
environment, the iSCSI initiator MUST use this key to ascertain that it
had indeed initiated the Login Phase with the intended target portal
group.

-The target MUST reply with the first option in the list it supports and
is allowed to use for the specific initiator unless it does not support
any in which case it MUST answer with "Reject" (see also Section 4.2
Text Mode Negotiation).

-The initiator must be aware of the imminent completion of the
SecurityNegotiation stage and MUST set the T bit to 1 and the NSG to
what it would like the next stage to be.

If the next stage is FullFeaturePhase, the target MUST respond with a
Login Response with the Session ID and the protocol version.

If the security negotiation fails at the target, then the target MUST
send the appropriate Login Response PDU.

The initiator MUST indicate its intent to terminate the negotiation by
setting the T bit to 1; the target sets the T bit to 1 on the last
response.

Whenever parameter action or acceptance are dependent on other
parameters, the dependent parameters MUST be sent after the parameters
on which they depend.

Thus, the TSIH in the Login PDU MUST be non-zero and CID does not change
during a connection reinstatement.

The initiator connection state MUST be CLEANUP_ WAIT (section 5.1) for
attempting a connection reinstatement.

Thus, the TSIH in the Login PDU MUST be zero to signal ses-sion
reinstatement.

The initiator session state MUST be FAILED (Section 5.3 Session State
Diagrams) for attempting a session reinstatement.

The initiator MUST indicate its intent to terminate the negotiation by
setting the F bit to 1; the target sets the F bit to 1 on the last
response.

Targets MUST NOT submit parameters that require an additional initiator
text request in a text response with the F bit set to 1.

Whenever parameter action or acceptance is dependent on other
parameters, the dependent parameters MUST be sent after the parameters
on which they depend; if sent within the same command, a response for a
parameter might imply responses for others.

Whenever the target responds with the F bit set to 0, it MUST set the
Target Transfer Tag to a value other than the default 0xffffffff.

If detected by the target this MUST result in a Reject with a reason of
"protocol error".

The initiator MUST reset the negotiation as outlined above.

Retry MUST NOT be used for reasons other than plugging command sequence
gaps.

If initiators, as part of plugging command sequence gaps as described
above, inadvertently issue retries for allegiant commands already in
progress (i.e., targets did not see the discontinuities in CmdSN
ordering), targets MUST silently discard the duplicate requests if the
CmdSN window had not advanced by then.

Targets MUST support the retry functionality described above.

When an iSCSI command is retried, the command PDU MUST carry the
original Initiator Task Tag and the original operational attributes
(e.g., flags, function names, LUN, CDB etc.) as well as the original
CmdSN.

The command being retried MUST be sent on the same connection as the
original command unless the original connection was already successfully
logged out.

When a target does not support allegiance reassignment, it MUST respond
with a task management response code of "Task failover not supported".

If allegiance reassignment is supported by the target, but the task is
still allegiant to a different connection, the target MUST respond with
a task management response code of "Task still allegiant".

Targets MUST NOT implicitly terminate an active task by sending a Reject
PDU for any PDU exchanged during the life of the task.

The CmdSN of the rejected command PDU (if it carried one) MUST NOT be
considered received by the target (i.e., a command sequence gap must be
assumed for the CmdSN), even though the CmdSN can be reliably
ascertained in this case.

When a data PDU is rejected and its DataSN can be ascertained, a target
MUST advance ExpDataSN for the current data burst if a recovery R2T is
being generated.

When a target or an initiator receives an iSCSI PDU with a format error,
it MUST immediately terminate all transport connections in the session
either with a connection close or with a connection reset and escalate
the format error to session recovery (see Section 6.12.4 Session
Recovery).

When a target receives any iSCSI PDU with a header digest error, it MUST
silently discard the PDU.

When a target receives any iSCSI PDU with a payload digest error, it
MUST answer with a Reject iSCSI PDU with a Reason-code of
DataDigest-Error and discard the PDU.

-If the discarded PDU is a solicited or unsolicited iSCSI data PDU (for
immediate data in a command PDU, non-data PDU rule below applies), the
target MUST do one of the following: a) Request retransmission with a
recovery R2T.

If the target chooses to implement this option, it MUST wait to receive
all the data (signaled by a Data PDU with the final bit set for all
outstanding R2Ts) before sending the response PDU.

When an initiator receives any iSCSI PDU with a header digest error, it
MUST discard the PDU.

When an initiator receives any iSCSI PDU with a payload digest error, it
MUST discard the PDU.

-If the discarded PDU is an iSCSI data PDU, the initiator MUST do one of
the following: a) Request the desired data PDU through SNACK.

In its turn, the target MUST either resend the data PDU or, reject the
SNACK with a Reject PDU with a reason-code of "SNACK Reject" in which
case: i) if the status had not already been sent for the com-mand, the
target MUST terminate the command with an iSCSI response reason( Section
9.4.3 Response) of "SNACK rejected".

Initiator in this case MUST inter-nally signal the completion with the
"SNACK rejected" reason (Section 9.4.3 Response) disregarding any
received status PDU, but must wait for the status to be received before
doing so.

-If the discarded PDU is a response PDU, the initiator MUST do one of
the following: a) Request PDU retransmission with a status SNACK.

The initiator MUST address these implied digest errors as described in
Section 6.5 Digest Errors.

Target MUST address these implied digest errors as described in Section
6.

When an initiator receives an iSCSI status PDU with an out-of-order
StatSN that implies missing responses, it MUST address the one or more
missing status PDUs as described in Section 6.5 Digest Errors.

If the initiator wants to recover the missing data for a command, it
MUST NOT acknowledge the received responses that start from the StatSN
of the interested command, until it has completed receiving all the data
PDUs of the command.

When an initiator receives duplicate R2TSNs (due to proactive
retransmission of R2Ts by the target) or duplicate DataSNs (due to
proactive SNACKs by the initiator), it MUST discard the duplicates.

On a ULP timeout for a command (that carried a CmdSN of n), the iSCSI
initiator MUST abort the command by either using the Abort Task task
management function request, or a "close the connection" Logout if it
intends to continue the session.

If the abort request is received and the original command is miss-ing,
targets MUST consider the original command with that RefCmdSN to be
received and issue a task management response with the response code:
"Function Complete".

-During Login, any failure in negotiation MUST be considered a login
process failure and the Login Phase must be terminated, and with it the
connection.

The operational parameters of the session or the connection MUST
continue to be the values agreed upon during an earlier successful
negotiation (i.e., any partial results of this unsuccessful negotiation
must be undone).

On connection failure, the initiator and target MUST do one of the
following:.

Either side may choose to escalate to session recovery, and the other
side MUST give it precedence.

On a connection failure, a target MUST terminate and/ or discard all the
active immediate commands regard-less of which of the above options is
used (i.e., immediate commands are not recoverable across connection
failures).

Use of within-connection and within-command recovery classes MUST NOT be
attempted before the connection is in Full Feature Phase.

The initiator MUST close the connec-tion.

It then MUST either Logout the failed connection, or Login with an
implied Logout, and reassign connection alle-giance for all commands
still in progress associated with the failed connection on another
connection (that MAY be a newly established connection) using the "Task
reassign" task management function (see Section 9.5.1 Function).

The initiator MUST handle it as a TCP connection failure for the
connec-tion( s) referred to in the Message.

The target MUST close the connection and if more than one connection is
available, the target SHOULD send an Asynchronous Message that indicates
it has dropped the connection.

iSCSI implementations MUST provide means of protection against active
attacks (e.g., pretending to be another identity, message insertion,
deletion, modification, and replaying) and passive attacks (e.g.,
eavesdropping, gaining advantage by analyzing the data sent over the
line).

Whenever an iSCSI initiator gets a response whose keys, or their values,
are not according to the step definition, it MUST abort the connection.

Whenever an iSCSI target gets a response whose keys, or their values,
are not according to the step definition, it MUST answer with a Login
reject with the "Initiator Error" or "Missing Parameter" status (these
statuses are not intended for cryptographically incorrect value, e.g.,
the CHAP response, for which "Authentication Failure" status MUST be
specified).

Compliant iSCSI implementation MUST implement the CHAP authentication
method [RFC1994] (according to Section 10.5 Challenge Handshake.

Implementations MUST support use of up to 128 bits random CHAP secrets,
including the means to generate such secrets and to accept them from an
external generation source.

Implementations MUST NOT provide secret generation (or expansion) means
other than random generation.

3.2 Confidentiality) MUST be used to protect the connection.

Moreover, in this case IKE authentication with group pre-shared keys
MUST NOT be used.

When CHAP is used with secret shorter than 96 bits, a compliant
implementation MUST NOT continue with the login unless it can verify
that IPsec encryption is being used to protect the connection.

Originators MUST NOT reuse the CHAP challenge sent by the Responder for
the other direction of a bi-directional authentication.

Responders MUST check for this condition and close the iSCSI TCP
connection if it occurs.

In iSCSI authentication, the prime modulus N MUST be at least 768 bits.

Upon receiving N and g from the Target, the Initiator MUST verify that
they match a well-known group that satisfies the above requirements and
abort the connection if they do not match.

An iSCSI compliant initiator or target MUST provide data integrity and
authentication by implementing IPsec [RFC2401] with ESP [RFC2406] in
tunnel mode and MAY provide data integrity and authentication by
implementing IPsec with ESP in transport mode.

The IPsec implementation MUST fulfill the following iSCSI specific
requirements:.

-HMAC-SHA1 MUST be implemented [RFC2404].

The ESP anti-replay service MUST also be implemented.

When confidentiality is used it MUST be accompanied by data integrity
and authentication to provide comprehensive protection against
eavesdropping, message insertion, deletion, modification, and replaying.

An iSCSI compliant initiator or target MUST provide confidentiality by
implementing IPsec [RFC2401] with ESP [RFC2406] in tunnel mode and MAY
provide confidentiality by implementing IPsec with ESP in transport
mode.

with the following iSCSI specific requirements: -3DES in CBC mode MUST
be implemented [RFC2451].

The NULL encryption algorithm MUST also be implemented.

A compliant iSCSI implementation MUST meet the key management
requirements of the IPsec protocol suite.

Authentication, security association negotiation, and key management
MUST be provided by implementing IKE [RFC2409] using the IPsec DOI
[RFC2407] with the following iSCSI specific requirements:.

-Peer authentication using a pre-shared key MUST be sup-ported.

-Both IKE Main Mode and Aggressive Mode MUST be supported.

-In the IKE Phase 2 Quick Mode exchanges for creating the Phase 2 SA,
the Identity Payload fields MUST be present.

ID_ IPV4_ ADDR, ID_ IPV6_ ADDR (if the protocol stack supports IPv6) and
ID_ FQDN Identity payloads MUST be supported; ID_ USER_ FQDN MAY be
supported.

The ID_ KEY_ ID Identity Payload MUST NOT be used.

Manual keying MUST NOT be used because it does not provide the necessary
re-keying support.

iSCSI initiators and targets MUST support autosense.

All commands that change the state of the device (as in SPACE com-mands
for sequential access devices, and EXCHANGE MEDIUM for medium changer
device), MUST be issued as non-immediate commands for deter-ministic and
in order delivery to iSCSI targets.

Any compliant sender MUST set all bits not defined and all reserved
fields to zero unless specified otherwise.

Any compliant receiver MUST ignore any bit not defined and all reserved
fields unless specified otherwise.

Initiators MUST NOT use target opcodes and targets MUST NOT use
initiator opcodes.

The TotalAHSLength is used only in PDUs that have an AHS and MUST be 0
in all other PDUs.

The DataSegmentLength MUST be 0 whenever the PDU has no data segment.

While a task exists, this tag MUST uniquely identify the task
session-wide.

For bidirectional operations, an additional header segment MUST be
present in the header sequence that indicates the Bidirectional Read
Expected Data Transfer Length.

In this case, the F bit MUST be set to 1.

If the Expected Data Transfer Length is higher than the FirstBurst-Size
(the negotiated maximum amount of unsolicited data the target will
accept), the initiator MUST send the maximum size of unsolic-ited data
OR ONLY the immediate data.

MUST be used to contain the CDB spillover.

For a response other than "Command Completed at Target" bits 3-6 MUST be
0.

If a SCSI device error is detected while data from the initiator is
still expected (the command PDU did not contain all the data and the
target has not received a Data PDU with the final bit Set), the tar-get
MUST wait until it receives a Data PDU with the F bit set in the last
expected sequence before sending the Response PDU.

iSCSI targets MUST support and enable autosense.

In the case of responses sent due to a retransmis-sion request, the
StatSN MUST be the same as the first time the PDU was sent unless the
connection has since been restarted.

When MaxCmdSN changes at the target while the target has no pending PDUs
to convey this information to the initiator, it MUST generate a NOP-IN
to carry the new MaxCmdSN.

For all these functions, the Task Management Function Response MUST be
returned as detailed in Section 9.6 Task Management Function Response.

According to [SAM2] for all the tasks covered by the task management
response (i.e., with CmdSN not higher than the task management command
CmdSN), additional responses MUST NOT be delivered to the SCSI layer
after the task management response.

The iSCSI target MUST ensure that no responses for the tasks covered by
a task management function are delivered to the iSCSI initiator after
the task management response.

For ABORT TASK SET and CLEAR TASK SET, the issuing initiator MUST
continue to respond to all valid target transfer tags (received via R2T,
Text Response, NOP-In, or SCSI Data-in PDUs) related to the affected
task set, even after issuing the task management request.

The target on its part MUST wait for responses on all affected target
transfer tags before acting on either of these two task management
requests.

If the connection is still active (it is not undergoing an implicit or
explicit logout), ABORT TASK MUST be issued on the same connection to
which the task to be aborted is allegiant at the time the Task
Management Request is issued.

For the LOGICAL UNIT RESET function, the target MUST behave as dictated
by the Logical Unit Reset function in [SAM2].

In addition, for the TARGET COLD RESET, the target MUST then termi-nate
all of its TCP connections to all initiators (all sessions are
terminated).

TASK REASSIGN MUST be received by the target ONLY after the connection
on which the command was previously executing has been successfully
logged-out.

TASK REASSIGN MUST be issued as an immediate command.

For all the other functions this field MUST be set to the reserved value
0xffffffff.

For the ABORT TASK function, initiators MUST always set this to the
CmdSN of the task identified by the Initiator Task Tag field.

The initiator MUST discard any discontiguous data PDUs from the previous
execution and the target MUST retransmit all data previously transmitted
in Data-in PDUs (if any) starting with ExpDataSN.

For the TARGET COLD RESET function, the target MUST then close all of
its TCP connections to all initiators (terminates all sessions).

The response to ABORT TASK SET and CLEAR TASK SET MUST be issued by the
target only after all the commands affected have been received by the
target, the corresponding task management functions have been executed
by the SCSI target and the delivery of all responses delivered until the
task management function completion have been con-firmed (acknowledged
through ExpStatSN) by the initiator on all connections of this session.

Although targets MAY choose to send even non-exception status in
separate responses, initiators MUST support non-exception status in
Data-In PDUs.

DataSegmentLength MUST not exceed MaxRecvPDUDataSize for the direc-tion
it is sent and the total of all the DataSegmentLength of all PDUs in a
sequence MUST not exceed MaxBurstSize (or FirstBurstSize for unsolicited
data).

The target should use the A bit moderately; it MAY set the A bit to 1
only once every MaxBurstSize bytes or on the last Data-In PDU that
concludes the entire requested read data transfer for the task from the
target's perspective, and MUST NOT do so more frequently than this.

On receiving a Data-In PDU with the A bit set to 1, if there are no
holes in the read data until that Data-In PDU, the initiator MUST issue
a SNACK of type DataACK except when it is able to acknowledge the status
for the task immediately via ExpStatSN on other outbound PDUs if the
status for the task is also received; in this latter case
(acknowledgement through ExpStatSN) sending a SNACK of type DataACK in
response to the A bit is not mandatory but if it is done it must not be
sent after the status acknowledgement through ExpStatSN.

If the initiator has detected holes in the read data until that Data-In
PDU, it MUST postpone issuing the SNACK of type DataACK until the holes
are filled.

An initiator also MUST NOT acknowledge the status for the task before
those holes are filled.

On incoming data, the Target Transfer Tag MUST be provided by the target
if the A bit is set to 1.

If the Target Transfer Tag is provided, then the LUN field MUST hold a
valid value and be consistent with whatever was specified with the
command; otherwise, the LUN field is reserved.

This field MUST ONLY be set if the S bit is set to 1.

Any input or output data sequence MUST contain less than 2** 32 numbered
PDUs.

The sending of 0 length data segments should be avoided, but initiators
and targets MUST be able to properly receive 0 length data segments.

If the command is completed with an error, then the response and sense
data MUST be sent in a SCSI Response PDU (i.e., MUST NOT be sent in a
SCSI Data packet).

For Bidirectional commands, the status MUST be sent in a SCSI Response
PDU.

If this bit is set to 1 the F bit MUST also be set to 1.

In order to allow write operations without an explicit initial R2T, the
initiator and target MUST have negotiated the key InitialR2T to No
during Login.

If an R2T is answered with a single Data-out PDU, the Buffer Offset in
the Data PDU MUST be the same as the one specified by the R2T and the
data length of the Data PDU MUST be the same as the Desired Data
Transfer Length specified in the R2T.

If the R2T is answered with a sequence of Data PDUs, the Buffer Offset
and Length MUST be within the range of those specified by R2T, and the
last PDU MUST have the F bit set to 1.

If DataPDUInOrder is set to Yes, the Buffer Offsets and Lengths for
consecutive PDUs MUST form a continuous non-overlapping range and the
PDUs MUST be sent in increasing offset order.

Within a connection, outstanding R2Ts MUST be fulfilled by the initiator
in the order in which they were received.

The number of R2Ts in a command MUST be less than 2** 32-1.

The Desired Data Transfer Length MUST NOT be 0 and MUST not exceed
MaxBurstSize.

There is no protocol rule about the Target Transfer Tag except that the
value 0xffffffff is reserved and MUST never be sent by a target in an
R2T.

This Async Message MUST be sent on the same connection as the one
requesting to be logged out.

The initiator MUST honor this request by issuing a Logout as early as
possible, but no later than Parameter3 seconds.

Initiator MUST send a Logout with a reason code of "Close the
connection" (if not the only connection) OR "Close the session" to close
all the connections (if using multiple connec-tions).

An initiator MUST have at most one outstanding Text Request on a
connection at any given time.

If the command is sent as part of a sequence of text requests and
responses, the Initiator Task Tag MUST be the same for all the requests
within the sequence (similar to linked SCSI commands).

It MUST do so whenever it sets the F bit to 0 in the response.

The initiator MUST ignore the Target Transfer Tag in the Text Response
when the F bit is set to 1.

If the Target Transfer Tag is not 0xffffffff the LUN field MUST be the
one sent by the target in the Text Response.

The data lengths of a text request MUST NOT exceed the iSCSI target
MaxRecvPDUDataSize (a per connection and per direction negotiated
parameter).

A Text Response with the F bit set to 1 MUST NOT contain key= value
pairs that may require additional answers from the initiator.

A Text Response with the F bit set to 1 MUST have a Target Transfer Tag
field set to the reserved value of 0xffffffff.

A Text Response with the F bit set to 0 MUST have a Target Transfer Tag
field set to a value other than the reserved 0xffffffff.

When a target has more work to do (e.g., cannot transfer all the
remaining text data in a single Text Response or has to continue the
negotiation) and has enough resources to proceed, it MUST set the Target
Transfer Tag to a value other than the reserved value of 0xffffffff.

Otherwise the Target Transfer Tag MUST be set to 0xffffffff.

The initiator MUST copy the Target Transfer Tag and LUN in its next
request to indicate that it wants the rest of the data.

The data lengths of a text request MUST NOT exceed the iSCSI initia-tor
MaxRecvPDUDataSize (a per connection and per direction negotiated
parameter).

After establishing a TCP connection between an initiator and a tar-get,
the initiator MUST start a Login Phase to gain further access to the
target's resources.

All Login requests within the Login Phase MUST carry the same
Ver-sion-max.

The target MUST use the value presented with the first login request.

All Login requests within the Login Phase MUST carry the same
Ver-sion-min.

The target MUST use the value presented with the first login request.

A vendor or organization with one or more OUIs, or one or more
Enterprise Numbers, MUST use at least one of these numbers and select
the appropriate value for the T field when its components generate
ISIDs.

An OUI or EN MUST be set in the corresponding fields in network byte
order (byte big-endian).

If the ISID is derived from something assigned to a hardware adapter or
interface by a vendor, as a preset default value, it MUST be
configurable to a value assigned according to the SCSI port behavior
desired by the system in which it is installed (see Section 8.1.1
Conservative Reuse of ISIDs and Section 8.1.2 iSCSI Name, ISID and TPGT
Use) and the resultant ISID MUST also be persistent over power cycles,
reboot, card swap etc.

The reserved value 0 MUST be used on the first connection for a new
session.

Otherwise the TSIH sent by the target at the conclusion of successful
login of the first connection for this session MUST be used.

All Login requests within a Login Phase MUST carry the same TSIH.

The target MUST check the value presented with the first login request
and act as specified in Section 4.3.1 Login Phase Start.

All Login requests within the Login Phase MUST carry the same CID.

The target MUST use the value presented with the first login request.

If the login request is a leading login request the target MUST use the
value presented in CmdSN as the target value for ExpCmdSN.

All keys in Chapter 11, except for the X-extension format, MUST be
supported by iSCSI initiators and targets.

All Login responses within the Login Phase MUST carry the same
Version-max.

The initiator MUST use the value presented as a response to the first
login request.

All Login responses within the Login Phase MUST carry the same
Version-active.

The initiator MUST use the value presented as a response to the first
login request.

For a new session, the target MUST generate a non-zero TSIH and return
it in the Login Final-Response (see Section 4.3 Login Phase).

All of the redirec-tion status class responses MUST return one or more
text key parameters of the type "TargetAddress", which indicates the
target's new address.

If the Status Class is not 0, the initiator and target MUST close the
TCP connection.

A login response with a T bit set to 1 MUST NOT contain key= value pairs
that may require additional answers from the initiator within the same
stage.

If the status class is 0, the T bit MUST NOT be set to 1 if the T bit in
the request was set to 0.

All keys in Chapter 11, except for the X-extension format, MUST be
supported by iSCSI initiators and targets.

After sending the Logout PDU, an initiator MUST NOT send any new iSCSI
commands on the closing connection.

If the Logout is intended to close the session, new iSCSI commands MUST
NOT be sent on any of the connections participating in the session.

When receiving a Logout request with the reason code of "close the
connection" or "close the session", the target MUST abort all pending
commands, whether acknowledged or not, on that connection or session
respectively.

When receiving a Logout request with the reason code "remove connection
for recovery", the target MUST discard all requests not yet acknowledged
that were issued on the specified connection and suspend all data/
status/ R2T transfers on behalf of pending commands on the specified
connection.

After receiving the Logout response and attempting to receive the FIN
(if still possible), the initiator MUST completely close the loggingout
connection.

If an initiator intends to start recovery for a failing connection, it
MUST use either the Logout command to "clean-up" the target end of a
failing connection and enable recovery to start, or use the Login
command with a non-zero TSIH and the same CID on a new connection for
the same effect (see Section 9.14.2 CID).

If the tasks terminated in any of the above cases are SCSI tasks, they
MUST be internally terminated with CHECK CONDITION status with a sense
key of unit attention and ASC/ ASCQ values of 0x6E/ 0x00 (COMMAND TO
LOGICAL UNIT FAILED).

After Logout, the TCP connection referred by the CID MUST be closed at
both ends (or all connections must be closed if the logout reason was
session close).

The numbered-response( s) or R2T( s), requested by a SNACK, MUST be
delivered as exact replicas of the ones the initiator missed except for
the fields ExpCmdSN, MaxCmdSN and ExpDataSN which MUST carry the current
values.

The numbered Data-In PDUs, requested by a SNACK with a RunLength
different from 0, MUST be delivered as exact replicas of the ones the
initiator missed except the fields ExpCmdSN and MaxCmdSN which MUST
carry the current values.

Any SNACK that requests a numbered-response, Data, or R2T that was not
sent by the target MUST be rejected with a reason code of "Protocol
error".

Data/ R2T SNACK for a command MUST precede status acknowledgement for
the given command.

For Status SNACK and DataACK, the Initiator Task Tag MUST be set to the
reserved value 0xffffffff.

In all other cases, the Initiator Task Tag field MUST be set to the
Initiator Task Tag of the referenced command.

In all other cases, the Target Transfer Tag field MUST be set to the
reserved value of 0xffffffff.

If the target supports recovery within connection, it MAY reject the
SNACK after which it MUST issue an Asynchronous Message PDU with an
iSCSI event that indicates "Request Logout".

If an initiator operates at ErrorRecoveryLevel 1 or higher, it MUST
issue a SNACK of type DataACK after receiving a Data-In PDU with the A
bit set to 1.

However, if the initiator has detected holes in the input sequence, it
MUST postpone issuing the SNACK of type DataACK until the holes are
filled.

The RunLength MUST also be 0 for a DataACK SNACK.

The first data SNACK issued after initiator's MaxRecvPDUDataSize
decreased, for a command issued on the same connection before the change
in MaxRecvPDUDataSize, MUST use RunLength "0" to request retransmission
of any number of PDUs (including one).

In all the cases in which a pre-instantiated SCSI task is terminated
because of the reject, the target MUST issue a proper SCSI command
response with CHECK CONDITION as described in Section 9.4.3 Response.

If the error is detected while data from the initiator is still expected
(the command PDU did not contain all the data and the target has not
received a Data-out PDU with the Final bit 1), the target MUST wait
until it receives the Data-out PDU with the F bit set to 1 before
sending the Response PDU.

When used as a ping command, the Initiator Task Tag MUST be set to a
valid value (not the reserved 0xffffffff).

Upon receipt of a NOP-In with the Target Transfer Tag set to a valid
value (not the reserved 0xffffffff), the initiator MUST respond with a
NOP-Out.

In this case, the NOP-Out Target Transfer Tag MUST con-tain a copy of
the NOP-In Target Transfer Tag.

When a target receives the NOP-Out with a valid Initiator Task Tag, it
MUST respond with a Nop-In Response (see NOP-In).

The NOP-Out MUST have the Target Transfer Tag set only if it is issued
in response to a NOP-In with a valid Target Transfer Tag.

When the Target Transfer Tag is set, the LUN field MUST also be cop-ied
from the NOP-In.

When a target receives the NOP-Out with a valid Initiator Task Tag (not
the reserved value 0xffffffff), it MUST respond with a NOP-In with the
same Initiator Task Tag that was provided in the NOP-Out Command.

It MUST also duplicate up to the first MaxRecvPDUDataSize bytes of the
initiator provided Ping Data.

For such a response, the Target Transfer Tag MUST be 0xffffffff.

When a target sends a NOP-In with the Initiator Task Tag set to
0xffffffff) it MUST NOT send any data in the data segment
(DataSegmentLength MUST be 0).

If the target is initiating a NOP-In without wanting to receive a
corresponding NOP-Out, this field MUST hold the reserved value of
0xffffffff.

A LUN MUST be set to a correct value when the Target Transfer Tag is
valid (not the reserved value 0xffffffff).

The initiator and target MUST implement CHAP.

For KRB5 (Kerberos V5) [RFC1510], the initiator MUST use:.

If the initiator authentication fails, the target MUST respond with a
Login reject with "Authentication Failure" status.

Otherwise, if the initiator has selected the mutual authentication
option (by setting MUTUAL-REQUIRED in the ap-options field of the KRB_
AP_ REQ), the target MUST reply with: KRB_ AP_ REP=< KRB_ AP_ REP> where
KRB_ AP_ REP is the server's response message as defined in [RFC1510].

If mutual authentication was selected and target authentication fails,
the initiator MUST close the connection.

KRB_ AP_ REQ and KRB_ AP_ REP are large-binary-values and their binary
length (not the length of the character string that represents them in
encoded form) MUST not exceed 65536 bytes.

For SPKM1 and SPKM2 [RFC2025], the initiator MUST use: SPKM_ REQ=<
SPKM-REQ> where SPKM-REQ is the first initiator token as defined in
[RFC2025].

If the initiator authentication fails, the target MUST return an error.

Otherwise, if the AuthMethod is SPKM1 or if the initiator has selected
the mutual authentication option (by setting mutual-state bit in the
options field of the REQ-TOKEN in the SPKM-REQ), the tar-get MUST reply
with: SPKM_ REP_ TI=< SPKM-REP-TI> where SPKM-REP-TI is the target token
as defined in [RFC2025].

If mutual authentication was selected and target authentication fails,
the initiator MUST close the connection.

Otherwise, if the AuthMethod is SPKM1, the initiator MUST continue with:
SPKM_ REP_ IT=< SPKM-REP-IT> where SPKM-REP-IT is the second initiator
token as defined in [RFC2025].

If the initiator authentication fails, the target MUST answer with a
Login reject with "Authentication Failure" status.

All the SPKM-* tokens are large-binary-values and their binary length
(not the length of the character string that represents them in encoded
form) MUST not exceed 65536 bytes.

For SRP [RFC2945], the initiator MUST use: SRP_ U=< user> TargetAuth=
Yes /* or TargetAuth= No */ The target MUST answer with a Login reject
with the "Authorization Failure" status or reply with:.

SRP_ N=< N> SRP_ g=< g> SRP_ s=< s> The initiator MUST either close the
connection or continue with: SRP_ A=< A> The target MUST answer with a
Login reject with the "Authentication Failure" status or reply with:.

SRP_ B=< B> The initiator MUST close the connection or continue with:
SRP_ M=< M> If the initiator authentication fails, the target MUST
answer with a Login reject with "Authentication Failure" status.

Otherwise, if the initiator sent TargetAuth= Yes in the first message
(requiring target authentication), the target MUST reply with:.

SRP_ HM=< H( A | M | K)> If the target authentication fails, the
initiator MUST close the connection.

The length of N, g, s, A, B, M in binary form (not the length of the
character string that represents them in encoded form) MUST not exceed
1024 bytes.

For CHAP [RFC1994], the initiator MUST use:.

The target MUST answer with a Login reject with the "Authentication
Failure" status or reply with:.

The initiator MUST continue with: CHAP_ N=< N> CHAP_ R=< R> or, if it
requires target authentication, with: CHAP_ N=< N> CHAP_ R=< R> CHAP_
I=< I> CHAP_ C=< C> If the initiator authentication fails, the target
MUST answer with a Login reject with "Authentication Failure" status.

Otherwise, if the initiator required target authentication, the target
MUST reply with CHAP_ N=< N> CHAP_ R=< R> If target authentication
fails, the initiator MUST close the connection.

Where N, (A, A1, A2), I, C, and R are (correspondingly) the Name,
Algorithm, Identifier, Challenge, and Response as defined in [RFC1994],
N is a text string, A, A1, A2, and I are numbers, and C and R are
binaryvalues and their binary length (not the length of the character
string that represents them in encoded form) MUST not exceed 1024 bytes.

When the Initiator and Target agree on a digest, this digest MUST be
used for every PDU in Full Feature Phase.

The initiator of the TCP connection MUST provide this key to the remote
endpoint in the first login request if the initiator is not establishing
a discovery session.

host90 InitiatorName= iSCSI The initiator of the TCP connection MUST
provide this key to the remote endpoint at the first Login of the Login
Phase for every connection.

Scope: SW TargetAlias=< iSCSI-local-name-value> Examples: TargetAlias=
Bob-s Disk TargetAlias= Database Server 1 Log Disk TargetAlias= Web
Server 3 Disk 20 If a target has been configured with a human-readable
name or description, this name MUST be communicated to the initiator
during a Login Response PDU.

If ImmediateData is set to No and InitialR2T is set to Yes, then the
initiator MUST NOT send unsolicited data and the target MUST reject
unsolicited data with the corresponding response code.

If ImmediateData is set to No and InitialR2T is set to No, then the
initiator MUST NOT send unsolicited immediate data, but MAY send one
unsolicited burst of Data-OUT PDUs.

The responder MUST select a value that does not exceed the offered
value.

FirstBurstSize MUST NOT exceed MaxBurstSize.

The responder MUST select a value that does not exceed the offered
value.

The responder MUST select a value that does not greater the offered
value.

The responder MUST select a value that does not exceed the offered
value.

If DataSequenceInOrder is set to Yes, Data Sequences MUST be transferred
using continuously non-decreasing sequence offsets (R2T buffer offset
for writes, or the smallest SCSI Data-In buffer offset within a read
data sequence).

MaxOustandingR2T MUST be set to 1 in this case.

The responder MUST select a value that does not exceed the offered
value.

When reduced to iSCSI terms, markers MUST indicate the offset to a
4-byte word boundary in the stream.

The SendTargets command MUST only be sent during the Full Feature Phase
of a normal or discovery session.

A system that contains targets MUST support discovery sessions on each
of its IP addresses, and MUST support the SendTargets command on the
discovery session.

A target MUST support the SendTargets com-mand on operational sessions;
these will only return address information about the target to which the
session is connected, and do not return information about other targets.

The text key MUST be SendTargets.

This value MUST be supported on a discovery session, and MUST NOT be
supported on an operational session.

This value MUST be supported on discovery sessions.

A discovery session MUST be capable of returning addresses for those
targets that would have been returned had value= all been designated.

This MUST be supported on operational sessions, and MUST NOT return
targets other than the one to which the session is logged in.

A SendTargets response MUST NOT not contain target names if there are no
targets for the requesting initiator to access.

A SendTargets response MUST NOT contain iSCSI default target names.
<br>

-----------------------------------------------------------------------
<br>

NumberOfSHOULDsFound = 37 <br>

@SentencesWithSHOULDs :
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.

-ACA is SHOULD.

-Changed the FIM SHOULD to should(!).

-Padding bytes SHOULD be sent as 0 (instead of MUST be 0).

Initiators undertake recovery actions if the difference is greater than
an implementation defined constant that SHOULD NOT exceed 2** 31-1.

A graceful transport connection shutdown SHOULD be initiated by either
party only when the connection is not in iSCSI Full Feature Phase.

A target MAY terminate a Full Feature Phase connection on internal
exception events, but it SHOULD announce the fact through an
Asynchronous Message PDU.

This date MUST be a date during which the naming authority owned the
domain name used in this format, and SHOULD be the date on which the
domain name was acquired by this naming authority.

The first Login Response PDU during the Login Phase from the iSCSI
target SHOULD return the TargetPortalGroupTag key that contains the tag
value of the iSCSI portal group servicing the Login Request PDU.

If the security negotiation fails at the initiator, the initiator SHOULD
close the connection.

In reassigning connection allegiance for a command, the targets SHOULD
continue the command from its current state.

For example, when reassigning read commands, the target SHOULD take
advantage of ExpDataSN field provided by the Task Management Function
Request (which must be set to zero if there was no data transfer) and
bring the read command to completion by sending the remaining data and
sending (or resending) the status.

To avoid a race with the target, which may already have a recovery R2T
or a termination response on its way, an initiator SHOULD NOT originate
a SNACK for an R2T based on its internal timeouts (if any).

The target MUST close the connection and if more than one connection is
available, the target SHOULD send an Asynchronous Message that indicates
it has dropped the connection.

Although technically possible, iSCSI SHOULD NOT be configured with-out
security.

-AES CBC MAC with XCBC extensions SHOULD be implemented [AESCBC].

-AES in Counter mode SHOULD be implemented [AESCTR] (NOTE: This is still
subject to the IPsec WG's standardization plans).

DES in CBC mode SHOULD NOT be used due to its inherent weakness.

Peer authentication using the public key encryption methods outlined in
IKE sections 5.2 and 5.3[ 7] SHOULD NOT be used.

-When digital signatures are used to achieve authentication, an IKE
negotiator SHOULD use IKE Certificate Request Payload( s) to specify the
certificate authority.

IKE negotia-tors SHOULD check the pertinent Certificate Revocation List
(CRL) before accepting a PKI certificate for use in IKE authentication
procedures.

IKE main mode with pre-shared key authentication method SHOULD NOT be
used when either the initiator or the target uses dynamically assigned
IP addresses.

The IP Subnet, IP Address Range, ID_ DER_ ASN1_ DN, ID_ DER_ ASN1_ GN
formats SHOULD NOT be used.

When IPsec is used the receipt of an IKE Phase 2 delete message SHOULD
NOT be interpreted as a reason for tearing down the iSCSI TCP
connection.

As iSCSI can have many commands in-flight between initiator and target,
iSCSI initiators and targets SHOULD support ACA.

A consideration of the above factors for SCSI tape devices as an example
suggests that implementations SHOULD use ErrorRecoveryLevel= 1 when
transport connection failure is not a concern, and ErrorRecoveryLevel= 2
when the connection failure is also of high likelihood during a backup/
retrieval.

The padding bytes SHOULD be 0.

The padding bytes SHOULD be sent as 0.

If neither bit is set, the Residual Count field SHOULD be zero.

If neither bit is set, the Bidirectional Read Residual Count field
SHOULD be zero.

The issuing initiator SHOULD however terminate (i.e. by setting the Fbit
to 1) these response sequences as quickly as possible, and it is
recommended to terminate all responses with no data.

The Data Segments of Data-in and Data-out PDUs SHOULD be filled to the
integer number of 4 byte words (real payload) unless the F bit is set to
1.

If DataSequenceInOrder is Yes, then consecutive R2Ts SHOULD refer to
continuous non-overlapping ranges.

Once this message is received, the initiator SHOULD NOT issue new iSCSI
commands.

For the Algorithm, as stated in [RFC1994], one value is required to be
implemented: 5 (CHAP with MD5) To guarantee interoperability, initiators
SHOULD always offer it as one of the proposed algorithms.

This key SHOULD be sent by an initiator within the Login Phase, if
available.

If a SendTargets response reports an iSCSI address for a target, it
SHOULD also report all other addresses in its portal group in the same
response.
<br>

-----------------------------------------------------------------------
<br>

NumberOfSHALLsFound = 1 <br>

@SentencesWithSHALLs :
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.
<br>

-----------------------------------------------------------------------
<br>

NumberOfREQUIREDsFound = 5 <br>

@SentencesWithREQUIREDs :
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.

Responses are REQUIRED in all other cases, and the value chosen and sent
by the responder becomes the outcome of the negotiation.

Otherwise, if the initiator has selected the mutual authentication
option (by setting MUTUAL-REQUIRED in the ap-options field of the KRB_
AP_ REQ), the target MUST reply with: KRB_ AP_ REP=< KRB_ AP_ REP> where
KRB_ AP_ REP is the server's response message as defined in [RFC1510].

I-> Login (CSG, NSG= 0,1 T= 1) KRB_ AP_ REQ=< krb_ ap_ req> (krb_ ap_
req contains the Kerberos V5 ticket and authenticator with
MUTUAL-REQUIRED set in the ap-options field) If the authentication is
successful, the target proceeds with: T-> Login (CSG, NSG= 0,1 T= 1)
KRB_ AP_ REP=< krb_ ap_ rep> (krb_ ap_ rep is the Kerberos V5 mutual
authentication reply) If the authentication is successful, the initiator
may proceed with:.

T-> Login-PR (CSG, NSG= 0,0 T= 0) AuthMethod= KRB5 I-> Login (CSG, NSG=
0,1 T= 1) KRB_ AP_ REQ= krb_ ap_ req (MUTUAL-REQUIRED not set in the
ap-options field of krb_ ap_ req) If the authentication is successful,
the target proceeds with: T-> Login (CSG, NSG= 0,1 T= 1) I-> Login (CSG,
NSG= 1,0 T= 0).
<br>

-----------------------------------------------------------------------
<br>

NumberOfRECOMMENDEDsFound = 1 <br>

@SentencesWithRECOMMENDEDs :
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.
<br>

-----------------------------------------------------------------------
<br>

NumberOfMAYsFound = 72 <br>

@SentencesWithMAYs :
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.

-IPsec transport mode is MAY and authentication MUST be used when
encryption is used.

MAY be discarded" into MUST be discarded.

iSCSI targets and initiators MUST support at least one TCP connec-tion
and MAY support several connections in a session.

To enable command recovery, the target MAY maintain enough state
information to enable data and status recovery after a connection
failure.

As part of the login process, the initiator and target MAY wish to
authenticate each other and set a security association protocol for the
session.

In order to protect the TCP connection, an IPsec security associa-tion
MAY be established before the Login request.

However, consecutive commands that are part of a SCSI linked
commandchain task MAY use different connections.

During the iSCSI Full Feature Phase, the initiator and target MAY
interleave unrelated SCSI commands, their SCSI Data, and responses over
the session.

A target that receives data out of order MAY terminate the session.

A target MAY terminate a Full Feature Phase connection on internal
exception events, but it SHOULD announce the fact through an
Asynchronous Message PDU.

Sync and Steering MAY also restrict the type of transformations UFL may
perform on the stream.

b) Discoverysession -a session opened only for target discovery; the
target MAY accept only text requests with the SendTar-gets key and a
logout request with reason "close the session".

A range or a large-numerical-value MAY ONLY be offered if it is
explicitly allowed for a key.

An offer of a value not admissible (e.g., not within the specified
bounds) MAY be answered with the constant "Reject" or the responder MAY
select an admissible value.

The initial login request of the first connection of a session MAY also
include the SessionType key= value pair.

The Login Phase MAY include a SecurityNegotiation stage and a
LoginOperationalNegotiation stage and MUST include at least one of them,
but the included stage MAY be empty except for the mandatory names.

The initiator and target MAY want to negotiate authentication
parameters.

The initiator MAY also send proprietary options.

Operational parameter negotiation during the login MAY be done:.

Operational parameter negotiation MAY involve several Login
requestresponse exchanges started and terminated by the initiator.

Some operational parameters MAY be negotiated outside (after) the Login
Phase.

Operational parameter negotiation MAY involve several text
request-response exchanges, which the initiator always starts and
terminates and uses the same Initiator Task Tag.

An initiator MAY reset an operational parameter negotiation by issu-ing
a Text request with the Target Transfer Tag set to the value 0xffffffff
after receiving a response with the Target Transfer Tag set to a value
other than 0xffffffff.

It is also assumed that at the target, incoming data (read data) MAY be
kept for recovery or it can be re-read from a device server.

However, targets MAY choose to send/ receive the entire data on a
reassignment of connection allegiance, and it is not considered an
error.

The target MAY advance its ExpDataSN if it does not attempt to recover
the lost data PDU.

An iSCSI initiator MAY attempt to plug a command sequence gap on the
target end (in the absence of an acknowledgement of the command by way
of ExpCmdSN) before the ULP timeout by retrying the unacknowl-edged
command, as described in Section 6.1 Retry and Reassign in Recovery.

The latter MAY be used periodically by highly reliable implementations.

Initiators and targets MAY also use the keep-alive option on the TCP
connection to enable early link failure detection on otherwise idle
links.

In every case, they detail the lowest class recovery that MAY be
attempted.

Both the iSCSI target and initiator MAY escalate the error handling to
an error recovery class, which impacts a larger number of iSCSI tasks in
any of the cases identified in the following discussion.

It then MUST either Logout the failed connection, or Login with an
implied Logout, and reassign connection alle-giance for all commands
still in progress associated with the failed connection on another
connection (that MAY be a newly established connection) using the "Task
reassign" task management function (see Section 9.5.1 Function).

Very simple initiators and targets MAY perform session recovery on all
iSCSI errors and therefore place the burden of recovery on the SCSI
layer and above.

An iSCSI compliant initiator or target MUST provide data integrity and
authentication by implementing IPsec [RFC2401] with ESP [RFC2406] in
tunnel mode and MAY provide data integrity and authentication by
implementing IPsec with ESP in transport mode.

An iSCSI compliant initiator or target MUST provide confidentiality by
implementing IPsec [RFC2401] with ESP [RFC2406] in tunnel mode and MAY
provide confidentiality by implementing IPsec with ESP in transport
mode.

Certificate-based peer authentication using digital signatures MAY be
supported.

ID_ IPV4_ ADDR, ID_ IPV6_ ADDR (if the protocol stack supports IPv6) and
ID_ FQDN Identity payloads MUST be supported; ID_ USER_ FQDN MAY be
supported.

MAY follow.

The data segment MAY also be followed by a data-digest.

It MAY be followed by Additional Header Segments (AHS), a Header-Digest,
a Data Segment, and/ or a Data-Digest.

The R and W MAY both be 1 when the corresponding Expected Data Transfer
Lengths are 0, but they CANNOT both be 0 when the corresponding Expected
Data Transfer Length and Bidirectional Read Expected Data Transfer
Length are not 0.

For some iSCSI responses, the response data segment MAY contain some
response related information, (e.g., for a target failure, it may
contain a vendor specific detailed description of the failure).

The iSCSI initia-tor MAY deliver to the SCSI layer all responses
received before the task management response (i.e., it is a matter of
implementation if the SCSI responses -received before the task
management response but after the task management request was
issued -are delivered to the SCSI layer by the iSCSI layer in the
initiator).

In case all or part of the response sequence is not received (due to
digest errors) for a valid TTT, the target MAY treat it as a case of
within-command error recovery class (section 6.12.1) if it is supporting
ErrorRecoveryLevel >= 1, or alternatively may drop the connection to
complete the requested task set function.

Target Reset MAY also be subject to SCSI access controls for the
requesting initia-tor.

Although targets MAY choose to send even non-exception status in
separate responses, initiators MUST support non-exception status in
Data-In PDUs.

It MAY be used as a "change direction" indication for Bidirectional
operations that need such a change.

The target should use the A bit moderately; it MAY set the A bit to 1
only once every MaxBurstSize bytes or on the last Data-In PDU that
concludes the entire requested read data transfer for the task from the
target's perspective, and MUST NOT do so more frequently than this.

An R2T MAY be answered with one or more SCSI Data-out PDUs with a
matching Target Transfer Tag.

If the last PDU (marked with the F bit) is received before the Desired
Data Transfer Length is transferred, a target MAY choose to Reject that
PDU with "Protocol error" reason code.

The target MAY reject any new I/ O requests that it receives after this
Message with the reason code "Waiting for Logout".

The AsyncVCode details the vendor code, and data MAY accompany the
report.

For an iSCSI Event, additional vendor-unique data MAY accompany the
Async event.

Initiators MAY ignore the data when not understood while processing the
rest of the PDU.

A target MAY reset its internal negotiation state if an exchange is
stalled by the initiator for a long time or if it is running out of
resources.

The text response MAY refer to key= value pairs presented in an earlier
text request and the text in the request may refer to earlier responses.

The initiator MAY provide some basic parameters in order to enable the
target to determine if the initiator may use the target's resources and
the initial text parameters for the security exchange.

This MAY be due to a request for a resource for which the initiator does
not have permission.

The initiator MAY provide some basic parameters in order to enable the
target to determine if the initiator may use the target's resources and
the initial text parameters for the security exchange.

An initiator MAY use a logout command to remove a connection from a
session or to close an entire session.

An iSCSI target that does not support recovery within connection MAY
reject the status SNACK.

If the target supports recovery within connection, it MAY reject the
SNACK after which it MUST issue an Asynchronous Message PDU with an
iSCSI event that indicates "Request Logout".

An initiator MAY ignore the A bit if it deems that the bit is being set
aggressively by the target (i.e., before the MaxBurstSize limit is
reached).

Proprietary algorithms MAY also be negotiated for digests.

If ImmediateData is set to No and InitialR2T is set to No, then the
initiator MUST NOT send unsolicited immediate data, but MAY send one
unsolicited burst of Data-OUT PDUs.

If ImmediateData is set to Yes and InitialR2T is set to No, then the
initiator MAY send unsolicited immediate data and/ or one unsolicited
burst of Data-OUT PDUs.

The initiator and target MAY indicate their readiness to receive and/ or
send markers during login separately for each connection.

If a receiver indicates that it desires a marker, the sender MAY agree
(during negotiation) and provide the marker at the desired interval.

An initiator MAY make use of the SendTargets as it sees fit.

A discovery session MAY respond to a SendTargets request with its
complete list of targets, or with a list of targets that is based on the
name of the initiator logged in to the session.

The initiator MAY keep the session to a default target open, and MAY
send subsequently SendTargets commands to discover new targets.
<br>

-----------------------------------------------------------------------
<br>

NumberOfOPTIONALsFound = 4 <br>

@SentencesWithOPTIONALs :
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.

The Sync and Steering Layer (which is OPTIONAL) MUST retain the PDU end
address within the stream for every delivered iSCSI PDU.

Specifically, the two cases in which responses are OPTIONAL are:.

The TARGET RESET function (WARM and COLD) implementation is OPTIONAL and
when implemented, should act as described below.
<br>

-----------------------------------------------------------------------
<br>