New feature in v3: cast!

[Brian Candler]

On Sat, May 11, 2013 at 06:48:18PM -0400, Arran Cudbard-Bell wrote:
> One useful thing which i'm not sure Alan has implemented yet is:
> 
> if (<cidr>&Framed-IP-Address == 192.168.0.0/24) {
> 
> }
...
> With the cast, Framed-IP-Address gets converted to a /32, and the first 24
> bits from the values are compared.

Hmm, I think this syntax is obscure.  Here the == operator is being changed
to mean "is this IP address contained within that prefix"?  They're not
equal to each other.  Perhaps something like =~ would be clearer?

I'm also not sure that casting the LHS to <cidr> is a clear way of achieving
this.  The LHS is, and remains, a single IP address.  The RHS is a CIDR
prefix.

So I'd rather see:

if (Framed-IP-Address =~ <cidr>192.168.0.0/24) { ... }

or:

if (Framed-IP-Address =~ 192.168.0.0/24) { ... }

since the unquoted RHS literal can be unambiguously parsed as a CIDR prefix
anyway, and a comparison of IP value with CIDR value have the obvious
semantics.

Maybe the reason for casting the LHS to <cidr> so that you can go a general
comparison of (CIDR) to (CIDR) rather than (IP) within (CIDR).  In that
case, the rules for comparing two (CIDR) values need to be clear.  The two
prefix lengths may be different.  Are you just comparing the shorter of the
two prefixes (so that the == operator is commutative)?  Or does the ==
operator return true only if the LHS CIDR range is completely contained
within the RHS CIDR range?

Example:

    192.168.0.0/24 == 192.168.0.0/23    # true or false?
    192.168.1.0/24 == 192.168.0.0/23    # true or false?
    192.168.0.0/23 == 192.168.1.0/24    # true or false?

And what about single IP addresses in CIDR notation, where the host part is
non-zero?

    192.168.0.1/24 == 192.168.0.1/24    # true or false?
    192.168.0.1/24 == 192.168.0.2/24    # true or false?
    192.168.0.1/24 == 192.168.0.1/23    # true or false?

Also, is there planned to be an ordering for CIDR values?

    192.168.0.0/24 < 192.168.0.0/23     # true or false?

Finally, there is a problem of what to do with modules like rlm_sql and
rlm_files.  These are already restricted to returning LHS=attribute name,
RHS=string literal.  Unfortunately we can't use the =~ operator here because
people may already be doing things like

    ("Framed-IP-Address", "=~", "^192\.168\.")

So maybe it makes sense for these to return

    ("<cidr>Framed-IP-Address", "=~", "192.168.0.0/24")

but this still doesn't feel quite right to me.

Aside: if this is going to be done, I have a much more pressing need for
being able to qualify the attribute with the list name:

    ("reply:Framed-IP-Address", "=*", "present")

At the moment I have to copy a bunch of attributes from the reply list to
the request list, just so that rlm_sql can match them.

Regards,

Brian.