|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] iSCSI: Use of Reject as a key valueJulian: Attached are 2 ascii text files. The first, reject_extracts.txt, contains all the pieces of draft 14 (the latest available txt version of the drafts) that say anything about the use of Reject as a key value. (At least all those I could find using simple search -- unfortunately, Reject is also the name of a PDU and hence it is not a simple mechanical process to distinguish the two uses! If I missed some, please let me know.) The second, reject_comments.txt, are my comments on these excerpts from the standard. It seems to me that the key thing missing in the standard is a general statement about "what to do next" if a key=Reject response is received. Except for the OFMarkInt and IFMarkInt keys, I could find no other statement about how to proceed after receiving the key=Reject response. In looking through the e-mails posted to the list for June and July, I also could find nothing, although many people seem to be taking the third of the 3 interpretations I listed in reject_comments.txt. I am requesting a clear statement somewhere in the standard that says "what to do next" upon receiving a key=Reject response. Thank you for your consideration. Bob Russell InterOperability Lab University of New Hampshire rdr@iol.unh.edu 603-862-3774
All references in draft 14 to use of "Reject" as a key value.
-------------------------------------------------------------
...
4.2 Text Mode Negotiation
...
The general format of text negotiation is:
Originator-> <key>=<valuex>
Responder-> <key>=<valuey>|NotUnderstood|Irrelevant|Reject
The originator or declarer can either be the initiator or the target
and the responder can either be the target or initiator, respec-
tively. Targets are not limited to respond to key=value pairs as
offered by the initiator. The target may offer key=value pairs of its
own.
All negotiations are explicit (i.e., the result MUST be based only on
newly exchanged or declared values). There are no implicit offers. If
an explicit offer is not made then a reply cannot be expected. Con-
servative design requires also that default values should not be
relied upon when use of some other value has serious consequences.
The value offered or declared can be a numerical-value, a numerical-
range defined by lower and upper value - both integers separated by
tilde, a binary value, a text-value, a iSCSI-name-value, an iSCSI-
local-name-value, a boolean-value (Yes or No), or a list of comma
separated text-values. A range or a large-numerical-value MAY ONLY be
offered if it is explicitly allowed for a key. An iSCSI-name-value
and an iSCSI-local-name-value can be used only where explicitly
allowed. A selected value can be an numerical-value, a large-numeri-
cal-value, a text-value or a boolean-value.
If a specific key is not relevant for the current negotiation, the
responder may answer with the constant "Irrelevant" for all types of
negotiation. However the negotiation is not considered as failed if
the response is "Irrelevant".
Any key not understood by the responder may be ignored by the
responder without affecting the basic function. However, the Text
Response for a key not understood MUST be key=NotUnderstood.
The constants "None", "Reject", "Irrelevant", and "NotUnderstood" are
reserved and must only be used as described here.
Reject or Irrelevant are legitimate negotiation options where allowed
but their excessive use is discouraged. A negotiation is considered
complete when the responder has sent the key value pair even if the
value is "Reject", "Irrelevant", or "NotUnderstood. Sending the key
again would be a re-negotiation
Some basic key=value pairs are described in Chapter 11. 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 NotUnder-
stood.
...
4.2.1 List negotiations
In list negotiation, the originator sends a list of values (which may
include "None") in its order of preference.
The responding party MUST respond with the same key and the first
value that it supports (and is allowed to use for the specific origi-
nator) selected from the originator list.
The constant "None" MUST always be used to indicate a missing func-
tion. However, None is a valid selection only if it is explicitly
offered.
If a responder does not understand any particular value in a list it
MUST ignore it. If a responder does support, understand or is allowed
to use none of the offered options with a specific originator, it may
use the constant "Reject" or terminate the negotiation. The selec-
tion of a value not offered is considered a negotiation failure and
is handled as a protocol error.
4.2.2 Simple-value negotiations
For simple-value negotiations, the responding party MUST respond with
the same key. The value it selects, based on the selection rule spe-
cific to the key, becomes the negotiation result. For a numerical
range the value selected must be an integer within the offered range
or "Reject" (if the range is unacceptable). 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 selection, by the responder, of a value not admissible
under the selection rules is considered a negotiation failure and is
handled accordingly. The selection rules are key-specific.
...
4.3 Login Phase
...
Neither the initiator nor the target should attempt to declare or
negotiate a parameter more than once during login except for
responses to specific keys that explicitly allow repeated key decla-
rations (e.g. TargetAddress). If detected by the target this MUST
result in a Login reject (initiator error). The initiator MUST drop
the connection
...
4.3.2 iSCSI Security Negotiation
The security exchange sets the security mechanism and authenticates
the initiator user and the target to each other. The exchange pro-
ceeds according to the authentication method chosen in the negotia-
tion phase and is conducted using the login requests' and responses'
key=value parameters.
An initiator directed negotiation proceeds as follows:
-The initiator sends a login request with an ordered list of
the options it supports (authentication algorithm). The
options are listed in the initiator's order of preference.
The initiator MAY also send proprietary options.
-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 parameters are encoded in UTF8 as key=value. For secu-
rity parameters, see Chapter 10.
...
A.3.2 OFMarkInt, IFMarkInt
Use: IO
Senders: Initiator and Target
Scope: CO
Offering:
OFMarkInt=<numeric-range-from-1-to-65535>
IFMarkInt=<numeric-range-from-1-to-65535>
Responding:
OFMarkInt=<numeric-value-from-1-to-65535>|Reject
IFMarkInt=<numeric-value-from-1-to-65535>|Reject
OFMarkInt is used to set the interval for the initiator to target
markers on the connection. IFMarkInt is used to set the interval for
the target to initiator markers on the connection.
For the offering the initiator or target indicates the minimum to
maximum interval (in 4-byte words) it wants the markers for one or
both directions. In case it only wants a specific value, only a sin-
gle value has to be specified. The responder selects a value within
the minimum and maximum offered or the only value offered or indi-
cates through the xFMarker key=value its inability to set and/or
receive markers. When the interval is unacceptable the responder
answers with "Reject". Reject is resetting the marker function in
the specified direction (Output or Input) to No.
...
Comments on the use of "Reject" as a key value.
In section 4.2, the "general format of text negotiation" clearly allows
both initiator and target to send and receive a "Reject" value.
However, this "general format" does not necessarily imply that it is
legal to send a "Reject" value at any time and for any key!
Later in the same section 4.2 it says:
"Reject or Irrelevant are legitimate negotiation options where
allowed but ...".
This could be read to imply that further explanations must be given to
indicate where Reject (Irrelevant) is allowed. In fact, the standard
explicitly lists the following specific situations where Reject is allowed.
1. In section 4.2.1, List negotiations, it says:
"If a responder does support, understand or is allowed to use
none of the offered options with a specific originator, it may
use the constant "Reject" or terminate the negotiation."
--This could be understood to mean that "Reject" does NOT terminate
the negotiation. However, the next sentence in the standard says:
"The selection of a value not offered is considered a negotiation
failure and is handled as a protocol error."
--Clearly "Reject" was not offered, so if it appears in the
response, this sentence could be understood to mean that the
negotiation failed.
2. In section 4.2.2, Simple-value negotiations, it says:
"For a numerical range the value selected must be an integer
withing the offered range or "Reject" (if the range is
unacceptable)."
--This explicitly allows Reject as a response for numerical range
parameters (of which there are only two: OFMarkInt and IFMarkInt),
but doesn't say what to do next if Reject is used. However,
section A.3.2 does say what to do for the OFMarkInt and IFMarkInt
keys (see below).
3. Also in section 4.2.2, Simple-value negotiations, it says:
"An offer of a value not admissible (e.e., not within the specified
bounds) MAY be answered with the constant "Reject" or the responder
MAY select an admissible value."
--This explicitly allows Reject as a response for other simple-value
types (keys expecting numerical values, boolean values, etc.),
but again doesn't say what to do next if Reject is used.
4. In section 4.3.2, iSCSI Security Negotiation, it says:
"-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)."
--Ok, but then what happens next -- has the negotiation failed?
If not, what value is used for the rejected key -- the value
in effect prior to this offer/response exchange? The standard
never says.
5. In section A.3.2, OFMarkInt, IFMarkInt, it says:
"Responding:
OFMarkInt=<numeric-range-from-1-to-65535>|Reject
IFMarkInt=<numeric-range-from-1-to-65535>|Reject"
--This is the only instance where Reject is explicitly specified
as a valid response for a specific key.
6. Also in section A.3.2, OFMarkInt, IFMarkInt, it says:
"When the interval is unacceptable the responder answers with
"Reject". Reject is resetting the marker function in the
specified direction (Output or Input) to No."
--This is also the only instance where the standard says what to
do when a response value of Reject is used.
I believe the source of much confusion is that, except for point 6 above,
the standard never says what is supposed to happen next when a response
value of Reject is used!
There are at least the following three interpretations:
1. Both sides use the value of the key in effect before the offer
and continue with negotiations as if nothing had happened,
although this particular key cannot be offered again in this
negotiation sequence (that is explicit).
2. Treat the negotiation as a failure and take appropriate action.
During login, appropriate action is to close the connection.
During text negotiation during FFP, appropriate action is
to ignore all the negotiations in this sequence of text request
text response exchanges.
3. If possible, use the value of the key in effect before the
offer (and continue as in point 1). If not possible, treat
the negotiation as a failure (and take appropriate action,
as in point 2).
Perhaps this vagueness is intentional, and all interpretations are
allowed. However, I believe it would remove a lot of confusion
if the standard said something about what to do next!
Comments?
Home Last updated: Tue Jul 30 10:39:11 2002 11481 messages in chronological order |