Re: INET/CIDR types

Larry Rosenman wrote:
> 
> The problem is NON-TECHNICAL people will be getting the output,
> and they expect 4 octet output.

Well, but what are they going to do if they see, say, that 196.100.0.0
is already allocated? Any CIDR net starting off on the .0 will have
exactly the same 4 octet notation. That is, the above entry would only
tell that there is some indeterminable number of addresses starting off
196.100.0.0 allocated, which could be anything between a measly /31 and
a whopping big /16. To repeat: CIDR having no implicit netmask encoded
in the class, there is no way of figuring out your allocation if you
lose the explicit mask. Which presumably will cause considerable
problems in a network allocation and tracking application!
> I really think that we should have a way to coerce a CIDR to
> an INET, and then allow host().

There is no unique mapping of a CIDR network to a INET host address,
except for the special case of /32. 
> Remember that I am dealing with $10/hour clerks.

Then given them a interface which makes the concept of CIDR obvious to
them. Faking a classed notation is no way to go! IP v.4 being what it
is, and registries being on the move to enforce CIDR more and more, they
will inevitably encounter CIDR sooner or later, probably in a business
critical way.  
> I really don't get the hostility to changing the OUTPUT format...

Anything broken that is added will sooner or later be used by somebody.
Which means that it can't be fixed without breaking some applications.
That alone should be a good enough reason not to introduce any broken
notions intentionally.

Sevo

-- 
Sevo Stille
sevo@ip23.net