RE: How do you negotiate a numerical range?

[Bill Studenmund <wrstuden@wasabisystems.com>]

On Wed, 17 Jul 2002, Martin, Nick (Server Storage) wrote:

> Bill,
>
> I agree that there could be more to do if/when we need ranges.
> Ranges are not allowed unless specifically stated for a particular key.

So we are safe for now.

This note (and this thread actually) is going a bit far afield. Its
relevance I think is that we are showing how we don't seem to have a clear
idea of how to use ranges, and as such we have a part of the spec
(admittedly unused at the moment) which we don't have clear in our head,
and which we don't seem to realize we don't have clear in our head (*).

(*) as opposed say to bi directional scsi commands, which I gather
everyone thinks we need field experience to decide what we want to do.

> >From working draft 15:
>
> "The value offered or declared can be a numerical-value, a numericalrange
> defined by lower and upper value with both integers separated
> by tilde, a binary value, a text-value, a iSCSI-name-value, an iSCSIlocal-
> name-value, a boolean-value (Yes or No), or a list of comma
> separated text-values.
>                         A range or a large-numerical-value MAY ONLY be
> offered if it is explicitly allowed for a key.
>                                                 An iSCSI-name-value
> and an iSCSI-local-name-value can be used only where explicitly
> allowed. A selected value can be an numerical-value, a large-numerical-
> value, a text-value or a boolean-value."
>
>
> I disagree with your conclusion in Question 1.
> Offering a range for this particular key is an error.

For the moment yes. But the point was to run a thought experement to see
what would happen if we permitted it.

> However presuming for a moment that a range is allowed for the key in
> the example, I think this must result in a negotiation failure for
> this key and login may fail.
>
> As I read you example, the responder seems to support the range 2~2
> which has no values in common with 3~10.  Responding with 2 is a
> protocol violation.  The correct response would be "Reject".

More below.

> If a key which requires a single numeric result allows a range to be
> offered, a value within the offered range must be selected.

> Responding with a value outside the offered range would be a protocol
> violation.

> If such a key has a MIN or MAX rule, this should specify whether the
> largest or smallest value common between the range offered and the
> range supported by the responder should be selected.  If 3~10 is
> offered, and 2~6 is supported by the responder, then the result with a
> MIN rule would be 3 and the result with a MAX rule would be 6.  If
> there is neither a MIN nor MAX rule then 3, 4, 5, and 6 are all valid
> responses (implementer's choice).  This is intuitive, but would
> perhaps need to be clearly stated to prevent other interpretation.

My concern with that is what would happen if you could offer both a single
number and a range? Think about MaxConnections for a moment. For it, we
want as many connections as both sides can support and no more. If we
exchange just numbers, then each side offers its max (say A and B), and we
choose the MIN of the two. But if we were dealing with ranges, we (AFAICT)
should offer the valid range we can accept, which would be 1~A and 1~B. We
then want the MAX of the intersection. So the MIN/MAX-ness of a parameter
flips if you're talking about a range or single numbers. :-|

> I could envision a key which requires a range as the result.  In this
> case the rule for the result might be the INTERSECTION of the range
> offered that the responder also supports.  Thus for an offer of 4~20
> the responses 4~8, 5~10, and 10~20 could each be valid depending on
> the supported range of the responder, but 2~4, 15~25, and 25~30 are
> all invalid responses because they include values outside the offered
> range.  There could also be a rule called UNION, but I have trouble
> imagining a use for it in negotiations.  As I read the excerpt above,
> keys which require a range as a result are currently prohibited.

That could be done. I agree I can't see a use for it now. :-)

> If non-intuitive results such as you describe in Question 1 were not
> already prohibited, then IMHO the spec would require revision.

Well, I do wonder why we need to talk about ranges when 1) we don't use
them, and 2) we don't have one clear idea how someone would use them. :-)

True that they only would be usable for vendor-specific keys now, but
since there's no agreed-on way to use them. So different vendors may
implement them differently. If I wanted to implement different vendors'
private keys, I could well end up needing different range implementations
for each vendor. :-|

Is there a reason we shouldn't just rip the range text out now? It's not
usable as-is, and we certianly can put it back when we 1) need it and 2)
have decided how to deal with the above.

??

Take care,

Bill