Subject: iSCSI: Negotiating a parameter more than once

From: [email-masked]
Date: Mon, 17 Jun 2002 16:18:43 -0600

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

---

From: "THALER,PAT (A-Roseville,ex1)" <[email-masked]>
Date: Mon, 17 Jun 2002 17:05:18 -0600

Julian,

It also isn't clear whether SendTargets can be sent more than once during a negotiation sequence.

It would be reasonable for the Initiator to set the F bit when it sends SendTargets and then when the Target sets the F bit the initiator will know that the response is complete. However if SendTargets isn't covered by the limitation on negotiating a parameter only once per negotiation sequence, an initiator could also leave the F bit at zero, assume the response is done when it gets a response with an empty text field, and send SendTargets again later in the same negotiation sequence. An initiatior could even send a single PDU with something like: SendTargets=<iSCSI-target-name-A>; SendTargets=<iSCSI-target-name-B>; SendTargets=<iSCSI-target-name-C>. 

There doesn't seem to be anything in Appendix D to say which of these is intended. The first possibility - allowing SendTargets to be sent only once during a negotiation sequence - seems adequate and simpler.

Pat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Monday, June 17, 2002 3:19 PM
To: [email-masked]
Cc: [email-masked]
Subject: iSCSI: Negotiating a parameter more than once

Julian,

Regards,
Pat

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Mon, 17 Jun 2002 19:56:03 -0400

The section you reference is titled "Login Phase" - SendTarget's isn't valid
during the login phase, and it's not a negotiation.  It's a
request/declaration, and its only valid during FFP.  Sorry, I don't see a
problem with the text you quoted.

Marjorie

> From: THALER,PAT (A-Roseville,ex1) [mailto:[email-masked]]
> Sent: Monday, June 17, 2002 4:05 PM
> Subject: RE: iSCSI: Negotiating a parameter more than once
> 
> 
> Julian,
> 
> It would be reasonable for the Initiator to set the F bit 
> when it sends SendTargets and then when the Target sets the F 
> bit the initiator will know that the response is complete. 
> However if SendTargets isn't covered by the limitation on 
> negotiating a parameter only once per negotiation sequence, 
> an initiator could also leave the F bit at zero, assume the 
> response is done when it gets a response with an empty text 
> field, and send SendTargets again later in the same 
> negotiation sequence. An initiatior could even send a single 
> PDU with something like: SendTargets=<iSCSI-target-name-A>; 
> SendTargets=<iSCSI-target-name-B>; SendTargets=<iSCSI-target-name-C>. 
> 
> There doesn't seem to be anything in Appendix D to say which 
> of these is intended. The first possibility - allowing 
> SendTargets to be sent only once during a negotiation 
> sequence - seems adequate and simpler.
> 
> Pat
> 
> 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. 
>

---

From: [email-masked]
Date: Mon, 17 Jun 2002 18:26:37 -0600

I referenced two sections - 4.3 and 4.4. I agree that 4.3 isn't relevant to SendTargets, but the similar text in 4.4 is.

Pat

-----Original Message-----
From: KRUEGER,MARJORIE (HP-Roseville,ex1)
[mailto:[email-masked]]
Sent: Monday, June 17, 2002 4:56 PM
To: 'THALER,PAT (A-Roseville,ex1)'
Cc: [email-masked]
Subject: RE: iSCSI: Negotiating a parameter more than once

Marjorie

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Mon, 17 Jun 2002 17:39:18 -0700

Seems to me that the text in 4.4 should be deleted, since even reworded, its
only confusing here.  Currently, there's no "negotiation" that's valid in
FFP - SendTargets and MaxPDUDataLength are declarative. 

> Sent: Monday, June 17, 2002 5:27 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> I referenced two sections - 4.3 and 4.4. I agree that 4.3 
> isn't relevant to SendTargets, but the similar text in 4.4 is.
> 
> Pat
>

---

From: "Julo-Actcom" <[email-masked]>
Date: Wed, 19 Jun 2002 08:12:09 +0300

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

--------------------------------------------------------------------------------
 
  a.. To: [email-masked] 
  b.. Subject: iSCSI: Negotiating a parameter more than once 
  c.. From: [email-masked] 
  d.. Date: Mon, 17 Jun 2002 16:18:43 -0600 
  e.. Cc: [email-masked] 
  f.. Content-Type: text/plain;charset="ISO-8859-1" 
  g.. Sender: [email-masked] 

--------------------------------------------------------------------------------

Julian,

Regards,
Pat

--------------------------------------------------------------------------------

  a.. Prev by Date: RE: iSCSI: use of Text/Login with no data segment 
  b.. Next by Date: RE: iSCSI: Negotiating a parameter more than once 
  c.. Prev by thread: iSCSI 0.13 vs. iSCSI Plugfest 
  d.. Next by thread: RE: iSCSI: Negotiating a parameter more than once 
  e.. Index(es): 
    a.. Date 
    b.. Thread

---

