Re: UNH Plugfest 5

["Julian Satran" <Julian_Satran@il.ibm.com>]

Bob,



"Robert D. Russell" <rdr@io.iol.unh.edu>
wrote on 14/01/2003 02:56:59:

> Julian:
> 
> The fifth iSCSI plugfest is now underway at UNH with 19 companies
> participating.
> 
> The following needs for clarification have arisen today (Monday,
> 13-Jan-2003):
> 
> 
> 1. Should a logout request with Reason Code 0 "close the session"
>    imply that all SCSI non-persistent reservations be cleared?
>    Section 3.2.7 says: "iSCSI does not require any
persistent
>    state maintenance across sessions",  but this
can be read to
>    imply that clearing persistent state is optional, and
it says
>    nothing about reservations.  For better interoperability,
>    could/should the standard make explicit what state is
required
>    to be cleared and what is not, and how to deal with reservations?
> 

Appendix F has all the clearing effects. We dealt
once more extensively with SCSI clearing
effects but those are now explicitly handled by the
SCSI documents.
> 
> 2. If the initiator offers authentication on the first login request,
>    and the target replies with a redirection, can that redirection
be
>    safely believed by the initiator without first finishing
the
>    authentication?  Probably not, which limits the
value of redirection.
>    Could/should anything be said about this in the standard?
> 
> 
That is an interesting point that was briefly discussed.
It is not sure that a legitimate target
would give out the "secrets" required to
authenticate the redirection nor that the redirector
has to ahve all the authentication implemented. If
the redirection is not legitimate you will
learn about it one step later and you will not be
able to get to the legitimate target anyhow.
However an initiator would be ill advised to change
it's internal tables to point to a new target before validating it.
An initiator is also at liberty to insist on authentication
in which case the redirection will have to provided after authentication.

As we assume that redirection will be provided by
"administrative entities" we did not feel that we have to be
more explicit in the standard and we could leave this to implementers/administrators.

> 3. Two points about TargetPortalGroupTag:
> 
>    a. Section 5.3.1 says: During the Login Phase the iSCSI
target MUST
>       return the TargetPortalGroupTag key with the
first Login Response
>       PDU with which it is allowed to do so ...".
 This is independent
>       of any value of the SessionType key offered on
the first Login
>       request, which means that the TargetPortalGroupTag
is also
>       required for discovery sessions.  Is this
what is intended?
>       If so, could/should it should be explicitly stated
as such in
>       the standard?
> 
This was intended. The statement is a blanket statement.
I am not sure that more words help but I will make it:

During the Login Phase the iSCSI target
MUST return the TargetPortalGroupTag key with the first Login Response
PDU with which it is allowed to do so (i.e., the first Login Response issued
after the first Login Request with the C bit set to 0) for all session
types. The TargetPortalGroupTag key value indicates the iSCSI portal group
servicing the Login Request PDU. If the reconfiguration of iSCSI portal
groups is a concern in a given environment, the iSCSI initiator should
use this key to ascertain that it had indeed initiated the Login Phase
with the intended target portal group.


>    b. Section 3.4.1 subsection 3 says: "Portal Groups
are identified
>       within an iSCSI Node by a portal group tag, a
simple unsigned-
>       integer between 1 and 65535 (see Section 12.3
SendTargets)."
>       However, a few drafts back, the TargetPortalGroupTag
was changed
>       to be a <16-bit-binary-value>, so that
0 is now an allowed value.
>       The above quote should be changed to be consistent.
I'll make it "between 0 and 65535"
> 
> Thank you for your consideration.
> 
> Bob Russell
> InterOperability Lab
> University of New Hampshire
> rdr@iol.unh.edu
> 603-862-3774
Thanks for the good work,
Julo