I tried fixing some of the known problems with comparison of INET values
(cf. thread "uniqueness not always correct" on 11/11/99, among others),
and was surprised to discover that my changes affected the results of
the inet regress test.  Specifically, the regress test exercises all the
inet comparison operators on the two data values
	'10.1.2.3/8'::inet     '10.0.0.0/32'::cidr
The old code believes that the first of these is greater, while my
revised code thinks the second is greater.

Now, my understanding of things is that '10.1.2.3/8' is just an
unreasonably verbose way of writing '10/8', because if you write /8
you are saying that only the first 8 bits mean anything.  So it seems
to me that we are really comparing '10/8' and '10.0.0.0/32', and the
former should be considered the lesser in the same way that 'ab'
comes before 'abc' in dictionaries.

Is the regress test's expected output wrong, or have I missed
something?

			regards, tom lane

Thu, 17 Feb 2000 02:25:13 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Definitional issue for INET types
Tom Lane wrote:

> Now, my understanding of things is that '10.1.2.3/8' is just an
> unreasonably verbose way of writing '10/8', because if you write /8
> you are saying that only the first 8 bits mean anything.  

Not really. In a classed view on a network, the /8 is undefined - and
worse, there is no real concept of a address consisting of a 
network/netmask tuple. /8 might imply that 10.1.2.3 is in the class A
segment, it might be considered a 255.0.0.0 netmask with any possible
interpretation of the latter, or it might be entirely ignored. For
::cidr vs. ::cidr the answer is clear - apply the masks and match then,
which would make 10/8 lesser by all means.

> So it seems
> to me that we are really comparing '10/8' and '10.0.0.0/32', and the
> former should be considered the lesser in the same way that 'ab'
> comes before 'abc' in dictionaries.
> 
> Is the regress test's expected output wrong, or have I missed
> something?

Tough question. There are some nasty details differing between classed
network notation and CIDR notation, and we certainly cannot reconcile
them all in operators. As the significant digits are meaningless in
classed notation, they might either be ignored or interpreted according
to any rule applying to classed netmasks, which really depends on the
context of the network device - a router, firewall or audit tool might
each have different semantics and requirements.  

I'll see whether I can figure out something consistent for the inet data
type. As it is right now, we might just as well drop it - it is both
synonymous to cidr and to a cidr /32 host, which simply can't be.
Personally, I don't think we would lose any functionality if we drop it,
as long as we have functions that return classed network structures like
the base address and a networks subnettable range. 

Sevo


-- 
Sevo Stille
sevo@ip23.net

Thu, 17 Feb 2000 13:07:59 +0100
Sevo Stille <sevo@ip23.net>
Re: [HACKERS] Definitional issue for INET types
On Thu, 17 Feb 2000, Tom Lane wrote:

> 	'10.1.2.3/8'::inet     '10.0.0.0/32'::cidr
> The old code believes that the first of these is greater, while my
> revised code thinks the second is greater.

I think we can flip a three-sided coin here:

1) '10.1.2.3/8'::inet is not a valid inet input value, sort of in the same
way as 10.5 is not a valid integer.

2) You coerce '10.1.2.3/8'::inet to essentially '10.0.0.0/8'::inet on
input. (In some parts, implicit data mangling that loses information is
not considered good practice.)

3) You can't compare inet and cidr because they're two different (albeit
similar) things. If you want to compare them you have to explicitly cast
inet to cidr or vice versa according to 1) or 2).

In any case I believe you revised code has a very good point.


-- 
Peter Eisentraut                  Sernanders vaeg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden


Thu, 17 Feb 2000 13:10:49 +0100 (MET)
Peter Eisentraut <e99re41@DoCS.UU.SE>
Re: [HACKERS] Definitional issue for INET types
Peter Eisentraut <e99re41@DoCS.UU.SE> writes:
> 3) You can't compare inet and cidr because they're two different (albeit
> similar) things. If you want to compare them you have to explicitly cast
> inet to cidr or vice versa according to 1) or 2).

This might in fact be the right answer --- maybe CIDR and INET should
have different comparison semantics.  Right now the two types seem to
share exactly the same operators, which makes me wonder why we have
both.

