Does anyone know why IANA has assigned NS and A records to the example.{com,org,net,...} domains? They even put up a website at the IP explaining RFC 2606. * Why did they assign NSs and a valid IP to these invalid domains? * Are they breaking the RFC by doing this? * Are they breaking anti-UCE filters by doing this? (yes) * Are they harvesting URLs and referrers? * Will they next advertise routes for RFC 1918 addresses? -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Roger Marquis [1/4/2004 10:06 PM] :
Does anyone know why IANA has assigned NS and A records to the example.{com,org,net,...} domains? They even put up a website at the IP explaining RFC 2606.
Perhaps because at least some people don't know about RFC2606 (and they don't know RFC1918 as well, come to think of it) means and send spam complaints to IANA? Like for example http://groups.google.com/groups?selm=396A85E6.3FC5%40whew.com
* Are they breaking anti-UCE filters by doing this? (yes)
What filter are you trying to use? and what spam did you see that forged example.* in the sender envelope / rDNS?
* Will they next advertise routes for RFC 1918 addresses?
There's a lot of polishing to be done on your tinfoil hat, amigo ... them mind rays are starting to get through. srs -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
On Sun, 04 Jan 2004 08:36:17 PST, Roger Marquis said:
* Why did they assign NSs and a valid IP to these invalid domains?
So they can put up an explanatory website that says "Don't do that, you idiot". This is similar to the choice of one of the RFC1918 address blocks because a major vendor used an adddress in that block as their "Hey there, I'm an unconfigured system" address. Sometimes, things get done out of sheer pragmatism.
* Are they breaking the RFC by doing this?
I'd say the problem of 1918 leakage is a bigger concern. I'm sure the example.* webserver isn't getting thousands of hits per second like the root nameservers are seeing from 1918 addresses.
* Are they breaking anti-UCE filters by doing this? (yes)
Only in that you can't ban mail from example.com because it doesn't have a DNS entry. (a) I don't see enough forged mail from example.com to worry about it, and (b) I think we all should have learned about trusting *that* check implicitly after Verisign's stunt.
* Are they harvesting URLs and referrers?
Well, the URL would point to them. What do they get out of that? The referrer doesn't tell them anything, other than "the referer page had an example URL that somebody was dumb enough to click on". Note that at that point, you really *want* to hand the poor user an explanation rather than a host-not-found (see the first point).
* Will they next advertise routes for RFC 1918 addresses?
If they want to DDoS themselves, sure. If they did do it and your site noticed, you're obviously one of Randy Bush's competitors who took his advice. Google for '+bgp +filter', and get some heavier-duty aluminum foil next time you're at the supermarket..... Having said that, I wonder who'd notice if AS701 suddenly announced the 3 1918 blocks. Like Postel's hijacking of the root, no correctly configured systems should notice anything happened... :)
On Sun, 4 Jan 2004 Valdis.Kletnieks@vt.edu wrote:
* Why did they assign NSs and a valid IP to these invalid domains?
So they can put up an explanatory website that says "Don't do that, you idiot".
This is the best explanation I've read so far. Problem is, it's not a compelling rational. Is this really the only reason for assigning NS and A records, violating the RFC, and breaking thousands of spam filters in the process? -- Roger Marquis Roble Systems Consulting http://www.roble.com/
Roger Marquis [1/5/2004 3:19 AM] :
This is the best explanation I've read so far. Problem is, it's not a compelling rational. Is this really the only reason for assigning NS and A records, violating the RFC, and breaking thousands of spam filters in the process?
What spam did you see that forged example.* in the sender envelope / rDNS? example.* is well worth special-casing, I dare say, if you find spam being sent with it in the headers. -- srs (postmaster|suresh)@outblaze.com // gpg : EDEDEFB9 manager, outblaze.com security and antispam operations
On Mon, 5 Jan 2004, Suresh Ramasubramanian wrote:
What spam did you see that forged example.* in the sender envelope / rDNS?
reject: RCPT from 123-58-189-66.wo.cpe.charter-ne.com[66.189.58.123]: 554 <tested.from.204.69.218.218@example.com>: Recipient address rejected: Relay access denied; from=<> to=<tested.from.204.69.218.218@example.com> reject: RCPT from 123-58-189-66.wo.cpe.charter-ne.com[66.189.58.123]: 554 <tested.from.204.69.218.218@example.com>: Recipient address rejected: Relay access denied; from=<> to=<tested.from.204.69.218.218@example.com> reject: RCPT from 123-58-189-66.wo.cpe.charter-ne.com[66.189.58.123]: 554 <tested.from.66.207.192.254@example.com>: Recipient address rejected: Relay access denied; from=<> to=<tested.from.66.207.192.254@example.com> reject: RCPT from unknown[195.219.161.18]: 504 <sss>: Helo command rejected: need fully-qualified hostname; from=<sss@example.com> to=<sssx@example.com> reject: RCPT from 123-58-189-66.wo.cpe.charter-ne.com[66.189.58.123]: 554 <tested.from.172.153.194.136@example.com>: Recipient address rejected: Relay access denied; from=<> to=<tested.from.172.153.194.136@example.com> reject: RCPT from 123-58-189-66.wo.cpe.charter-ne.com[66.189.58.123]: 554 <tested.from.172.153.194.136@example.com>: Recipient address rejected: Relay access denied; from=<> to=<tested.from.172.153.194.136@example.com> reject: RCPT from adsl-65-66-178-75.dsl.snantx.swbell.net[65.66.178.75]: 554 <vic@victim.com>: Recipient address rejected; from=<pekon@example.com> to=<vic@victim.com> proto=SMTP helo=<compuserve.com> warning: 213.230.38.5: hostname reserved-multicast-range-NOT-delegated.example.com verification failed: Host not found reject: RCPT from cmailg1.svr.pol.co.uk[195.92.195.171]: 554 <cmailg1.svr.pol.co.uk[195.92.195.171]>: Client host rejected: Access denied; from=<thetoptenwebs@www.example.com> to=<vic@victim.com> reject: RCPT from lsanca2-ar24-4-62-187-078.lsanca2.dsl-verizon.net[4.62.187.78]: 554 Service unavailable; Client host [4.62.187.78] blocked using bl.spamcop.net; Blocked - see http://spamcop.net/bl.shtml?4.62.187.78; from=<bclark@dummy-host.example.com> to=<commsec@victim.com> proto=SMTP helo=<compuserve.com> reject: RCPT from 12-252-121-69.client.attbi.com[12.252.121.69]: 554 Service unavailable; Client host [12.252.121.69] blocked using bl.spamcop.net; Blocked - see http://spamcop.net/bl.shtml?12.252.121.69; from=<hashao@example.com> to=<wotan@victim.com> proto=SMTP helo=<aol.com> reject: RCPT from unknown[219.234.9.254]: 554 Service unavailable; Client host [219.234.9.254] blocked using bl.spamcop.net; Blocked - see http://spamcop.net/bl.shtml?219.234.9.254; from=<gorgo@dummy-host.example.com> to=<lindalu1@victim.com> proto=SMTP helo=<rambler.ru> reject: RCPT from unknown[166.104.200.92]: 554; Client host [166.104.200.92] blocked using bl.spamcop.net; Blocked - see http://spamcop.net/bl.shtml?166.104.200.92; from=<cbaoqiu@dummy-host.example.com> to=<vic@victim.com> proto=SMTP helo=<microsoft.com> reject: RCPT from host202-60.pool21759.interbusiness.it[217.59.60.202]: 554 Service unavailable; Client host [host202-60.pool21759.interbusiness.it] blocked; from=<tasminahmad@dummy-host.example.com> to=<pacgermany@victim.com> proto=SMTP helo=<mailserv> reject: RCPT from c-66-229-245-245.we.client2.attbi.com[66.229.245.245]: 554; Client host [66.229.245.245] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?66.229.245.245; from=<bcwekjfeg@example.com> to=<brad@victim.com> proto=SMTP helo=<c-66-229-245-245.we.client2.attbi.com> reject: RCPT from c-66-229-245-245.we.client2.attbi.com[66.229.245.245]: 554; Client host [66.229.245.245] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?66.229.245.245; from=<bcwekjfeg@example.com> to=<freekje@victim.com> proto=SMTP helo=<c-66-229-245-245.we.client2.attbi.com> reject: RCPT from flandre-1-81-57-169-89.fbx.proxad.net[81.57.169.89]: 554; Client host [81.57.169.89] blocked using bl.spamcop.net; Blocked - see http://www.spamcop.net/bl.shtml?81.57.169.89; from=<jwxplalp@hinmavzgv.example.net> to=<daemon@victim.com> proto=SMTP helo=<flandre-1-81-57-169-89.fbx.proxad.net> reject: RCPT from unknown[61.105.251.12]: 554 Service unavailable; Client host [61.105.251.12] blocked using bl.spamcop.net; Blocked - see http://spamcop.net/bl.shtml?61.105.251.12; from=<rosalia@faun.example.org> to=<jon@victim.com> proto=SMTP helo=<microsoft.com> reject: RCPT from ool-182f3f56.dyn.optonline.net[24.47.63.86]: 554 Service unavailable; Client host [24.47.63.86] blocked using bl.spamcop.net; Blocked - see http://spamcop.net/bl.shtml?24.47.63.86; from=<lippmann@example.org> to=<e.retsia@victim.com> proto=SMTP helo=<compuserve.com> reject: RCPT from mrdn-01-25.dialup.netins.net[207.177.98.90]: 504 <sss>: Helo command rejected: need fully-qualified hostname; from=<sss@example.com> to=<sssx@example.com> reject: RCPT from 13-156.ae.cgocable.ca[24.122.13.156]: 554; Client host [24.122.13.156] blocked using cbl.abuseat.org; Blocked - see http://cbl.abuseat.org/lookup.cgi?ip=24.122.13.156; from=<alrwv236h@example.org> to=<agodoy@victim.com> proto=SMTP helo=<13-156.ae.cgocable.ca> ...
I'd say the problem of 1918 leakage is a bigger concern.
Quite a big problem. Because some of the major backbones don't bother to filter that address space in the src of the packets, DDoS tools just love forging UDP packets with reserved space, which makes it nearly impossible to correctly track down where its coming from. A good example of this issue is with at least two of the AHBL nameservers run by the SOSDG (I have no idea what the other nameservers are seeing as they are not managed by us, but they are probably getting similar queries), someone from 192.168.1.20 is making dns queries for ip4r lookups under dnsbl.ahbl.org. Of course, the bogon filters stop it dead in its tracks, but, the fact that its getting through across Sprint, Cogentco, and similar isn't a good sign. Providers should be filtering at their borders both src and dst packets going to any of the reserved spaces. If they did, this wouldn't be an issue. Now, the better question is, what idiot is doing those dnsbl queries on our servers, and why haven't they noticed that the lookups don't work, and resolving in general probably isn't working? Who knows. < Side note: sorry about the weird quoting. OE-Quotefix is somehow barfing on your message specifically and crashing, so I had to turn it off > -- Brian Bruns The Summit Open Source Development Group Open Solutions For A Closed World / Anti-Spam Resources http://www.sosdg.org The AHBL - http://www.ahbl.org ----- Original Message ----- From: <Valdis.Kletnieks@vt.edu> To: "Roger Marquis" <marquis@roble.com> Cc: <nanog@trapdoor.merit.edu>; <spamtools@lists.abuse.net> Sent: Sunday, January 04, 2004 3:05 PM Subject: Re: example.com/net/org DNS records
Does anyone know why IANA has assigned NS and A records to the example.{com,org,net,...} domains? They even put up a website at the IP explaining RFC 2606.
because they are owned by the IANA.
* Why did they assign NSs and a valid IP to these invalid domains?
they are not invalid.
* Are they breaking the RFC by doing this?
Nope.
* Are they breaking anti-UCE filters by doing this? (yes)
Perhaps.
* Are they harvesting URLs and referrers?
Ask the current IANA.
* Will they next advertise routes for RFC 1918 addresses?
Perhaps. They do authorize authoritative DNS service for these blocks in the public Internet.
-- Roger Marquis Roble Systems Consulting http://www.roble.com/
--bill (one-time IANA jock, who set up the DNS for RFC 1918 space and the example domains)
Does anyone know why IANA has assigned NS and A records to the example.{com,org,net,...} domains? They even put up a website at the IP explaining RFC 2606. because they are owned by the IANA.
pedantic point: no, they are not 'owned' by anybody. they are *reserved*, and should not be used by anybody. randy
In a message written on Sun, Jan 04, 2004 at 05:51:40PM -0800, Randy Bush wrote:
pedantic point:
no, they are not 'owned' by anybody. they are *reserved*, and should not be used by anybody.
To be really pedantic, from http://www.faqs.org/rfcs/rfc2606.html: ] 2. TLDs for Testing, & Documentation Examples ] ] There is a need for top level domain (TLD) names that can be used for ] creating names which, without fear of conflicts with current or ] future actual TLD names in the global DNS, can be used for private ] testing of existing DNS related code, examples in documentation, DNS ] related experimentation, invalid DNS names, or other similar uses. I don't think I'm going out on a limb to suggest that names like example.com should be used by _everybody_ in documentation examples, least they pick something that might actually be used in the future. To wit, the point is not that they "should not be used by anyone", as you suggest, but rather, like RFC 1918 space, should be used by everyone for documentation, example configurations, and the like to insure they never conflict with a real service. The idea that if someone tries to use them they are presented with an intelligent error message that seeks to educate them is pleasing. -- Leo Bicknell - bicknell@ufp.org - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/ Read TMBG List - tmbg-list-request@tmbg.org, www.tmbg.org
-----BEGIN PGP SIGNED MESSAGE----- Leo Bicknell wrote:
In a message written on Sun, Jan 04, 2004 at 05:51:40PM -0800, Randy Bush wrote:
pedantic point:
no, they are not 'owned' by anybody. they are *reserved*, and should not be used by anybody.
To be really pedantic, from http://www.faqs.org/rfcs/rfc2606.html:
] 2. TLDs for Testing, & Documentation Examples ] ] There is a need for top level domain (TLD) names that can be used for ] creating names which, without fear of conflicts with current or ] future actual TLD names in the global DNS, can be used for private ] testing of existing DNS related code, examples in documentation, DNS ] related experimentation, invalid DNS names, or other similar uses.
I don't think I'm going out on a limb to suggest that names like example.com should be used by _everybody_ in documentation examples, least they pick something that might actually be used in the future.
To wit, the point is not that they "should not be used by anyone", as you suggest, but rather, like RFC 1918 space, should be used by everyone for documentation, example configurations, and the like to insure they never conflict with a real service.
The idea that if someone tries to use them they are presented with an intelligent error message that seeks to educate them is pleasing.
On topic of the 'example' internet thingies, use: 2001:db8::/32 for IPv6 documentation. If you make an example anywhere or like to tell how something works, use the above space. There is a draft in the queue but it is not there yet and the whois entry isn't there either. "but I need do show peering between TLA's and need 2x /32" then show it using /35's... does that matter that much in docs? :) FYI: http://www.apnic.net/info/faq/ipv6-documentation-prefix-faq.html Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / http://unfix.org/~jeroen iQA/AwUBP/jM0SmqKFIzPnwjEQKKjgCePaYqqgsp5tH/+JLXYBuPTzOihlwAniUJ RhCqAdQcn8g7CxZlhoQ3cHkV =uS0t -----END PGP SIGNATURE-----
On Sun, Jan 04, 2004 at 09:13:39PM -0500, Leo Bicknell wrote:
I don't think I'm going out on a limb to suggest that names like example.com should be used by _everybody_ in documentation examples, least they pick something that might actually be used in the future.
To wit, the point is not that they "should not be used by anyone", as you suggest, but rather, like RFC 1918 space, should be used by everyone for documentation, example configurations, and the like to insure they never conflict with a real service.
If you are going to insist on being really pedantic, get it right :) RFC1918 space is reserved for private use, not for documentation and example configurations. That's what 192.0.2.0/24 is for, see RFC3330. -- Colm MacCárthaigh Public Key: colm+pgp@stdlib.net
Does anyone know why IANA has assigned NS and A records to the example.{com,org,net,...} domains? They even put up a website at the IP explaining RFC 2606. because they are owned by the IANA.
pedantic point:
no, they are not 'owned' by anybody. they are *reserved*, and should not be used by anybody.
randy
Ok... IANA has paid the registration fees for those domains in the past, I have no idea what the current situation is. Now I know that paying for something does not always equate to ownership, but that is a common perception. as usual, YMMV. --bill
* Are they breaking anti-UCE filters by doing this? (yes)
How? They own example.com. If UCE happens to contain a forged sender of roble.com, would you consider that even remotely useful in a filter? Why should example.com be any different? they will likely never use the domain name, so probably wouldn't care if you feel the need to blacklist it explicitly, for that matter.
Roger Marquis Roble Systems Consulting http://www.roble.com/
-- Ray Wong rayw@rayw.net
* Are they breaking anti-UCE filters by doing this? (yes)
How? They own example.com. If UCE happens to contain a forged sender of roble.com, would you consider that even remotely useful in a filter? Why should example.com be any different? they will likely never use the domain name, so probably wouldn't care if you feel the need to blacklist it explicitly, for that matter.
Maybe NANAE will let y'all borrow one of the troll signs. [Attribution removed because my remark is not aimed at any one particular potser here.)
* Are they breaking anti-UCE filters by doing this? (yes)
How? They own example.com.
A) They don't own example.com and, B) this is the crux of the issue. IANA was not granted special privileges by RFC2606 nor do they have any more claim to these domains than Verisign does to unregistered domains or expired domains. Example.dom was placed in the pubic domain by a public and open RFC process. It seems that IANA has violated this process and in so doing exceeded the authority vested in them by their contract with DARPA (and the DOC?).
If UCE happens to contain a forged sender of roble.com, would you consider that even remotely useful in a filter?
Yes. Roble manages several email gateways for companies other than ourselves and we've found that rejecting invalid domains and senders is an indispensable component of spam filtering. Not only is it effective it is also 100% false-positive proof (so far). -- Roger Marquis Roble Systems Consulting http://www.roble.com/
On Sun, 04 Jan 2004 13:43:36 PST, Roger Marquis said:
Example.dom was placed in the pubic domain by a public and open RFC process. It seems that IANA has violated this process and in so doing exceeded the authority vested in them by their contract with DARPA (and the DOC?).
Erm. No, RFC2606 specifically says: 3. Reserved Example Second Level Domain Names The Internet Assigned Numbers Authority (IANA) also currently has the following second level domain names reserved which can be used as examples. example.com example.net example.org 4. IANA Considerations IANA has agreed to the four top level domain name reservations specified in this document and will reserve them for the uses indicated. In other words, they're IANA reserved, and you're permitted to use them for the purposes listed in the RFC.
A) They don't own example.com and,
Who says they don't? RFC never says IANA can or cannot "own".
B) this is the crux of the issue. IANA was not granted special privileges by RFC2606 nor do they have any more claim to these domains than Verisign does to unregistered domains or expired domains.
The RFC never stated "IANA cannot register these domains." It says IANA will _reserve_ the domains. Bottomline, as long as IANA "holds" the domain, stating its "reserved", RFC is complied. http://www.example.com says: "You have reached this web page by typing "example.com", "example.net", or "example.org" into your web browser. These domain names are reserved for use in documentation and are not available for registration. See RFC 2606, Section 3. " Good enough. I find it fully compliant to the RFC.
Example.dom was placed in the pubic domain by a public and open RFC process. It seems that IANA has violated this process and in so doing exceeded the authority vested in them by their contract with DARPA (and the DOC?).
Is that contract available in public domain? If so, have you read it? I clearly understand your frustration but let's not make assumptions.
If UCE happens to contain a forged sender of roble.com, would you consider that even remotely useful in a filter?
Yes. Roble manages several email gateways for companies other than ourselves and we've found that rejecting invalid domains and senders is an indispensable component of spam filtering. Not only is it effective it is also 100% false-positive proof (so far).
OK, bingo. This is a simple issue to fix. Configure your spam filter to reject spams sourced from example.* This is not hard, and much more productive and quickest to do on your mail server(s). -J -- James Jun (formerly Haesu) TowardEX Technologies, Inc. 1740 Massachusetts Ave. Boxborough, MA 01719 Consulting, IPv4 & IPv6 colocation, web hosting, network design & implementation http://www.towardex.com | james@towardex.com Cell: (978)394-2867 | Office: (978)263-3399 Ext. 170 Fax: (978)263-0033 | AIM: GigabitEthernet0 NOC: http://www.twdx.net | POC: HAESU-ARIN, HDJ1-6BONE
On Sunday, January 04, 2004 4:43 PM [GMT-5=EST], Roger Marquis <marquis@roble.com> wrote:
If UCE happens to contain a forged sender of roble.com, would you consider that even remotely useful in a filter?
Yes. Roble manages several email gateways for companies other than ourselves and we've found that rejecting invalid domains and senders is an indispensable component of spam filtering. Not only is it effective it is also 100% false-positive proof (so far).
But, it has to be done carefully. Our RHSBL (part of the AHBL) is based on this idea - but, we are extremely careful in what we block exactly. A single wrong block (aol.com for example) could have really bad side affects for anyone using the list. As such, the best way to use a domain style block is to try and only use it on the mainsleeze spammers for example, that spam from their (many) domains they own. We had to do this with topic's spammy domains in order to allow our users to keep getting messages from mailing lists hosted off of topica's main domain. Each type of blacklisting has to be carefully thought out, and implemented correctly. A combination of a DNSbl, a RHSbl, a whitelist, and something similar to spamassassin gives you the flexability to block alot of spam without needing to block everything outright. -- Brian Bruns The Summit Open Source Development Group Open Solutions For A Closed World / Anti-Spam Resources http://www.sosdg.org The AHBL - http://www.ahbl.org
On Sun, 4 Jan 2004, Roger Marquis wrote:
Does anyone know why IANA has assigned NS and A records to the example.{com,org,net,...} domains? They even put up a website at the IP explaining RFC 2606.
* Why did they assign NSs and a valid IP to these invalid domains?
There's already been a lot of discussion about why this is a good thing, so I won't reiterate it all. That web site gets roughly 5 million hits a week, so we believe that it's definitely providing a valuable educational service to the internet community.
* Are they breaking the RFC by doing this?
We don't believe we are, and certainly wouldn't intentionally take any action that violates the RFC's. The IANA is entrusted with safeguarding a lot of internet resources, and it's a responsibility that we take very seriously.
* Are they breaking anti-UCE filters by doing this? (yes)
This is an unfortunate side effect, but we believe that the user education benefits are worth the cost.
* Are they harvesting URLs and referrers?
We log the "standard" stuff that just about any other web site would, including URI's, referers, etc. As someone else pointed out, "harvesting" the URI's won't really provide us any benefit. As for the referers, if the community finds this problematic, I would have no problem turning it off. We don't release the data, and currently we're not doing anything with it other than logging it, so we wouldn't miss it if it went away. :) Hopefully this information is useful. If you have any further questions, please feel free to contact me. Doug -- Doug Barton General Manager, Internet Assigned Numbers Authority
On Monday 05 January 2004 11:46 am, Doug Barton wrote:
On Sun, 4 Jan 2004, Roger Marquis wrote:
* Are they breaking anti-UCE filters by doing this? (yes)
This is an unfortunate side effect, but we believe that the user education benefits are worth the cost.
As long as IANA isn't sending email using that domain, then it should be trivial for email admins to block anything claiming to come from that domain.
Doug
-- Donovan Hill Electronics Engineering Technologist, CCNA www.lazyeyez.net, www.gwsn.com
On Mon, 5 Jan 2004, Doug Barton wrote:
Does anyone know why IANA has assigned NS and A records to the example.{com,org,net,...} domains? They even put up a website at the IP explaining RFC 2606.
There's already been a lot of discussion about why this is a good thing, so I won't reiterate it all.
Thanks Doug. Are those discussions available on the net? If so could you post the URL? -- Roger Marquis Roble Systems Consulting http://www.roble.com/
On Mon, 5 Jan 2004, Roger Marquis wrote:
On Mon, 5 Jan 2004, Doug Barton wrote:
There's already been a lot of discussion about why this is a good thing, so I won't reiterate it all.
Thanks Doug. Are those discussions available on the net? If so could you post the URL?
The discussion I'm referring to is the one that happened on the NANOG list subsequent to your post. Doug -- Doug Barton General Manager, Internet Assigned Numbers Authority
participants (14)
-
bill
-
Brian Bruns
-
Colm MacCarthaigh
-
Donovan Hill
-
Doug Barton
-
haesu@towardex.com
-
Jeroen Massar
-
Laurence F. Sheldon, Jr.
-
Leo Bicknell
-
Randy Bush
-
Ray Wong
-
Roger Marquis
-
Suresh Ramasubramanian
-
Valdis.Kletnieks@vt.edu