Subject: iSCSI: key negotiation - Unrecognized value?

From: "KRUEGER,MARJORIE (HP-Roseville,ex1)" <[email-masked]>
Date: Tue, 19 Feb 2002 20:22:37 -0500

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: Luben Tuikov <[email-masked]>
Date: Wed, 20 Feb 2002 15:21:16 -0500

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

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".

Comments?

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

---

From: Luben Tuikov <[email-masked]>
Date: Wed, 20 Feb 2002 15:17:22 -0500

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.

---

From: Paul Koning <[email-masked]>
Date: Wed, 20 Feb 2002 17:09:31 -0500 (EST)

>>>>> "Luben" == Luben Tuikov <[email-masked]> writes:

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

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

That doesn't sound right, because the spec says that NotUnderstood
applies to keys, not to values.

The best fit is "reject" though the wording of the spec doesn't really
say that.  Actually, the spec is unconfortably fuzzy about all this
stuff; for example, the fact that it says '...may use the constant
"Reject"' is weird.  I assume that should be "...MAY use..." but why
does it say "may" -- what other alternative is there?  

For the case here, a single (non-list) key with a syntactically
invalid value, I can't get particularly excited about the answer.
Dealing elegantly with defective initiators isn't all that critical.
Sure, if it's easy and reasonable (which it seems to be) let's
generalize the wording for "Reject" so it clearly applies to this case.

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

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

I don't think so.  That's a numeric negotiation, lower value wins.  So
the responder must pick a number it supports <= the value supplied by
the originator.  "Reject" would be valid if there is no such number.
(That's not possible for this particular key.)

A way to justify "reject" is with the argument that 4294967296 is not
a valid integer string here because it is out of range.  True, and
that would justify treating it as no different from initiator saying
"yes" for this key.  Then again, I'd expect that a lot of responders
would simply run the key through atoi(), observe that this worked, see
that the value is too large, and reply with an acceptable value.

	paul