Subject: Re: iscsi: comments to iSCSI rev 6

From: [email-masked]
Date: Wed, 2 May 2001 09:45:31 +0300

Matt,

Comments in text.

I still did not hear any comment from you on the commad codes you where so
concerned about.

Julo

"Matt Wakeley" <[email-masked]> on 01-05-2001 23:46:26

Please respond to Matt Wakeley <[email-masked]>

To:   IPS Reflector <[email-masked]>
cc:
Subject:  Re: iscsi: comments to iSCSI rev 6

[email-masked] wrote:

> +++ residual counts are not necessarily errors. Interpretation is by
target
> and many commands for undefined length transfer end having a residual
> count. The space is available in the header so I see no point in not
> sending the counts. SAM2 is somewhat ambivalent about overflow though.
+++

But residuals are generally not normal behavior right?  So then make them
only
in the response.  That makes just one less option to implement (I don't
care
about if there is space in the header or not, the issue is implementing,
testing and interoperating options).  Status within a data PDU would then
mean
success with a residue of zero.  Anything else is reported in a response
PDU.

+++ On the contrary for some devices  residual counts are normal and
frequent. Reading from a tape with a variable length block will usually
result in an underrun. Besides - except for the mapping the path for
handling is the same as for a separate response so that I have a hard time
understanding the implementation argument.
++++

> Section 2.8.3: Keys not understood by the target should be expicitely
> indicated as not being understood.  Silence is not a good way to indicate
> that one does not understand something.
>
> +++ as for keys not understood the intent is to have new or vendor
specific
> keys not interfering with the old or standrd only implementations  +++

+++ yet another way for a DOS attack - but I will change it. The text will
read now:

Any other key not understood by the target may be ignored by the target
without affecting basic function. However the Text Response for a key that
was not understood MUST be key=NotUnderstood.

   If the Text Response does not contain the key requested, the initiator
   must assume, whenever appropriate, that the response was "none".

How will returning "key=*not understood*" going to interfer with anything?
It's much better than silence.

> Section 2.12.3: indicate that the LUN is copied from the NOP-IN.  This is
> much more clear than "the correct value for the task".
>
> +++ and open it up to strange thing like LU5 asking a nop-out to LU7 ?
+++

How will that occur?  The target sent the NOP-IN ping request.  The target
includes a LUN.  The only "correct value" that the initiator can return for
the LUN in the NOP-OUT ping response is the value the target sent in the
original request.

+++ OK +++

> Section 2.14: Why is there no CmdSN for the logout command?  Also, 2 ways
> of performing the same operation (cleaning up) are stated in the 3rd
> paragraph.
> In the interest of reducing "options", I suggest that one be picked as
the
> only method.
> +++ silly mistake - i've fixed it +++

I assume you're talking about the missing CmdSN.  You didn't address the
issue
of eliminating one of the two ways of cleaning up.

+++ That seems to be an endless discussion. Whever I take it out there is
somebody that asks for the colapse. The only good argument for the colapse
is single connection targets that whithout this option in login will reject
the second login +++

> Section 2.17.4: "The target assigns" should be "The target may assign".
> +++ ??? it always put something there +++

Yes, it must always put something there.  But "assign" means it picks a
unique
value and is actively using it.  Unassigned means that it is not used, and
the
unassigned value of 0xffffffff is used.

+++ my english dictionary - Webster - shows no such connotation +++

> Appendix: "Initial Marker-less Interval" - I say again, there should not
be
> a "minimum markerless interval".  This should be whatever is negotiated.
> +++ The negotiation itself can't proceed if there are markers that nobody
> knows how to take out +++

Julian, you just keep missing my point.  There are no markers until after
login negotiation.  Part of the negotiation is to say where the first
marker
will be.  If I only use 100 bytes to log in, and I want markers every 1024
bytes, I should not have to wait 3900 bytes to get to the first one just
because the spec arbitrarily picked 4K as the minimum amount of markerless
space.

+++ OK and analyzers will take care of themselves

The new part will read:

01   Initial Marker-less Interval

   To enable the connection setup including the login phase negotiation,
   marking (if any) is started only at the first marker interval after the
   end of the login phase.

-Matt Wakeley
Agilent Technologies

---

From: Steve Senum <[email-masked]>
Date: Wed, 02 May 2001 10:09:34 -0500

I would prefer the text stay as is,
that the target not send any response
for an unknown key.  I see no value
at all in sending key=NotUnderstood.
Lack of a response tells me that already.

Steve Senum

---

From: "Matt Wakeley" <[email-masked]>
Date: Wed, 02 May 2001 15:44:01 -0700

> Lack of a response tells me that already.

No it doesn't.  You can't tell the difference between "not understood" and
"none", since "none" is allowed not to respond also.

I don't like that either.  If the response is "none", say so, don't just sit
there silently.

-Matt

---

From: Steve Senum <[email-masked]>
Date: Thu, 03 May 2001 09:50:47 -0500

Matt,

Okay, but I still don't see the need.

If one side initiates sending a key to the other side,
I might expect the following responses under
the current draft 6:

1. key returned with an option other other than 'none'.

2a. key not returned.
2b. key returned with option 'none'.

And you would add:

2c. key returned with option 'NotUnderstood'.

To me, responses 2a, 2b, and 2c all mean the same,
in as far as the side to initiate sending the key must
make do without that key.  From a negotiation point,
I don't see the value add in response 2c, or for that
matter, response 2b.

---

From: "Matt Wakeley" <[email-masked]>
Date: Fri, 04 May 2001 11:24:46 -0700

> I don't see the value add in response 2c, or for that

The result may mean the same, but for diagnostic purposes, the only thing you
know is you can't do it.  You don't know why.  If you know why, then perhaps
you can take corrective action to remedy the problem.

-Matt

---

From: Steve Senum <[email-masked]>
Date: Fri, 04 May 2001 14:43:52 -0500

Matt,

> you can take corrective action to remedy the problem.

To help with this issue, I would prefer key=none be required
to sent, if applicable. That would leave a non response to
mean only not supported.

Steve Senum

---

From: Stephen Bailey <[email-masked]>
Date: Mon, 07 May 2001 09:00:22 -0400

All,

I agree with Matt.

Every text key in the iSCSI specification should have a precisely
specified response to indicate that it was received and understood.
This does not include X-* keys, for which you're on your own.

A property which I think Matt has articulated, but I want to repeat,
is that an implementation should be able to sanity-check all
negotiation interactions as well as simply communicating the relevant
information.  Specifically, if a negotiation `fails', an
implementation must distinguish between incompatible capabilities and
logical errors whenever possible.

For example if a target sends an AccessID=xxx, the present
specification seems to suggest that there is no response required or
allowed for that key.  I believe we should specify that some response
(perhaps echoing it?) to distinguish between the cases where the
AccessID had the desired effect, and where it had no effect at all
(was ignored).

Explicitly specifying responses for each key allows a more `anal'
implementation to sanity check a more lax one.  We all know we'll
certainly see both implementation styles regardless of what's
specified.

Steph