Subject: RE: iSCSI: key negotiation - Unrecognized value?

From: Eddy Quicksall <[email-masked]>
Date: Wed, 20 Feb 2002 09:38:46 -0500

Marjorie,

Thanks for bringing this up again. I asked it once under "Re: iSCSI: invalid
key value" but unfortunately I asked it in a "list context". As I remember,
I got about 3 different opinions. Hopefully, we can get an answer this time.

IMHO, I think we should allow "reject" to be used (but now it is for list
items only). I know that some people are using "reject".

Eddy

-----Original Message-----
From: KRUEGER,MARJORIE (HP-Roseville,ex1) [mailto:[email-masked]]
Sent: Tuesday, February 19, 2002 8:23 PM
To: Ips Reflector (E-mail)
Subject: iSCSI: key negotiation - Unrecognized value?

What is the proper response if you recognize a key, but are offered a value
that you don't recognize?  For instance, what if MaxConnections=yes is
offered?

Where is that specified in the document? 

Marjorie Krueger
Networked Storage Architecture
Networked Storage Solutions Org.
Hewlett-Packard
tel: +1 916 785 2656
fax: +1 916 785 0391
email: [email-masked]

---

From: "LEMAY,KEVIN (A-Roseville,ex1)" <[email-masked]>
Date: Wed, 20 Feb 2002 13:32:47 -0700

My impression was that "notUnderstood" was used if the key name itself could
not be decoded.

I believe that the correct behavior in the specific case should be:

