Ariel@RELAY.PRIME.COM (Robert Ullmann) (08/09/90)
Hi, [this message didn't seem to make it to the TCP-ISDN list, and wasn't sent to NameDroppers, so I am quoting the whole thing, instead of the usual excerpts] > Date: Wed, 08 Aug 90 14:38:22 +1000 > From: Bob <smart@mel.dit.csiro.au> > I think the general idea of the proposed draft RFC is excellent. > I would like to quibble at some details. > 1) The RT records are to be used by the network layer. Like > all network activity this should work without reference to > domain names. It seems more correct to make this an > extension of the in-addr.arpa domain > 17.128.in-addr.arpa. IN RT 10 sh.prime.com. > is a route to a whole class B network (128.17). Alternatively > 17.18.19.20.in-addr.arpa. IN RT 30 relay.prime.com. > is a route to a specific host. I did think about this. In my view, the domain system (at least in the Internet class) is all about binding FQDNs to attributes. The "pointer" zones are only a particular inverted index to the domain records. If the IP address exists, there should be a PTR record; if it exists, it should point to a valid FQDN, and (all) the other RRs can be placed there. I'm not terribly worried about the layer mixing: either way, we are already assuming that the IP (internetwork-layer) router is making a DNS (application-layer) request. Also: for a multi-homed host, there is no particular association between its IP addresses and the X25 or ISDN address(es): it is perfectly all right to call it with the "off-side" IP address. The other reason for binding name->(X.25/ISDN) is for protocols not involving IP at all; both SMTP and TP/IX are the particular examples I am interested in. > 2) The X25 and ISDN types should be network types parallel to > IN not parts of the IN network info. E.g. > Relay.prime.com. X25 A 311061700956 > ISDN A 150887929603217 003 In my view: IN is not a "network type". It is an Object Class, in this case the class of all objects known as "Internet Hosts". The information clearly belongs to the Internet class. > Records of the form > 31106700956.x25-addr.arpa. IN X25 x.y.edu > should mean that host x.y.edu will accept X25-over-IP calls > for X.25 address 31106700956 using some to-be-defined protocol > for running X.25 over IP. I would point out that CISCO have > such a protocol and might release it (my guess: they would > release it if there was a threat of some other protocol > becoming a standard). Interesting. Problem: either you have a very large, very flat, and *very* hard to administer zone; or you have to figure out how to delegate parts of the X.121 address-space. Any ideas? > Similarly for IN ISDN. Yes ISDN over IP could be used to provide > telephone/fax/whatever connectivity to workstations with IP > connectivity. It may not be as clearly desirable as IP over ISDN > but it is possible and whatever the theoretical difficulties I > suspect it would work fine in practice in many situations. Seems to me any given protocol (voice/fax/whatever) would best be run on TCP (or ISO TPn, or TP/IX-TP), then you could run (e.g.) voice/TCP/IP/ISDN everywhere instead of voice/ISDN. <grin> > 3) It is possible to imagine access to X25 and ISDN A records from > boxes which don't run IP. So it would be nice to define a protocol > for accessing the DNS over raw X.25 and raw ISDN networks. Since > the DNS can be accessed by UDP and TCP this shouldn't be hard. Quite so. Something I am prototyping. Basically, you call with PRID C0F66035 and use the TCP DNS encapsulation (16-bit count precedes each DNS packet, DNS packets do not correspond necessarily to X.25 L3 M-data sequences). On ISDN, you use X.25 bearer capability, and user-user setup element selecting X.244 (X.25 PRID/UDATA), in turn selecting C0F66035. (thus calls gated ISDN->PSDN or vice versa work properly) All of which might be the subject of a future RFC. This parallels the method of doing IP/ISDN on the switched service with user-user selecting X.244 PRID = CC, which also (theoretically) works across ISDN/PSDN gates. > Bob Smart <smart@mel.dit.csiro.au> Robert Ullmann Prime Computer