Progress report from the ISCSI Group Test Period - Login is ugly

["Barry Reinhold" <bbrtrebia@mediaone.net>]

Three rounds of interoperability testing have been completed and the group
of 30 companies is now in a debugging mode. The main problem points came up
quickly and they are: login, login, and login.

A short summary of the issues follows, detailed descriptions will be posted
for list review:

1. CmdSN - If a login PDU is sent with CMDSN=5 and the next command is in
the full feature phase is the CmdSN of that PDU 5 or 6? For the current test
period we have chosen to use simply increment CmdSN. (we will send 6)

2. InitStatSN - This is essentially the same issue as CmdSN, however there
is complexity with the multiple StatSNs that can come back as a result of
the partial login response. The plan for the current test period is to treat
this differently then CmdSN and use the value given in InitStatSN. This is
in no way a reflection of what the implementers desired in future revs. of
the specification.

3. There was mixed implementations in terms of the usage of the F bit in
Command frames. Some following wording in rev 6 and some following wording
in 6-96.

4. There was a lack of consistency in understanding what a "list" was.
Key=value pairs such as InitialR2T = no were in some cases interpreted as
list items and in some cases as something else ("binary options"). If the
item was viewed as a list, then the expected form was initialR2T=no,yes. The
implied meaning being that the device wanted to send initial data without an
R2T, but supported the use of R2Ts. A device that sent initialR2T=no was
understood to be saying "I will only work with devices that can accept
initial write data w/o an R2T." In this view that default value only implies
what is used if the key is missing from the negotiation.
The other (major) view was that there are more things then lists and numeric
keys. In this case the initialr2t=no is not a list and does not need to have
all supported options with it.

5. Dependent keys - If a device does not like the value for a dependent
parameter, such as IFMarkInt, that depends on FMarker, how is this handled?

6. What is the proper way for a target to force security negotiation when
the initiator moves directly to operation phase? Does it reject the login
and terminate the connection? or does it send Security parameters back
anyways?

7. A number of vendors were not expecting the target to be able to initiate
new key=value pairs.

8. During the security phase of login operational parameters may be ignored.
There were different views as to what this implied (not sending the
key=value pairs back, sending the values back but ignoring them once
operation negotiation phase was entered.

9. The standard requires that key=value entries be "separated" by nulls.
This means that the last one does not have to have a null. There was
universal desire for all key=values to be terminated by a null.

10. Is the setting of F=1 persistent? If the initiator sends F=1 and the
target comes back with new parameters is the initiator allowed to withdraw
the F=1 setting in the next PDU it send.

The large number of views on what the draft says relative to login suggest
that we need to have more precise login behavior documentation. In
particular a state table with well defined actions for the transitions
between states should be specifies. The current draft 6-96 has a table, but
lacks transition actions. The key=value negotiation process such employ a
formal grammar the applied a well defined meaning to each of the identifiers
and fixed the syntactical expressions.

Barry Reinhold
Principal Architect
Trebia Networks
barry.reinhold@trebia.com
603-868-5144/603-659-0885/978-929-0830 x???