Re: hackers-digest V1 #1013

Thus spake Paul A Vixie

i would very much like inet_net_pton to not be changed in this way,

You mean inet_net_ntop, right?

even though it's an internal server function the way postgres 6.4
will be packaged. there is an RFC specifying what this function does.

Are you talking about RFC2133? That one doesn't even specify bits as
an argument so this is already different. Is there another one I
should be looking at?

If a function is based on a standards document like this, shouldn't
we include that as a comment in the file?

Anyway, I seem to be mistaken about the whole cidr or inet type.
Based on the discussions we had earlier I am surprised by the
following.

darcy=> select '198.1.2.3/8'::inet;
?column?
--------
198/8
(1 row)

I would have expected it to print what I entered. If the above is
correct then perhaps we still need a cidr type that behaves differently
or rename this to cidr and write a new inet type.

Here is what I thought we were talking about taken from postings in
this list back in July.

From Bruce Momjian:
My guess is that it is going to output x.x.x.x/32, but we should supply
a function so they can get just the IP or the mask from the type. That
way, people who don't want the cidr format can pull out the part they
want.

This suggests that the whole address is stored and by default would be
output. Are we outputting just the network part now and expecting my
functions to get the host part?

I said:

Perhaps there is an underlying difference of assumptions about what
the actual type is. Let me take a stab at defining it (without
naming it) and see if we're all on the same bus.