From: "THALER,PAT (A-Roseville,ex1)" <[email-masked]>
Date: Wed, 19 Jun 2002 11:18:44 -0600

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,

 

and in 4.4:

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,

drop the connection.

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: "Julian Satran" <[email-masked]>
Date: Wed, 19 Jun 2002 21:59:40 +0300

OK Julo

"THALER,PAT (A-Roseville,ex1)" <[email-masked]>
Sent by: [email-masked]
06/19/2002 08:18 PM
Please respond to "THALER,PAT (A-Roseville,ex1)"

        To:     Julo-Actcom <[email-masked]>, [email-masked]
        cc: 
        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,

I think that you refer to the responses to SendTargets - those contain 
more than an instance of the declarations and have to outlined.

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] 
Subject: iSCSI: Negotiating a parameter more than once 
From: [email-masked] 
Date: Mon, 17 Jun 2002 16:18:43 -0600 
Cc: [email-masked] 
Content-Type: text/plain;charset="ISO-8859-1" 
Sender: [email-masked] 

Julian,

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. 

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: use of Text/Login with no data segment 
Next by Date: RE: iSCSI: Negotiating a parameter more than once 
Prev by thread: iSCSI 0.13 vs. iSCSI Plugfest 
Next by thread: RE: iSCSI: Negotiating a parameter more than once 
Index(es): 
Date 
Thread

---

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

Sorry Pat, I read your response too quickly and misinterpreted the
definition of "negotiation sequence".  I agree with you, the text you
suggest is appropriate.
 
In addition, it would be nice if section 11 had an explicit "Use" indication
distinguishing keys that can be repeated w/in a declaration sequence
(targetAddress, targetAlias, targetName) and keys that cannot be repeated.
 
You mentioned that you couldn' t find text that says the SendTargets command
can be repeated w/in a declaration sequence - in fact, Appendix D paragraph
6 says:
     
     "A SendTargets command consists of a single Text request PDU.
     This PDU contains exactly one text key and value.  The text key MUST 
     be SendTargets.  The expected response depends upon the value, as 
     well as whether the session is a discovery or operational session."
 
This seems OK to me, if an initiator wants information about another target,
it can just initiate another SendTargets "negotiation sequence"??
 
Marj

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

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,
 
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,

I think that you refer to the responses to SendTargets - those contain more
than an instance of the declarations and have to outlined.

	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

---

From: "Julian Satran" <[email-masked]>
Date: Thu, 20 Jun 2002 09:58:19 +0300

Marjorie,

We discussed this repeatedly in the past and I recall that except the 
dissenting voice of Mark Bakke the agreement was that long-lived discovery 
sessions are not considered useful.

Julo

"KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Sent by: [email-masked]
06/19/2002 09:31 PM
Please respond to "KRUEGER,MARJORIE (HP-Roseville,ex1)"

        To:     "'THALER,PAT (A-Roseville,ex1)'" <[email-masked]>, Julo-Actcom 
<[email-masked]>, [email-masked]
        cc: 
        Subject:        RE: iSCSI: Negotiating a parameter more than once

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.

Marjorie Krueger
 
-----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,

Therefore, I suggest:
For 4.3:
 
For 4.4:
 
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,

 

and in 4.4:

Julian,

Regards,
Pat

---

From: "THALER,PAT (A-Roseville,ex1)" <[email-masked]>
Date: Thu, 20 Jun 2002 12:19:19 -0600

Julian,
 
Whether the discovery session is long lived or not isn't really relevant to whether SendTargets can be offerred more than once per a negotiation _sequence_ since there can be multiple negotiation sequences during a discovery session. Keeping a discovery session open and sending SendTargets multiple times in a discovery session is specifically allowed (Appendix D page 249 just before the examples). The draft is silent on whether that is allowed within the same negotiation sequence.
 
IMO, since it is simple for the initiator to start a new negotiation sequence by sending a Text Request after the last sequence finishes, there isn't any reason to complicate things by allowing multiple SendTargets within a sequence.
 
Regards,
Pat
 
-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Wednesday, June 19, 2002 11:58 PM
To: KRUEGER,MARJORIE (HP-Roseville,ex1)
Cc: [email-masked]; Julo-Actcom; [email-masked]; 'THALER,PAT (A-Roseville,ex1)'
Subject: RE: iSCSI: Negotiating a parameter more than once

Marjorie, 

We discussed this repeatedly in the past and I recall that except the dissenting voice of Mark Bakke the agreement was that long-lived discovery sessions are not considered useful. 

Julo 

06/19/2002 09:31 PM 

        To:        "'THALER,PAT (A-Roseville,ex1)'" <[email-masked]>, Julo-Actcom <[email-masked]>, [email-masked] 
        cc:         
        Subject:        RE: iSCSI: Negotiating a parameter more than once 

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

-----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, 

Therefore, I suggest: 
For 4.3: 
  
For 4.4:
  
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, 

  

and in 4.4: 

Julo 

  _____  

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

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

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

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

  _____  

	Julian,

Regards,
Pat

  _____  

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

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

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

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

*	Index(es): 

*	

*