Hi Santosh, On Thu, 2014-06-12 at 14:46 +0530, Santosh Kulkarni wrote: > Hi Nab, > > Had a query regarding LIO implementation for key value > re-negotiation/declaration in Multiple Connections. > In Multiple Connections, when a session wide key value pair > (InitialR2t,ImmediateData etc) is negotiated in a leading connection , > cannot be renegotiated/declared again in a subsequent connection within > the session. > And further the target should go ahead and must send Login Reject PDU > back to the initiator. > > But what i see is LIO sends a "not understood" value and goes ahead with > the login process and there is no Login Reject PDU sent out. > > But RFC states the following. > > > Quoting section > > 5.3. Login Phase > > "Neither the initiator nor the target should attempt to declare or > negotiate a parameter more than once during login except for > responses to specific keys that explicitly allow repeated key > declarations (e.g., TargetAddress). An attempt to > renegotiate/redeclare parameters not specifically allowed MUST be > detected by the initiator and target. If such an attempt is detected > by the target, the target MUST respond with Login reject (initiator > error); if detected by the initiator, the initiator MUST drop the > connection" > > Do share your thoughts on this. > So I think the above is intended to mean that any attempt to renegotiate/redeclare parameters within a single login attempt must result in a Login reject response. Since login attempts for a leading connection and subsequent non-leading connection are logically different login attempts on different TCP connections, I don't think the wording in Section 5.3 applies to the MC/S case your highlighting. Looking through the spec, I can't find anything about this specific case. From section 5.2, the 'Irrelevant' and 'Reject' key response don't fit this particular case. The closest thing wrt to NotUnderstood usage being the correct response for this case is: "Any key not understood by the acceptor may be ignored by the acceptor without affecting the basic function. However, the answer for a key not understood MUST be key=NotUnderstood." and: "All keys in this document, except for the X extension formats, MUST be supported by iSCSI initiators and targets when used as specified here. If used as specified, these keys MUST NOT be answered with NotUnderstood." The logical inverse of the latter wording can be interpreted as: 'If not used as specified, these keys may be answered with NotUnderstood.' So that said, I think a NotUnderstood response is acceptable for this case. --nab -- To unsubscribe from this list: send the line "unsubscribe target-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
