Andy Bakun wrote:
On Sat, 2005-03-26 at 13:19, David MacQuigg wrote:
After processing the mask, if there is any match, proceed with the terms as
usual. If there is no match, skip processing any terms except 'all', and
don't call for any remainder of a truncated record.
Will this even work? In chained records, the -all is in the final
record, and the mask is supposed to allow the evaluator to abort sooner
without looking up those records. It won't have to evaluate them except
for looking for redirect= to finally get to an all so it can extract the
+, -, ~ or ? from it.
That's why the modifier includes a prefix. The compiler would copy the
prefix of the all mechanism in the uncompiled record to the prefix of
the mask. Essentially that allows you to know at the top record what the
last record ends with.
On the other hand, maybe the mask modifier should encourage people to
get their network in order so they can use -all. Then they can use the
mask modifier and keep the same result (+-?~) across the entire IP
address space.
On Sat, 2005-03-26 at 10:53, Radu Hociung wrote:
Actually, if I read the above correctly, -m= is not legal. m-= is ok,
but m~= and m?= are not. So lets make it
m = [PREFIX] [IP notation]
This fits within the syntax but is super unintuitive because it's
different from everything else. Fortunately, only compilers will be
generating it.
I don't see why it's hard for a human to understand what the compiler
did ? As for the compiler, intuitive is not important, because it's just
following rules like any other machine :)
Frank's negated-inclusive-include (or whatever you wanna call it), while
being addition queries, doesn't have this problem -- the entire SPF
syntax remains available.
True. But let's quickly analyze a mask like m=-65/6 m=213/8
How would this be specified with an excluding-include (Frank you gotta
give this thing a name ;) )
Frank also showed the IP list that would have to be included for the two
concepts to be equivalent.
In the example above, which is a little more complex than the one Frank
showed, the include would be this:
/* expand m=-65/6 */
ip4:0.0.0.0/2 ip4:128.0.0.0/1 ip4:96.0.0.0/3
ip4:80.0.0.0/4 ip4:72.0.0.0/5 ip4:68.0.0.0/6
/* expand m=213/8 (213=128+64+16+4+1)*/
-ip4:0.0.0.0/2 -ip4:128.0.0.0/1 -ip4:96.0.0.0/3
-ip4:64.0.0.0/4 -ip4:(128+64+32).0.0.0/5 ...
This would be a much longer list. Frank, would you mind running the
script you wrote to generate the equivalent include list?
Also, please note that the 65/6 is a very lowsy mask. A better mask is
more narrow, ie it has a higher CIDR. 65.0.0.0/24 is a much tighter mask
around "ip4:65.0.0.55 ip4:65.0.0.32" than 65/6. Also 65.0.0.0/25 is
twice as tight as the /24 mask, and 65.0.0.0/26 is four times as tight.
65.0.0.32/27 is as tight as it gets without breaking it down into two
separate m= modifiers, each of which would be /32 tight.
A larger CIDR specifies a narrower mask. Unfortunately, the expanded
list of ip4: mechanisms grows very fast as the CIDR increases.
Frank, out of curiosity, what is the include list for 65.0.0.32/27 ?
The tightest mask possible would be "m=-65.0.0.55 m=65.0.0.32"
You can imagine that a list of IP4 mechanisms that match everything but
that tightest mask would be a very long list. The more fragmented the
space that a mask specifies, the longer the equivalent includeable list
gets.
Thank you,
Radu.