[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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. 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:firstname.lastname@example.org] 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:email@example.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:firstname.lastname@example.org] 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.
Last updated: Wed Feb 20 21:18:01 2002
8821 messages in chronological order