|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: UNH Plugfest 5Bob, "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
Home Last updated: Tue Jan 14 20:18:59 2003 12174 messages in chronological order |