|
|
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] |
-------- Original Message -------- Subject: Re: Question regarding SessionType Date: Tue, 29 Nov 2005 16:52:40 +0200 From: Julian Satran <satran@haifasphere.co.il> To: Sears_Bill@emc.com CC: ips@ietf.orgReferences: <05AADEB492F5824996D28D50468673990621AE@CORPUSMX40A.corp.emc.com>
Bill, Unfortunately the text of RFC3720 does not agree with your assumptions.The session type can be specified at any stage as explicitly stated in chapters 11 and 12. I can't think of a good reason we should limit its use (or even recommend it as good practice in the implementor guide).
Julo Sears_Bill@emc.com wrote:
rfc3720 section 5.3 states:The initial login request of the first connection of a session MAY also include the SessionType key=value pair.The use of the word 'MAY' here is bothersome. Does this mean that an initiator may leave out the session type in the first request but then explicitly specify it later? This seems possible but very annoying. For example:During Security stage it seems that an initiator could leave out SessionType but specify a TargetName=<something>. Later during operational stage the initiator could specify SessionType=Discovery. It seems that this is allowed.Currently I am assuming that if the SessionType is not specified in the initial login request of the first connection that the initiator is implicitly negotiating for SessionType=Normal. In this case I wont send SessionType=Normal in a response PDU but I will assume that SessionType has been negotiated to its default value of Normal. I regard seeing SessionType in any subsequent LoginRequest PDU as an error.Bill------------------------------------------------------------------------ _______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips
_______________________________________________ Ips mailing list Ips@ietf.org https://www1.ietf.org/mailman/listinfo/ips
[IETF] [Linux iSCSI] [Linux SCSI] [Linux Resources] [Yosemite News] [IETF Announcements] [IETF Discussion] [SCSI]
![]() |
![]() |