I don't suppose Paul Vixie is still reading this list.  Someone should
contact him and ask where we went wrong.  Who was our point man on the
network types to begin with?

			regards, tom lane

Thu, 17 Feb 2000 10:41:38 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Definitional issue for INET types 
Sevo Stille <sevo@ip23.net> writes:
> I'll see whether I can figure out something consistent for the inet data
> type. As it is right now, we might just as well drop it - it is both
> synonymous to cidr and to a cidr /32 host, which simply can't be.
> Personally, I don't think we would lose any functionality if we drop it,
> as long as we have functions that return classed network structures like
> the base address and a networks subnettable range. 

Hmm.  One way to throw the question into stark relief is to ask:
Is '10/8' *equal to* '10.0.0.0/32', in the sense that unique indexes
and operations like SELECT DISTINCT should consider them identical?
Does your answer differ depending on whether you assume the values
are of CIDR or INET type?

Once we have decided if they are equal or not, we can certainly manage
to come up with a sort ordering for the cases that are not equal.

			regards, tom lane

Thu, 17 Feb 2000 10:49:19 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Definitional issue for INET types 
Tom Lane wrote:
 
> Hmm.  One way to throw the question into stark relief is to ask:
> Is '10/8' *equal to* '10.0.0.0/32', in the sense that unique indexes
> and operations like SELECT DISTINCT should consider them identical?
> Does your answer differ depending on whether you assume the values
> are of CIDR or INET type?

Well, in a CIDR context, they positively are different, '10.0.0.0/32' is
a host, and '10/8' is a network, and our application would positively
treat either entirely different. CIDR consistently works by
apply-mask-and-process.  

In a INET context, the answer is not that easy, as net and mask have no
defined behaviour as a tuple. The mask will in some cases be a
independent entity, which presumably is why Paul Vixie made meaningless
net/mask combinations  legal there. If INET is used to store e.g. a
Cisco wildcard value, the /xx part is meaningless - however, 10.1.2.3/8
would not be a shorthand for 10/8 then. 

As far as ipmeter is concerned, we found out that INET is of no use for
us - even if there are some strange things you might do with odd
net/mask patterns, few of them follow any easily defined paradigm.
Personally, I am all for dropping INET, or for defining it to be
maskless (which could be done by forcing /32 for it).

Sevo

Thu, 17 Feb 2000 17:11:28 +0100
Sevo Stille <sevo@ip23.net>
Re: [HACKERS] Definitional issue for INET types
Sevo Stille <sevo@ip23.net> writes:
>> Hmm.  One way to throw the question into stark relief is to ask:
>> Is '10/8' *equal to* '10.0.0.0/32', in the sense that unique indexes
>> and operations like SELECT DISTINCT should consider them identical?
>> Does your answer differ depending on whether you assume the values
>> are of CIDR or INET type?

> Well, in a CIDR context, they positively are different, '10.0.0.0/32' is
> a host, and '10/8' is a network, and our application would positively
> treat either entirely different. CIDR consistently works by
> apply-mask-and-process.  

OK.  Now let's try you on this one: true or false?
	'10.1.2.3/8'::cidr = '10/8'::cidr

(which was actually the example I meant to ask about above, but
carelessly cut-and-pasted the wrong values :-(.)

> In a INET context, the answer is not that easy, as net and mask have no
> defined behaviour as a tuple. The mask will in some cases be a
> independent entity, which presumably is why Paul Vixie made meaningless
> net/mask combinations  legal there.

I think that was the idea, all right, which would seem to suggest that
we ought to compare all the bits of the IP addresses, and then compare
the bitcounts (since the bitcount is just a compact representation of a
logically separate netmask, and has nothing to do with the validity of
the IP address).  But I'm not sure whether this holds good for CIDR too.

> Personally, I am all for dropping INET, or for defining it to be
> maskless (which could be done by forcing /32 for it).

If you don't need a mask, leave out the /32 --- or even add a column
constraint requiring it to be 32.  I don't see that it's necessary
to tell other people that they can't have a mask.  CIDR may be a
different story however.

			regards, tom lane

Thu, 17 Feb 2000 11:38:01 -0500
Tom Lane <tgl@sss.pgh.pa.us>
Re: [HACKERS] Definitional issue for INET types 