RE: iSCSI: key negotiation - Unrecognized value?

[pat_thaler@agilent.com]

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:pat_thaler@agilent.com]
Sent: Wednesday, February 20, 2002 3:34 PM
To: LEMAY,KEVIN (A-Roseville,ex1); 'Luben Tuikov'; KRUEGER,MARJORIE
(HP-Roseville,ex1)
Cc: Ips Reflector (E-mail); Julian Satran
Subject: RE: iSCSI: key negotiation - Unrecognized value?


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:kevin_lemay@agilent.com]
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.

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:luben@splentec.com]
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.