Subject: RE: iSCSI: Negotiating a parameter more than once

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Wed, 19 Jun 2002 14:31:41 -0400

In the context of the two keys that are valid during FFP, neither of these
suggested edits to that paragraph make sense.  Currently, there is no
"negotiation" key that's valid in FFP, and the "declarative" keys that are
valid, - SendTargets and MaxPDUDataLength *can* validly be repeated.  If an
initiator opens a discovery session, it may keep it open, and it may repeat
SendTargets requests as it deems necessary to keep it's target information
up to date.  In the course of a SendTargets response, the target validly
repeats certain keys.  The MaxPDUDataLength key can be sent by the initiator
as often as the PMTU changes.
 
Why not just delete this paragraph?  In the future if there are keys added
that are valid during FFP, the RFC that specifies those keys can specify
whether or not they can be "renegotiated".
 
Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard

-----Original Message-----
From: THALER,PAT (A-Roseville,ex1) [mailto:[email-masked]]
Sent: Wednesday, June 19, 2002 10:19 AM
To: Julo-Actcom; [email-masked]
Subject: RE: iSCSI: Negotiating a parameter more than once

Julian,
 
If declarations should not be repeated (except for those where it is
explicitly allowed), then it should be "negotiate or declare" because
"negotiate" doesn't cover declarations. Alternatively, one could add an
explicit definition that "Negotiate" includes both declarations and
negotiations. Secondly, SendTargets is not a valid example for login as it
is FFPO. I think the only parameter explicitly allowed to be duplicated
during Login is TargetAddress (when returned as a result of a redirect).
Furthermore, I can not find any explicit statement that SendTargets may be
repeated during a FFP negotiation sequence. Only TargetName and
TargetAddress have explicit text allowing them to be repeated (in Appendix B
for both and in the description of redirection for LoginResponse for
TargetAddress).
 
Therefore, I suggest:
For 4.3:
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).
If detected by the target this MUST result in a Login reject (initiator
error). The initiator MUST drop the connection
 
For 4.4:
Neither the initiator nor the target should attempt to declare or negotiate
a parameter more than once during any negotiation sequence without an
intervening reset except for responses to specific keys that explicitly
allow repeated key declarations (e.g. TargetAddress). If detected by the
target this MUST result in a Reject with a reason of "protocol error". The
initiator MUST reset the negotiation as outlined above.
 
Pat
-----Original Message-----
From: Julo-Actcom [mailto:[email-masked]]
Sent: Tuesday, June 18, 2002 10:12 PM
To: [email-masked]
Subject: RE: iSCSI: Negotiating a parameter more than once

Pat,
 
4.3 and 4.4 cover two diferent phases.
Parameters should not be negotiated or declared twice.
 
I think that you refer to the responses to SendTargets - those contain more
than an instance of the declarations and have to outlined.
 
How about the following text in 4.4:

	Neither the initiator nor the target should attempt to negotiate a
parameter more than once during login except for responses to specific keys
that explicitly allow repeated key declarations (e.g. SendTargets). If
detected by the target this MUST result in a Login reject (initiator error).
The initiator MUST drop the connection.

and in 4.4:

	Neither the initiator nor the target should attempt to negotiate a
parameter more than once during any negotiation sequence without an
intervening reset except for responses to specific keys that explicitly
allow repeated key declarations. If detected by the target this MUST result
in a Reject with a reason of "protocol error". The initiator MUST reset the
negotiation as outlined above.

Julo
  _____  

*	To: [email-masked] <mailto:[email-masked]>  

*	Subject: iSCSI: Negotiating a parameter more than once 

*	From: [email-masked] <mailto:[email-masked]>  

*	Date: Mon, 17 Jun 2002 16:18:43 -0600 

*	Cc: [email-masked] <mailto:[email-masked]>  

*	Content-Type: text/plain;charset="ISO-8859-1" 

*	Sender: [email-masked] <mailto:[email-masked]>  

  _____  

Julian,

The following text appears in 4.3 (page 78 just before 4.3.1):

Neither the initiator nor the target should attempt to negotiate a

parameter more than once during login. If detected by the target this

MUST result in a Login reject (initiator error). The initiator MUST

drop the connection.

and nearly the same text in 4.4 (page 85 near the end):

Neither the initiator nor the target should attempt to negotiate a

parameter more than once during any negotiation sequence without an

intervening reset. If detected by the target this MUST result in a

Reject with a reason of "protocol error". The initiator MUST reset

the negotiation as outlined above.

This is confusing partly because "negotiate" seems to be generally used
covering both negotiations and declarations and in some cases covering only
negotiations. It isn't clear in which sense it is used. If the text above
applies only to negotiated values, then it would be allowable to send
parameters such as Initiator Name, SessionType, and MaxRecvDataSegmentLength
over which doesn't seem to be a good idea. However, there are other
declarative parameters which are sent multiple times - SendTargets where
there are multiple targets or multiple addresses for a target requires
sending the same parameter multiple times. 

Perhaps the text should be changed to:

Neither the initiator nor the target should attempt to declare or negotiate
a

parameter other than TargetName, TargetAlias or TargetAddress more than
once....

Regards,

Pat
  _____  

*	Prev by Date: RE: iSCSI:
<http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10861.html> use of
Text/Login with no data segment 

*	Next by Date: RE: iSCSI:
<http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10863.html> Negotiating a
parameter more than once 

*	Prev by thread: iSCSI 0.13
<http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10858.html> vs. iSCSI
Plugfest 

*	Next by thread: RE: iSCSI:
<http://www.pdl.cmu.edu/mailinglists/ips/mail/msg10863.html> Negotiating a
parameter more than once 

*	Index(es): 

*	 <http://www.pdl.cmu.edu/mailinglists/ips/mail/maillist.html#10862>
Date 

*	 <http://www.pdl.cmu.edu/mailinglists/ips/mail/thrd109.html#10862>
Thread

---

From: Martins Krikis <[email-masked]>
Date: Wed, 19 Jun 2002 13:29:01 -0700 (PDT)

> as often as the PMTU changes.

I don't see why the repetition of SendTargets and
MaxRecvDataSegmentLength must happen in the same
"negotiation sequence". If a node wants to repeat
them, it can easily cause it to happen in a new
sequence. Thus, I think that the paragraphs in
question do make sense and that only the keys sent
in response to SendTargets should be allowed to be
repeated.

> whether or not they can be "renegotiated".

The paragraphs are needed because they are the only
rules disallowing renegotiation and redeclaration
(in the same negotiation sequence). 

As to the future keys, I'd like them too to be
non-renegotiable. 

Martins Krikis, Intel Corp.

Disclaimer: these are my opinions and may
            not be those of my employer.

__________________________________________________
Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup
http://fifaworldcup.yahoo.com