Originator-> MaxConnections=yes
Responder->  MaxConnections=reject (with a login response of "Initiator
error")

The reason being, is that this key is clearly defined as a numeric field
with specific ranges of values. To send a non-numeric value for this key
would be an initiator error and should be treated as such.

Although processing as "notunderstood" may allow the login to continue, it
will also "cover up" the error allowing bad code to continue live on. Do we
really want to make it easy for people to not even follow the spec?

Kevin Lemay 

-----Original Message-----
From: Luben Tuikov [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 12:17 PM
To: KRUEGER,MARJORIE (HP-Roseville,ex1)
Cc: Ips Reflector (E-mail); Julian Satran
Subject: Re: iSCSI: key negotiation - Unrecognized value?

Marjorie, Julian, all,

When a value doesn't belong to the valid set of
assignable values to a key, but is offered, 
as Marjorie's example, shouldn't the following
take place:

Originator-> MaxConnections=yes
Responder->  MaxConnections=NotUnderstood

Also, isn't ``Reject'' used for a valid, assignable
value, but for which the responder has no resources:

Originator-> MaxConnections=4294967296
Responder->  MaxConnections=Reject

I.e. the responder cannot allow 2^32 connections,
since the OS will not allow it in the first place...
(If your OS allows it, replace the number with 1e3000
above ;-)

?

P.S. The ``NotUnderstood'' reply above would also
be semantically correct.

-- 
Luben Tuikov, Senior Software Engineer, Splentec Ltd.
Bus: +1-905-707-1954x112, 9-5 EST. Fax: +1-905-707-1974.

---

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Wed, 20 Feb 2002 13:47:49 -0800

> Responder->  MaxConnections=NotUnderstood

I believe that behavior is in error, as there must be a difference in the
response to an unrecognized key and an unrecognized "key value".
 
> Responder->  MaxConnections=Reject

Not as the spec is currently written.

I believe Robert Russell has recommended the correct solution - the current
draft doesn't specifically address the response when an invalid "key value"
is offered.

Marjorie

---

From: "THALER,PAT (A-Roseville,ex1)" <[email-masked]>
Date: Wed, 20 Feb 2002 16:33:55 -0700

2.2.4 says: "The constants "None", "Reject", "Irrelevant", and
"NotUnderstood" are reserved and must only be used as described here."

NotUnderstood is for a key not understood by the responder. The draft
doesn't say it is used for a value that is not understood.

It currently describes Reject only in the context of list negotiation where
it is used when none of the values in the offered list are acceptable. For
the example Luben gives of a numerical negotiation (MaxConnections), Reject
would never be a valid response. If the originator offers a higher valid
value than the responder is willing to accept, the responder would respond
with the lower number that it is willing to accept. So a valid negotiation
for the case where the originator asks for a valid assignable value than the
responder is willing to support would be something like:

Originator-> MaxConnections=65535
Responder->  MaxConnections=3

In the example Luben gave, 4294967296 is not a valid value for
MaxConnections because it is outside the range <number-from-1-to-65535>. The
draft doesn't say what to do about out of range values and other invalid
values.

The draft does say that "selection of a value not admissible under the
selection rules rules is considered a protocol error and is handled
accordingly." The context for that statement appears to be the selection of
a value offered by the responder, but that action would also make sense for
responding to a value that is invalid for the key (wrong type of value or
out of range). An implementation offering an invalid value is broken which
makes proceeding with the negotiation a problem.

Sending a "Reject" also would be a reasonable response to an invalid value
but it  seems that offering an invalid value is just as severe an error as
the ones that currently are responded to with protocol errors. 

Regards,
Pat

-----Original Message-----
From: LEMAY,KEVIN (A-Roseville,ex1) [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 12:33 PM
To: 'Luben Tuikov'; KRUEGER,MARJORIE (HP-Roseville,ex1)
Cc: Ips Reflector (E-mail); Julian Satran
Subject: RE: iSCSI: key negotiation - Unrecognized value?

Kevin Lemay 

-----Original Message-----
From: Luben Tuikov [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 12:17 PM
To: KRUEGER,MARJORIE (HP-Roseville,ex1)
Cc: Ips Reflector (E-mail); Julian Satran
Subject: Re: iSCSI: key negotiation - Unrecognized value?

Marjorie, Julian, all,

?

---

From: [email-masked]
Date: Wed, 20 Feb 2002 17:50:32 -0700

Thinking about this response further, "protocol error" should be replaced by
"negotiation failure." 2.2.4 says that selection of an inadmissible value
must be considered a protocol error and handled accordingly, but 7.8
Protocol Errors doesn't seem to say anything relevant to this type of error.
Also during login one cannot send a reject PDU with a reason code of
Protocol Error.

7.8 Negotiation Failures does contain relevant actions and should replace
protocol error in 2.2.4.
 
Pat

-----Original Message-----
From: THALER,PAT (A-Roseville,ex1) [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 3:34 PM
To: LEMAY,KEVIN (A-Roseville,ex1); 'Luben Tuikov'; KRUEGER,MARJORIE
(HP-Roseville,ex1)

Regards,
Pat

-----Original Message-----
From: LEMAY,KEVIN (A-Roseville,ex1) [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 12:33 PM
To: 'Luben Tuikov'; KRUEGER,MARJORIE (HP-Roseville,ex1)
Cc: Ips Reflector (E-mail); Julian Satran
Subject: RE: iSCSI: key negotiation - Unrecognized value?

Kevin Lemay 

-----Original Message-----
From: Luben Tuikov [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 12:17 PM
To: KRUEGER,MARJORIE (HP-Roseville,ex1)
Cc: Ips Reflector (E-mail); Julian Satran
Subject: Re: iSCSI: key negotiation - Unrecognized value?

Marjorie, Julian, all,

?

---

From: [email-masked]
Date: Wed, 20 Feb 2002 17:35:42 -0700

Commments in line with my initials: <PAT> 
Pat

-----Original Message-----
From: Luben Tuikov [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 12:21 PM
To: KRUEGER,MARJORIE (HP-Roseville,ex1)
Cc: Ips Reflector (E-mail); Julian Satran
Subject: Re: iSCSI: key negotiation - Unrecognized value?

> Where is that specified in the document?

v10, pg 34, top:

 Any other key not understood by the responder may be ignored
 by the responder without affecting the basic function. However,
 the Text Response for a key not understood MUST be
 key=NotUnderstood.

<PAT> That is for a key that is not understood, not for a value that is not
understood or a value that is invalid.

v10, pg 33, middle:

 If a responder does not support or is not allowed to use
 all of the offered options with a specific originator,
 it may use the constant "Reject".

<PAT> That is part of the text under "In literal list negotiation..."
It doesn't apply to the other negotiation types (e.g. numerical) because
the requester doesn't give offered options. For instance, in numerical
negotiation, the requester gives a single value and the responder returns a
response based upon a key specific rule such as return the lower of the
request value and responder's maximum value.

Comments?

---

From: [email-masked]
Date: Wed, 20 Feb 2002 18:29:00 -0700

Santosh,

If it is during Login Phase, then the target can't send a Reject PDU to
indicate protocol error because only Login Request and Login Response PDUs
are allowed. 

A Login Response with a status class of Initiator Error and a status detail
of Initiator Error seems reasonable. None of the other status details seem
to quite fit the description. An invalid value isn't a missing parameter.

That would be consistant with the text on Negotiation Failures. 

I don't think it should respond to the key with not understood, but a
response to the key of Reject would be reasonable and doing so might make it
easier to debug the negotiation problem.

Regards,
Pat

-----Original Message-----
From: Santosh Rao [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 12:08 PM
To: IPS Reflector
Subject: Re: iSCSI: key negotiation - Unrecognized value?

Hello,

It seems like there are several possible responses on seeing a numeric
key being offered with a non-numeric key value. (ex :
"MaxBurstSize=yes", or "MaxConnections=yes").

1) Target ignores the received key, without affecting basic function. 
It responds to the key with NotUnderstood. 
Login negotiation outcome is then initiator implementation dependent.
Most likely, the initiator will terminate the TCP connection and error
back to the caller indicating that it could not open an iscsi
connection.  

2) Target may respond with a Reject PDU response indicating a "protocol
error". No login response is sent in this case (?). 

3) Target responds with a login response pdu indicating a
status_class_detail of 0x0207 (Missing Parameter).

4) Target may react to this error as a "format error" and close the TCP
connection. 

In all the cases, the end result is TCP connection termination. However,
the response (2) is the least desirable, since no long response is
generated.

I believe that (1) coupled with (3) is the most desirable behaviour. 

Regards,
Santosh

Julian Satran wrote:
> 
> If it is not a list element the it is Reject. If it is a list element
> and you recognize others then ignore the "bad" value else "Reject".
> 
> Regards,
> Julo
> 
>  "KRUEGER,MARJORIE (HP-Roseville,ex1)"
>  <[email-masked]>                     To:        "Ips
>  Sent by: [email-masked]        Reflector (E-mail)"
>                                        <[email-masked]>
>  20-02-02 03:22                                cc:
>                                                Subject:        iSCSI:
>                                        key negotiation - Unrecognized
>                                        value?
> 
> 
> 

-- 
##################################
Santosh Rao
Software Design Engineer,
HP-UX iSCSI Driver Team,
Hewlett Packard, Cupertino.
email : [email-masked]
Phone : 408-447-3751
##################################

---

From: "Buck Landry" <[email-masked]>
Date: Wed, 20 Feb 2002 22:42:50 -0600

<<<

Not to take this too far off track, but the exact phrase in the v10 draft,

"Before the Full Feature Phase is established, only Login Request and Login Response PDUs are allowed"

.. would seem to make Reject PDU reason code 0x01, "Full Feature Phase Command before login", fairly useless.

--buck

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 7:29 PM
To: [email-masked]; [email-masked]
Subject: RE: iSCSI: key negotiation - Unrecognized value?

Santosh,

Regards,
Pat

<snip>

---

From: "Julian Satran" <[email-masked]>
Date: Thu, 21 Feb 2002 09:16:14 +0200

Correct - I have removed it - Julo

"Buck Landry" <[email-masked]>
Sent by: [email-masked]
21-02-02 06:42

        To:     <[email-masked]>, <[email-masked]>
        cc: 
        Subject:        RE: iSCSI: key negotiation - Unrecognized value?

"Before the Full Feature Phase is established, only Login Request and 
Login Response PDUs are allowed"

.. would seem to make Reject PDU reason code 0x01, "Full Feature Phase 
Command before login", fairly useless.

--buck

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 7:29 PM
To: [email-masked]; [email-masked]
Subject: RE: iSCSI: key negotiation - Unrecognized value?

Santosh,

A Login Response with a status class of Initiator Error and a status 
detail
of Initiator Error seems reasonable. None of the other status details seem
to quite fit the description. An invalid value isn't a missing parameter.

I don't think it should respond to the key with not understood, but a
response to the key of Reject would be reasonable and doing so might make 
it
easier to debug the negotiation problem.

Regards,
Pat

<snip>

---

From: Eddy Quicksall <[email-masked]>
Date: Thu, 21 Feb 2002 13:24:54 -0500

Julian,
 
If we can use "reject" when it is not a list, can you please make that
clear? Also can we allow it for boolean's too just for completeness?
 
The rev 10 spec currently says:
 
If a responder does not support or is not allowed to use 
all of the offered options with a specific originator, it 
may use the constant "Reject". 
 
That is in the discussion of list negotiations. And an EMAIL you sent on 2/6
(RE: iSCSI: Boolean value (yes, no) negotiation) said:
 
--snip--
> Eddy is right - reject is not intended/valid for booleans.
>
> Julo

Eddy

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Thursday, February 21, 2002 1:18 AM
To: Luben Tuikov
Cc: Ips Reflector (E-mail); KRUEGER,MARJORIE (HP-Roseville,ex1);
[email-masked]

Marjorie is correct - the text is (quite) explicit about requiring reject. 
As for you example - the value to be answered by the target is the maximum
acceptable - see the rules for numeric negotiations. 

Julo 

Luben Tuikov <[email-masked]> 
Sent by: [email-masked] 
20-02-02 22:21 
        
        To:        "KRUEGER,MARJORIE (HP-Roseville,ex1)"
<[email-masked]> 
        cc:        "Ips Reflector (E-mail)" <[email-masked]>, Julian
Satran/Haifa/IBM@IBMIL 
        Subject:        Re: iSCSI: key negotiation - Unrecognized value? 

v10, pg 34, top:

v10, pg 33, middle:

Comments?

---

From: "Julian Satran" <[email-masked]>
Date: Fri, 22 Feb 2002 08:02:48 +0200

Eddy,

This thread took way too much list space. I made it clear from the outset 
that I'll fix the text.

Julo

Eddy Quicksall <[email-masked]>
21-02-02 20:24

        To:     Julian Satran/Haifa/IBM@IBMIL
        cc:     "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>, "ips@ece. 
cmu. edu (E-mail)" <[email-masked]>
        Subject:        RE: iSCSI: key negotiation - Unrecognized value?

Julian,

 
 
That is in the discussion of list negotiations. And an EMAIL you sent on 
2/6 (RE: iSCSI: Boolean value (yes, no) negotiation) said:
 
--snip--

Eddy

-----Original Message-----
From: Julian Satran [mailto:[email-masked]]
Sent: Thursday, February 21, 2002 1:18 AM
To: Luben Tuikov
Cc: Ips Reflector (E-mail); KRUEGER,MARJORIE (HP-Roseville,ex1); 
[email-masked]

Julo 

        

v10, pg 34, top:

v10, pg 33, middle:

Comments?

---

From: "Julian Satran" <[email-masked]>
Date: Fri, 22 Feb 2002 13:55:32 +0200

you are correct. Julo

[email-masked]
21-02-02 02:50

        To:     [email-masked], [email-masked], [email-masked], 
[email-masked]
        cc:     [email-masked], Julian Satran/Haifa/IBM@IBMIL
        Subject:        RE: iSCSI: key negotiation - Unrecognized value?

Thinking about this response further, "protocol error" should be replaced 
by
"negotiation failure." 2.2.4 says that selection of an inadmissible value
must be considered a protocol error and handled accordingly, but 7.8
Protocol Errors doesn't seem to say anything relevant to this type of 
error.
Also during login one cannot send a reject PDU with a reason code of
Protocol Error.

Pat

-----Original Message-----
From: THALER,PAT (A-Roseville,ex1) [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 3:34 PM
To: LEMAY,KEVIN (A-Roseville,ex1); 'Luben Tuikov'; KRUEGER,MARJORIE
(HP-Roseville,ex1)

It currently describes Reject only in the context of list negotiation 
where
it is used when none of the values in the offered list are acceptable. For
the example Luben gives of a numerical negotiation (MaxConnections), 
Reject
would never be a valid response. If the originator offers a higher valid
value than the responder is willing to accept, the responder would respond
with the lower number that it is willing to accept. So a valid negotiation
for the case where the originator asks for a valid assignable value than 
the
responder is willing to support would be something like:

In the example Luben gave, 4294967296 is not a valid value for
MaxConnections because it is outside the range <number-from-1-to-65535>. 
The
draft doesn't say what to do about out of range values and other invalid
values.

The draft does say that "selection of a value not admissible under the
selection rules rules is considered a protocol error and is handled
accordingly." The context for that statement appears to be the selection 
of
a value offered by the responder, but that action would also make sense 
for
responding to a value that is invalid for the key (wrong type of value or
out of range). An implementation offering an invalid value is broken which
makes proceeding with the negotiation a problem.

Regards,
Pat

-----Original Message-----
From: LEMAY,KEVIN (A-Roseville,ex1) [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 12:33 PM
To: 'Luben Tuikov'; KRUEGER,MARJORIE (HP-Roseville,ex1)
Cc: Ips Reflector (E-mail); Julian Satran
Subject: RE: iSCSI: key negotiation - Unrecognized value?

My impression was that "notUnderstood" was used if the key name itself 
could
not be decoded.

Although processing as "notunderstood" may allow the login to continue, it
will also "cover up" the error allowing bad code to continue live on. Do 
we
really want to make it easy for people to not even follow the spec?

Kevin Lemay 

-----Original Message-----
From: Luben Tuikov [mailto:[email-masked]]
Sent: Wednesday, February 20, 2002 12:17 PM
To: KRUEGER,MARJORIE (HP-Roseville,ex1)
Cc: Ips Reflector (E-mail); Julian Satran
Subject: Re: iSCSI: key negotiation - Unrecognized value?

Marjorie, Julian, all,

?