david@ms.uky.edu (David Herron -- One of the vertebrae) (11/12/89)
In article <1810003@hpiag0.IAG.HP.COM> laubach@hpiag0.IAG.HP.COM (Mark Laubach) writes: >We are looking at the feasibility of submitting BITNET host >information into the uucp map project data. Note that this is not a >promise just an intent to look into it. Stay tuned for this. I've sent the following to Mark privately but I also thought it might be useful to have some public comment on it. Note that in my old job back "home" in KY, I ran a gateway between UUCP & BITNET and also was a map coordinator. Both are former duties but even though my current job doesn't let me hack on e-mail very much I'm very interested in the subject .. Anyway, the suggestions for coordinating between Usenet & BITNET: uhm ... technically it'd be very simple to push bitnet site data into the Usenet maps. There's already a node list available, it'd be a simple matter to make the following sort of file BITNETGATE psuvax1, ukma, husc6, etc BITNETGATE ukma.bitnet, psuvax1.bitnet, cunyvm.bitnet, etc the hard part is to do it right. Each of the gateways are close to particular parts of each network (the UUCP net & BITNET). That is, what should be done is to come up with some weights between each of the gateways and all the bitnet machines. That is, take ukma as an example. It's close to the branch of BITNET "south" of Ohio State. All those sites would have a fairly low weight and as you go beyond Ohio State the weight should increase. Especially beyond the Oh.St. -> PSU -> CUNY links which are chronically overloaded. It'd be tempting to try a simple approach of "each hop on the network costs so much in 'weight'". But some links are chronically crowded and it'd be better to place a high weight for traversing that edge. Each of the other gateways has their own areas of BITNET they could service well. The same holds true for the BITNET->UUCP direction, ukma (again) has lots of UUCP links on the east coast and some of those have good links to other parts of the country but it's not as direct as it could be. version 2 ukma psuvax1.bitnet(weight), cunyvm.bitnet(weight), etc psuvax1 ukma.bitnet(weight), cunyvm.bitnet(weight), etc alias entries should also be made for bitnet sites which have Official Domain Names. ukma.bitnet=g.ms.uky.edu psuvax1.bitnet=psuvax1.psu.edu cunyvm.bitnet=cunyvm.cuny.edu etc. NOTE: I cannot offer ukma's services as an official gateway since I no longer work there. I don't know of they'd be interested, they have enough problems already internal to the site without adding in problems from the outside. -- <- David Herron; an MMDF guy <david@ms.uky.edu> <- ska: David le casse\*' {rutgers,uunet}!ukma!david, david@UKMA.BITNET <- <- New official address: attmail!sparsdev!dsh@attunix.att.com
davecb@yunexus.UUCP (David Collier-Brown) (11/13/89)
david@ms.uky.edu (David Herron -- One of the vertebrae) writes: | technically it'd be very simple to push bitnet site data into | the Usenet maps [...]| | the hard part is to do it right. If there's a published or measurable metric on the speed, capacity or average load on the various links, one can map that to either usenet "HOURLY+HIGH" or internet preference values, with a commensurate bound on error. The hard part is getting the data (;-)), not reducing it. --dave (bitnet wizards, where are you when I need you) c-b -- David Collier-Brown, | davecb@yunexus, ...!yunexus!davecb or 72 Abitibi Ave., | {toronto area...}lethe!dave Willowdale, Ontario, | Joyce C-B: CANADA. 416-223-8968 | He's so smart he's dumb.
rsalz@bbn.com (Rich Salz) (11/15/89)
I do not think it is worthwhile to put BITNET host lists into the UUCP mapping project. If some BITNET sites have NNTP links or UUCP connections, then okay. Otherwise, what's the point? Why flood the net with site listings -- that's what domains are for. /r$ -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. Use a domain-based address or give alternate paths, or you may lose out.
laubach@hpiag0.IAG.HP.COM (Mark Laubach) (11/16/89)
I'm not sure of the feasibility of putting all the BITNET nodes into the uucp map database, its about 2990 last time I looked. So it seems that the .bitnet kludge is the way to go for the moment. What we are looking at is getting all the bitnet hosts registered into the domain nameservice as soon as possible as the better solution. Mark
honey@citi.umich.edu (Peter Honeyman) (11/17/89)
Mark Laubach writes: >I'm not sure of the feasibility of putting all the BITNET nodes into >the uucp map database, its about 2990 last time I looked. So it seems >that the .bitnet kludge is the way to go for the moment. What we are >looking at is getting all the bitnet hosts registered into the domain >nameservice as soon as possible as the better solution. > >Mark it's feasible -- from about 1983 to 1985, i included bitnet data in my pathalias runs. i stopped when i got bored with picking out the name collisions. it might have been different if my machine had itself been a bitnet node. it did help me debug pathalias, though, by artificially swelling the input. how about the dual question: should uucp map data be included when running pathalias for bitnet nodes? hi mark. peter
davecb@yunexus.UUCP (David Collier-Brown) (11/20/89)
>Mark Laubach writes: | I'm not sure of the feasibility of putting all the BITNET nodes into | the uucp map database, its about 2990 last time I looked. So it seems | that the .bitnet kludge is the way to go for the moment. What we are | looking at is getting all the bitnet hosts registered into the domain | nameservice as soon as possible as the better solution. I'd venture to suggest that the .bitnet (and .uucp) kludge might be turned into a **way** of getting the hosts registered into the domain nameservice world: 1) have the bitnet registry use someone's bitnet->dns format translator to generate a set of nameserver files for the pseudo-domain .bitnet [I saw one once...] 2) [very optionally] provide a nameserver for .bitnet 3) punt the internet-compatible information back to the sites, so that they can run local nameservers with the real data (for those sites who interoperate with the internet) 4) collect the forms used to sucessfully register a site [I'm sure there is at least one] or subdomain in the internet, and generate a template. 5) generate a pre-potted registration form for each site from the template, and fire it back to them. Everybody wants to avoid work. Everybody wants someone else to do it. A registry has the information to do things once, rather than requiring each site to do/redo it. If site who have done difficult tasks provide their software to registries, the registry has at least the chance to do the common part once for all the sites, and leave them with only the site-specific tasks. If the sites welcome the registry making their life easier, then good. If not, eventually they'll fall out of communication with the rest of the world, and the new management will play catchup for a while... --dave (I'm lazy, but I'd fill out *part* of a registration form) c-b -- David Collier-Brown, | davecb@yunexus, ...!yunexus!davecb or 72 Abitibi Ave., | {toronto area...}lethe!dave Willowdale, Ontario, | Joyce C-B: CANADA. 416-223-8968 | He's so smart he's dumb.
rsalz@bbn.com (Rich Salz) (11/21/89)
In <5266@yunexus.UUCP> davecb@yunexus.UUCP (David Collier-Brown) writes: > 1) have the bitnet registry use someone's bitnet->dns format > translator to generate a set of nameserver files for the > pseudo-domain .bitnet [I saw one once...] > 2) [very optionally] provide a nameserver for .bitnet This won't work. The folks at the NIC will not register a .BITNET nor a .UUCP domain. To quote the people there (I can't find the email I got, so I don't want to put a name to it): Registering a .UUCP domain makes as much sense as changing your phone number based on who your carrier is. -- Please send comp.sources.unix-related mail to rsalz@uunet.uu.net. Use a domain-based address or give alternate paths, or you may lose out.
davecb@yunexus.UUCP (David Collier-Brown) (11/21/89)
In <5266@yunexus.UUCP> davecb@yunexus.UUCP (David Collier-Brown) writes: | 2) [very optionally] provide a nameserver for .bitnet rsalz@bbn.com (Rich Salz) writes: | This won't work. The folks at the NIC will not register a .BITNET nor | a .UUCP domain. To quote the people there (I can't find the email I | got, so I don't want to put a name to it): | Registering a .UUCP domain makes as much sense as changing | your phone number based on who your carrier is. Thats why its very optional (:-)). Alas, this reasonable decision seems a stumbling-block in the way of sites trying to become part of a more sane world: it is very non-obvious to a small private site how to become part of a domain, who is in charge, how to interpret the forms required, etc, etc, ad infinitum. Part of the problem is that they can't just change domain from .uucp (a psuedo) to .yxzzy.com (a real), but instead have to become real in one giant step. Ok, we can either 0) leave it lie, 1) change the rules to make it easier, 2) get someone else to do the work (well, most of it). I really don't like 0: if it were a conscious policy, it would be a policy of exclusivity. As it is, it merely has the effect of one! Therefor I'd vote for 3, with 2 iff the domain were time-limited. --dave (variously dave@lethe.uucp, davecb@Nexus.YorkU.CA, DAVECB@YUORION.BITNET, and once upon a time "David R. Brown"@HI-Multics.ARPA) c-b -- David Collier-Brown, | davecb@yunexus, ...!yunexus!davecb or 72 Abitibi Ave., | {toronto area...}lethe!dave Willowdale, Ontario, | Joyce C-B: CANADA. 416-223-8968 | He's so smart he's dumb.
jqj@rt-jqj.stanford.edu (JQ Johnson) (11/22/89)
It is often suggested that sites on bitnet register domain-style names under a .BITNET domain, but the reply is always that the NIC will not accept such a top level domain. Perhaps it would be appropriate to register all BITNET sites under the BITNET parent organization? Thus, we might have DNS addresses such as "site.cren.org" and a CREN.ORG domain administered by the CSnet organization. Or perhaps a CREN.NET or even CS.NET? Alternatively, the CSnet folks could do with BITNET what they did with CSnet years ago and manage a bunch of 2nd-level domains, one for each BITNET site. JQ Johnson voice: 415-723-3078 Manager, Special Projects Internet: jqj@jessica.stanford.edu Networking and Communications Systems Pine Hall Rm 125-A Stanford University Stanford, CA 94305-4122
dennis@gpu.utcs.utoronto.ca (Dennis Ferguson) (11/23/89)
In article <6920@portia.Stanford.EDU> jqj@rt-jqj.stanford.edu (JQ Johnson) writes: >It is often suggested that sites on bitnet register domain-style names >under a .BITNET domain, but the reply is always that the NIC will not >accept such a top level domain. Perhaps it would be appropriate to >register all BITNET sites under the BITNET parent organization? Thus, >we might have DNS addresses such as "site.cren.org" and a CREN.ORG >domain administered by the CSnet organization. Or perhaps a CREN.NET >or even CS.NET? Far be it for me to put words in the NIC's mouth, but what is often missed is that UTORVM1.BITNET isn't really a name at all, not in the same sense as VM.UTCS.UTORONTO.CA. "UTORVM1" is an NJE network level address, it is used by the networking software on bitnet machines for routing purposes. Its nearest functional analogue (and a pretty good match in terms of function, at that) for hosts on an IP network would be something like 128.100.63.2.INTERNET. I think the reason the NIC won't register .BITNET (and shouldn't register CREN.ORG or CREN.NET to be used for the same purpose) is about the same reason they don't register a .INTERNET domain with the usage above. Or, going at it another way, the University of Toronto is a member of NetNorth, which I guess makes this a BITNET site. Should we then register all of the hosts here as something.BITNET? No, say you, only the ones that are attached to the NJE network (since, implicitly, "something" is not just a name, it must be an NJE network address). Similarly, there are lots of machines which wouldn't qualify for a name of the form 128.100.63.2.INTERNET, either. Yet pretty well all machines here can make use of names with .toronto.edu or .utoronto.ca on the end, since these names carry distinctly different (and more generally useful) semantics. I don't think CREN.ORG, or CREN.NET would necessarily make the NIC happier, unless machines which didn't have NJE network connections could be registered in these domain as well. The latter is the key objection to .BITNET, I think, not so much that it is a top level domain. Dennis
laubach@hpiag0.IAG.HP.COM (Mark Laubach) (11/23/89)
| It is often suggested that sites on bitnet register domain-style names | under a .BITNET domain, but the reply is always that the NIC will not | accept such a top level domain. Perhaps it would be appropriate to | register all BITNET sites under the BITNET parent organization? Thus, | we might have DNS addresses such as "site.cren.org" and a CREN.ORG | domain administered by the CSnet organization. Or perhaps a CREN.NET | or even CS.NET? We haven't looked into creating a cren.net domain yet. There is already a cs.net domain. We may be able to do something under a domain and provide CNAMES to the official name. I think the NIC would prefer to see us register name under the appropriate subdomain under .com or .edu for the entity in question rather than bury it under a single domain. | Alternatively, the CSnet folks could do with BITNET what they did with | CSnet years ago and manage a bunch of 2nd-level domains, one for each | BITNET site. It makes a lot more sense for us to register each organization under its own .edu or .com subdomain, to run these from a few servers on the Internet (eg. sh.cs.net), and to provide MX records to the appropriate INTERBIT gateway machines (e.g. cunyvm.cuny.edu). Mark