Subject: RE: How do you negotiate a numerical range?

From: "Martin, Nick (Server Storage)" <[email-masked]>
Date: Wed, 17 Jul 2002 18:52:08 -0500

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. 

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

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.

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.  

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

Thanks,
Nick

> -----Original Message-----
> From: Bill Studenmund [mailto:[email-masked]]
> Sent: Wednesday, July 17, 2002 4:11 PM
> To: [email-masked]
> Subject: How do you negotiate a numerical range?
> 
> 
> I think I know the answer, but wanted to double check as 
> AFAICT all the
> numbers we have in the spec are either MIN or MAX; I suspect 
> not much code
> is using numerical ranges at the moment. Also, the spec doesn't say
> anything about negotiating ranges AFAICT. :-)
> 
> Question 1:
> 
> Since all of the numbers we have are MIN or MAX, my 
> understanding is that
> you just take the min or max of the range, and use that for 
> negotiation.
> 
> The initially-non-intuitive thing is that you can readily get 
> a negotiated
> value outside of the offered range. :-)
> 
> Consider an offer of "MaxConnections=3~10" to a device that wants
> MaxConnections=2. Since MaxConnections is a MIN number, the correct
> response (I believe) is "MaxConnections=2". I suspect however 
> this might
> seem counter-intuitive for new implementers.
> 
> Question 2:
> 
> Say you have a number that is not a MIN or MAX number (right 
> now this'd be
> a vendor-specific one), and you are offered a range (say 
> "Foo=3~12"), and
> had you made the offer you would have offered a different range (say
> "Foo=10~16"). Do we want to say anything now about how to handle this
> negotiation, or do we want to wait until we actually have a 
> non-MIN/MAX
> number in the spec?
> 
> I'd vote holding off, and just having everyone understand 
> there will be
> more work for some future version. :-)
> 
> Thoughts?
> 
> Take care,
> 
> Bill
> 
>

---

From: Bill Studenmund <[email-masked]>
Date: Wed, 17 Jul 2002 18:29:34 -0700 (PDT)

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

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

> 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