I see the underlying data type storing two things, a host address
(which can hold an IPv4 or IPv6 IP) and a netmask which can be
stored as a small int, 8 bits is plenty. The input function would
read IP numbers as follows (I'm making some of this up as I go.)

x.x.x.x/y IP x.x.x.x with masklen y
x.x.x.x:y.y.y.y IP x.x.x.x with masklen determined by examining
y.y.y.y raising an exception if it is an invalid
mask (defined as all ones followed by all zeroes)
x.x.x.x IP x.x.x.x masklen of 32

The output functions would print in a standard way, possibly allowing
alternate representations like we do for money. Also, there would
be functions to extract the host, the network or the netmask.

Is this close to what everyone thinks or are we talking about completely
different things?

No one contradicted me so I assumed that there was agreement.

From Bruce Momjian:
That way, if they specify cidr bits, we store it. If they don't we make
the bits field equal -1, and print/sort appropriately. The addr len is
usually 3, but ip6 is also easy to add by making the addr len equal 6.

Supporting the idea of setting bits to -1 to mean an unspecified netmask.

I also checked doc/README.inet. It seems to support what I expect
although it doesn't mention setting bits to -1.

So what do I do? Should I redo the inet functions without using the
inet_net_* functions as described above or is the current behaviour the
one we wanted?

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.

darcy@druid.net (D'Arcy J.M. Cain) writes:

Based on the discussions we had earlier I am surprised by the
following.

darcy=> select '198.1.2.3/8'::inet;
?column?
--------
198/8
(1 row)

I would have expected it to print what I entered.

Why? You told it to truncate the data to 8 bits, so it did. (At least,
that's my understanding of what the /n notation means, but maybe I'm
mistaken.)

regards, tom lane

Thus spake Tom Lane

darcy@druid.net (D'Arcy J.M. Cain) writes:

Based on the discussions we had earlier I am surprised by the
following.

darcy=> select '198.1.2.3/8'::inet;
?column?
--------
198/8
(1 row)

I would have expected it to print what I entered.

Why? You told it to truncate the data to 8 bits, so it did. (At least,
that's my understanding of what the /n notation means, but maybe I'm
mistaken.)

As I explained, I was surprised based on my understanding of the type
based on previous postings.

BTW, for a real world example of the usage I was expecting, look at an
Ascend router. In a connection profile you can specify an IP for the
remote side as, e.g., 198.96.119.225/28. The Ascend pulls out all
the information it needs to set up that connection. It assigns
198.96.119.225 to the remote host, it routes the 16 addresses in that
subnet to that interface and, if RIP is enabled (a bad idea but allowed)
then it knows to announce on 198.96.119.239.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.

my take on this is that (1) inet_net_pton() is definitely broken in that
it is willing to write one more byte of output than its arguments allow,
and (2) inet_net_{pton,ntop}() is not suitable for postgresql's use here.

i can fix (1) in bind 8.1.3, and postgresql already has it fixed in its
version of bind's library.

there is no way to fix (2) without an api change. we need, in order to
meet the stated needs of folks here who have uses for an inet-like type,
a way to have the prefix length be less than the size of the bitstring
being introduced. "16.1.0.2/28" was given as an example, that being a
way to give both a host address and its netmask on some wire. i've
wanted this functionality from time to time in the past and i can see
why for postgresql's purposes that's what should be provided for the
"inet" (or, given this change, more properly the "cidr") type.

but inet_net_ntop() only returns one thing (the prefix length) and the
caller is expected to know how many octets of mantissa were generated
based on this returned prefix length. i propose a new interface, which
would have a different name, a different argument list, and a different
use:

int
inet_cidr_pton(af, src, dst, size, int *used)

this would work very much the same as inet_net_pton() except for three
things: (1) nonzero trailing mantissas (host parts) would be allowed; (2)
the number of consumed octets of dst would be set into *used; and (3) there
would be absolutely no classful assumptions made if the pfxlen is not
specified in the input.

int
inet_cidr_ntop(ag, src, len, bits, dst, size)

this would work very much the same as inet_net_ntop() except that the
size (in octets) of src's mantissa would be given in the new "len" argument
and not imputed from "bits" as occurs now. "bits" would just be output
as the "/NN" at the end of the string, and would never be optional.

if this is agreeable, i'll code it up and submit it here for testing before
i push it out in bind 8.1.3. i really do agree with the functionality we've
drifted toward in this type -- if folks want to express the netmask of a
host address without getting in trouble for a nonzero host part that's
lost during parsing and storage, then they jolly well ought to be able to
do that.

Paul A Vixie <paul@vix.com> writes:

if this is agreeable, i'll code it up and submit it here for testing
before i push it out in bind 8.1.3. i really do agree with the
functionality we've drifted toward in this type -- if folks want to
express the netmask of a host address without getting in trouble for
a nonzero host part that's lost during parsing and storage, then
they jolly well ought to be able to do that.

I certainly agree. We should then be able to switch very easily and
cleanly to the use of these new input and output functions, and add
the various utility functions that D'Arcy has outlined. Should be
quick work.

We should leave the type name as INET, I think.

Bruce/Marc: we're OK for 6.4 with this still, right? Even if it takes
a couple more days to get everything to fall into place?

-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"

Paul A Vixie <paul@vix.com> writes:

if this is agreeable, i'll code it up and submit it here for testing
before i push it out in bind 8.1.3. i really do agree with the
functionality we've drifted toward in this type -- if folks want to
express the netmask of a host address without getting in trouble for
a nonzero host part that's lost during parsing and storage, then
they jolly well ought to be able to do that.

I certainly agree. We should then be able to switch very easily and
cleanly to the use of these new input and output functions, and add
the various utility functions that D'Arcy has outlined. Should be
quick work.

We should leave the type name as INET, I think.

Bruce/Marc: we're OK for 6.4 with this still, right? Even if it takes
a couple more days to get everything to fall into place?

I think so. It does not affect people testing other things.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

Thus spake Tom Ivar Helbekkmo

if this is agreeable, i'll code it up and submit it here for testing
before i push it out in bind 8.1.3. i really do agree with the
functionality we've drifted toward in this type -- if folks want to
express the netmask of a host address without getting in trouble for
a nonzero host part that's lost during parsing and storage, then
they jolly well ought to be able to do that.

OK, I have cobbled up some functions and modified others in inet.c
based on the suggested cidr utility functions. I have made a few
assumptions which I am sure we will have to look at so that everyone
is comfortable with the code. I have added the following new functions.

char *inet_netmask(inet * addr);
int4 inet_masklen(inet * addr);
char *inet_host(inet * addr);
char *inet_network_no_bits(inet * addr);
char *inet_network_and_bits(inet * addr);
char *inet_broadcast(inet * addr);

The difference between inet_network_no_bits and inet_network_and_bits is
that for a.b.c.d/24, the former will return a.b.c and the latter will
return a.b.c/24. I couldn't use inet_network as a name anyway since
it conflicts with something in arpa/inet.h (On NetBSD -current).

If someone will add the necessary entries to the catalogues, I'll
start testing them. I'll post the changes to inet.c and builtins.h
to the patches list. I can't guarantee that they are bug-free yet
but it does compile and shouldn't interfere with anything anyone
else is doing.

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.

darcy@druid.net (D'Arcy J.M. Cain) writes:

I have another question. What is the point of "used?" Can't I just
assume 4 octets for ipv4 and 6 for ipv6? Can I set it to NULL if I
don't care about the value?

Not an answer to your question, but IPV6 does not use 6 byte
addresses; they are 16 bytes long.

-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"

From: darcy@druid.net (D'Arcy J.M. Cain)
Date: Sun, 11 Oct 1998 07:17:58 -0400 (EDT)

Thus spake Paul A Vixie

int
inet_cidr_pton(af, src, dst, size, int *used)

this would work very much the same as inet_net_pton() except for three
things: (1) nonzero trailing mantissas (host parts) would be allowed; (2)
the number of consumed octets of dst would be set into *used; and (3) there
would be absolutely no classful assumptions made if the pfxlen is not
specified in the input.

Is there also agreement on the use of -1 to mean unspecified netmask?

ok. this means we have to return octets and use an argument for *bits.

How about the optional input form h.h.h.h:m.m.m.m to specify netmask?

i'd rather avoid this, since cidr does not allow noncontiguous netmasks
and i'd rather not create another error return case unless it's REALLY
important. is it? as currently specified:

/*
* static int
* inet_cidr_pton(af, src, dst, size, *bits)
* convert network address from presentation to network format.
* accepts hex octets, hex strings, decimal octets, and /CIDR.
* "size" is in bytes and describes "dst". "bits" is set to the
* /CIDR prefix length if one was specified, or -1 otherwise.
* return:
* number of octets consumed of "dst", or -1 if some failure occurred
* (check errno). ENOENT means it was not a valid network address.
* note:
* 192.5.5.1/28 has a nonzero host part, which means it isn't a network
* as called for by inet_net_pton() but it can be a host address with
* an included netmask.
* author:
* Paul Vixie (ISC), October 1998
*/
int
inet_net_pton(int af, const char *src,
void *dst, size_t size,
int *bits)
{
switch (af) {
case AF_INET:
return (inet_cidr_pton_ipv4(src, dst, size, bits));
default:
errno = EAFNOSUPPORT;
return (-1);
}
}

int
inet_cidr_ntop(ag, src, len, bits, dst, size)

this would work very much the same as inet_net_ntop() except that the
size (in octets) of src's mantissa would be given in the new "len" argument
and not imputed from "bits" as occurs now. "bits" would just be output
as the "/NN" at the end of the string, and would never be optional.

And if bits is -1 then don't print the /NN part, right?

ok. here's what that looks like, for comments before i write it:

/*
* char *
* inet_cidr_ntop(af, src, len, bits, dst, size)
* convert network address from network to presentation format.
* generates "/CIDR" style result unless "bits" is -1.
* return:
* pointer to dst, or NULL if an error occurred (check errno).
* note:
* 192.5.5.1/28 has a nonzero host part, which means it isn't a network
* as called for by inet_net_pton() but it can be a host address with
* an included netmask.
* author:
* Paul Vixie (ISC), October 1998
*/
char *
inet_cidr_ntop(int af, const void *src, size_t len, int bits,
char *dst, size_t size)
{
switch (af) {
case AF_INET:
return (inet_cidr_ntop_ipv4(src, len, bits, dst, size));
default:
errno = EAFNOSUPPORT;
return (NULL);
}
}

From: darcy@druid.net (D'Arcy J.M. Cain)
Date: Sun, 11 Oct 1998 07:40:41 -0400 (EDT)

Thus spake Paul A Vixie

int
inet_cidr_pton(af, src, dst, size, int *used)

this would work very much the same as inet_net_pton() except for three
things: (1) nonzero trailing mantissas (host parts) would be allowed; (2)
the number of consumed octets of dst would be set into *used; and (3) there
would be absolutely no classful assumptions made if the pfxlen is not
specified in the input.

I have another question. What is the point of "used?" Can't I just
assume 4 octets for ipv4 and 6 for ipv6? Can I set it to NULL if I
don't care about the value?

we probably could have done this until we had to return octets and fill *used
with the bits. but more importantly, i think we should still only touch the
octets in *dst that are nec'y. this is consistent with the _ntop() as well.

From: darcy@druid.net (D'Arcy J.M. Cain)
Date: Sun, 11 Oct 1998 20:22:25 -0400 (EDT)

... [One] more thing. I built my stuff on the assumption that the
inet_cidr_ntop function returned char *, not int. I assume that was
just an error in your message. In fact, here is the way I added the
prototypes to builtins.h.

Yes.

char *inet_cidr_ntop(int af, const void *src, size_t len, int bits, char *dst, size_t size);
int inet_cidr_pton(int af, const void *src, void *dst, size_t size, int *used);

Is this what you had in mind?

Yes. But note that as now proposed, inet_cidr_pton() returns octets not bits
as earlier proposed, and sets *used to the bits not the octets as earlier
proposed.

If there are no further comments?

(In case y'all are wondering, this is how BIND's other library functions
got specified, though the driving application wasn't PostGreSQL last time.)

Thus spake Paul A Vixie

From: darcy@druid.net (D'Arcy J.M. Cain)
How about the optional input form h.h.h.h:m.m.m.m to specify netmask?

i'd rather avoid this, since cidr does not allow noncontiguous netmasks
and i'd rather not create another error return case unless it's REALLY
important. is it? as currently specified:

Not that important I think. It was just a leftover though from earlier
discussions. I just wanted to make sure we considered it. The issue
of the extra error return came up back then too.

/*
* static int
* inet_cidr_pton(af, src, dst, size, *bits)
* convert network address from presentation to network format.
* accepts hex octets, hex strings, decimal octets, and /CIDR.
* "size" is in bytes and describes "dst". "bits" is set to the
* /CIDR prefix length if one was specified, or -1 otherwise.
* return:
* number of octets consumed of "dst", or -1 if some failure occurred
* (check errno). ENOENT means it was not a valid network address.

So if it is a network we don't have to fill the whole structure, right?
What happens on these calls?

inet_cidr_pton(af, "192.5/16", dst, sizeof dst, &bits);
inet_cidr_pton(af, "192.5/24", dst, sizeof dst, &bits);
inet_cidr_pton(af, "192.5.5.1/16", dst, sizeof dst, &bits);

I'm guessing that the return and bits for each would be (2, 16), (3, 24)
and (4, 16). Is that correct or since they are all ipv4 addresses would
the size always be 4?

* note:
* 192.5.5.1/28 has a nonzero host part, which means it isn't a network
* as called for by inet_net_pton() but it can be a host address with
* an included netmask.
* author:
* Paul Vixie (ISC), October 1998
*/
int
inet_net_pton(int af, const char *src,

inet_cidr_pton?

ok. here's what that looks like, for comments before i write it:

/*
* char *
* inet_cidr_ntop(af, src, len, bits, dst, size)
* convert network address from network to presentation format.
* generates "/CIDR" style result unless "bits" is -1.

Sounds right.

I have another question. What is the point of "used?" Can't I just
assume 4 octets for ipv4 and 6 for ipv6? Can I set it to NULL if I
don't care about the value?

we probably could have done this until we had to return octets and fill *used
with the bits. but more importantly, i think we should still only touch the
octets in *dst that are nec'y. this is consistent with the _ntop() as well.

Does this mean we need to add a size element to the inet structure?

Yes. But note that as now proposed, inet_cidr_pton() returns octets not bits
as earlier proposed, and sets *used to the bits not the octets as earlier
proposed.

OK. I'll wait till your stuff has been added to fix my stuff. That way
I can test it and send in the final changes once (hopefully.)

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.

So if it is a network we don't have to fill the whole structure, right?

right.

What happens on these calls?

inet_cidr_pton(af, "192.5/16", dst, sizeof dst, &bits);
inet_cidr_pton(af, "192.5/24", dst, sizeof dst, &bits);
inet_cidr_pton(af, "192.5.5.1/16", dst, sizeof dst, &bits);

I'm guessing that the return and bits for each would be (2, 16), (3, 24)
and (4, 16). Is that correct or since they are all ipv4 addresses would
the size always be 4?

yes. :-). i mean, the former. {2,16}, {3,24}, and {4,16}. ipv4 is the
family of the address but does not dictate the size of the prefix. i still
don't want to touch octets which aren't specified, any more than i would
want to emit them in _ntop(). but that's my preference speaking -- what is
yours?

int
inet_net_pton(int af, const char *src,

inet_cidr_pton?

oops, yeah. you can see where i copied this stuff from.

Does this mean we need to add a size element to the inet structure?

i think so, yes.

Thus spake Paul A Vixie

inet_cidr_pton(af, "192.5/16", dst, sizeof dst, &bits);
inet_cidr_pton(af, "192.5/24", dst, sizeof dst, &bits);
inet_cidr_pton(af, "192.5.5.1/16", dst, sizeof dst, &bits);

I'm guessing that the return and bits for each would be (2, 16), (3, 24)
and (4, 16). Is that correct or since they are all ipv4 addresses would
the size always be 4?

yes. :-). i mean, the former. {2,16}, {3,24}, and {4,16}. ipv4 is the
family of the address but does not dictate the size of the prefix. i still
don't want to touch octets which aren't specified, any more than i would
want to emit them in _ntop(). but that's my preference speaking -- what is
yours?

Well, I don't mind filling in the whole structure. It would simplify
a few things and we wouldn't need to add a size element to the structure.
The network function will output it correctly, I think.

inet_network_with_bits('192.5/16') => '192.5/16'
inet_network_with_bits('192.5.5.1/16') => '192.5/16'
inet_network_with_bits('192.5/24') => '192.5.0/16'

Does this seem right?

Does this mean we need to add a size element to the inet structure?

i think so, yes.

Unless we zero-pad, right?

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.

From: darcy@druid.net (D'Arcy J.M. Cain)
Date: Tue, 13 Oct 1998 12:58:03 -0400 (EDT)

Well, I don't mind filling in the whole structure. It would simplify
a few things and we wouldn't need to add a size element to the structure.

ok.

The network function will output it correctly, I think.

inet_network_with_bits('192.5/16') => '192.5/16'
inet_network_with_bits('192.5.5.1/16') => '192.5/16'
inet_network_with_bits('192.5/24') => '192.5.0/16'

Does this seem right?

for networks, yes.

Does this mean we need to add a size element to the inet structure?

i think so, yes.

Unless we zero-pad, right?

ok. here's the current proposal. any further comments?

/*
* char *
* inet_cidr_ntop(af, src, bits, dst, size)
* convert network address from network to presentation format.
* generates "/CIDR" style result unless "bits" is -1. "src"'s
* size is determined from its "af".
* return:
* pointer to dst, or NULL if an error occurred (check errno).
* note:
* 192.5.5.1/28 has a nonzero host part, which means it isn't a network
* as called for by inet_net_pton() but it can be a host address with
* an included netmask.
* author:
* Paul Vixie (ISC), October 1998
*/
char *
inet_cidr_ntop(int af, const void *src, int bits, char *dst, size_t size) {
switch (af) {
case AF_INET:
return (inet_cidr_ntop_ipv4(src, bits, dst, size));
default:
errno = EAFNOSUPPORT;
return (NULL);
}
}

...

/*
* int
* inet_cidr_pton(af, src, dst, *bits)
* convert network address from presentation to network format.
* accepts hex octets, hex strings, decimal octets, and /CIDR.
* "dst" is assumed large enough for its "af". "bits" is set to the
* /CIDR prefix length if one was specified, or -1 otherwise.
* return:
* 0 on success, or -1 if some failure occurred (check errno).
* ENOENT means it was not a valid network address.
* note:
* 192.5.5.1/28 has a nonzero host part, which means it isn't a network
* as called for by inet_net_pton() but it can be a host address with
* an included netmask.
* author:
* Paul Vixie (ISC), October 1998
*/
int
inet_cidr_pton(int af, const char *src, void *dst, int *bits) {
switch (af) {
case AF_INET:
return (inet_cidr_pton_ipv4(src, dst, bits));
default:
errno = EAFNOSUPPORT;
return (-1);
}
}

Thus spake Paul A Vixie

The network function will output it correctly, I think.

inet_network_with_bits('192.5/16') => '192.5/16'
inet_network_with_bits('192.5.5.1/16') => '192.5/16'
inet_network_with_bits('192.5/24') => '192.5.0/16'

Does this seem right?

for networks, yes.

Hmm. It _is_ the network function I was talking about. The same inputs
whould give the following results.

Input Network (with) Network (without) Host Broadcast
192.5/16 192.5/16 192.5 192.5.0.0 192.5.255.255
192.5.5.1/16 192.5/16 192.5 192.5.0.0 192.5.255.255
192.5/24 192.5.0/16 192.5.0 192.5.0.0 192.5.0.255

Of course, you wouldn't expect the first and last to have the host function
applied to it. They are probably in a field used to store networks.

ok. here's the current proposal. any further comments?

/*
* char *
* inet_cidr_ntop(af, src, bits, dst, size)
* convert network address from network to presentation format.
* generates "/CIDR" style result unless "bits" is -1. "src"'s
* size is determined from its "af".

And size is the available space in dst, right? Perfect.

/*
* int
* inet_cidr_pton(af, src, dst, *bits)
* convert network address from presentation to network format.
* accepts hex octets, hex strings, decimal octets, and /CIDR.
* "dst" is assumed large enough for its "af". "bits" is set to the
* /CIDR prefix length if one was specified, or -1 otherwise.

This sounds bang-on to me. How soon before your functions are in the
tree? I'll start modifying my code based on this but I won't send it
in until I have tested it against your functions.

By George! I think we've got it. :-)

-- 
D'Arcy J.M. Cain <darcy@{druid|vex}.net>   |  Democracy is three wolves
http://www.druid.net/darcy/                |  and a sheep voting on
+1 416 424 2871     (DoD#0082)    (eNTP)   |  what's for dinner.

This sounds bang-on to me. How soon before your functions are in the
tree? I'll start modifying my code based on this but I won't send it
in until I have tested it against your functions.

I have not seen any patch yet. Paul, was your earlier posting supposed
to be applied? If so, let me know.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026

darcy@druid.net (D'Arcy J.M. Cain) writes:

By George! I think we've got it. :-)

Yup! Great work, guys! I like what I see in the tree so far -- just
waiting for the transition to complete so I can use my network data
again! :-)

-tih
--
Popularity is the hallmark of mediocrity. --Niles Crane, "Frasier"

This sounds bang-on to me. How soon before your functions are in the
tree? I'll start modifying my code based on this but I won't send it
in until I have tested it against your functions.

I have not seen any patch yet. Paul, was your earlier posting supposed
to be applied? If so, let me know.

no. i will supply new source files to replace and augment the bind-based
source files in your current pool. (i'll want the new $Id:$'s for example.)

By George! I think we've got it. :-)

Yup! Great work, guys! I like what I see in the tree so far -- just
waiting for the transition to complete so I can use my network data
again! :-)

I've forgotten who volunteered to write or update docs for this. I need
to freeze the User's Guide fairly soon (~4 days?), and need to add a
mention of the CIDR data type in "datatype.sgml".

I assume that the README.inet which is currently in the tree is not an
accurate document now? I would be happy to transcribe a plain text
description into sgml, and would then expect last-minute updates to
happen in the sgml source rather than the original plain text. OK?

- Tom

By George! I think we've got it. :-)

Yup! Great work, guys! I like what I see in the tree so far -- just
waiting for the transition to complete so I can use my network data
again! :-)

I've forgotten who volunteered to write or update docs for this. I need
to freeze the User's Guide fairly soon (~4 days?), and need to add a
mention of the CIDR data type in "datatype.sgml".

I assume that the README.inet which is currently in the tree is not an
accurate document now? I would be happy to transcribe a plain text
description into sgml, and would then expect last-minute updates to
happen in the sgml source rather than the original plain text. OK?

There were no volunteers, and in fact, it is still changing. When it is
done, one of the few people who have followed the features will have to
write something up.

-- 
  Bruce Momjian                        |  http://www.op.net/~candle
  maillist@candle.pha.pa.us            |  (610) 853-3000
  +  If your life is a hard drive,     |  830 Blythe Avenue
  +  Christ can be your backup.        |  Drexel Hill, Pennsylvania 19026