At Thu, 17 Mar 2016 11:24:57 +1100, Mark Andrews wrote: > In message <20160316235134.gi1...@mx2.yitter.info>, Andrew Sullivan writes: > > > > I'm apparently having a hard time reading this month :-/ But your > > point makes the problem yet worse, since there's no sense that in > > the CS net class here the RDATA of an A record is a host address. > > I suppose that, since it's in 882 (which is obsoleted) that > > doesn't matter.
RFC 973 deprecated the CS class. > > But in CH according to the definition it's not just a host > > addressm but "a domain name followed by a 16 bit" address. (Maybe > > that actually means that the domain name is not in the RDATA. Since > > I'm having so much trouble reading this month, it's probably better > > that I not form an opinion.) > > RFC 1034 has: > > Similarly we might see: > > XX.LCS.MIT.EDU. IN A 10.0.0.44 > CH A MIT.EDU. 2420 >From which point people with sufficiently long memories can probably tell you whose fault this is. PVM and I came up with the CH class A RDATA layout over lunch one day in 1985 when he happened to be visiting LCS. Chaosnet is strictly a LAN protocol (well, OK, if anybody had ever actually implemented anything using IP protocol number 16, it would have been an Internet protocol running somewhere around OSI layers 4+5, but I digress), so the idea was that the RDATA contains a DNS name naming the LAN and a 16-bit address naming the node on that LAN. We already had CS A RRs as a precedent for class-specific RDATA, so we just followed that. This was long enough ago that Chaosnet was in much wider use within MIT than TCP/IP, and it was not yet a foregone conclusion that the Internet would grow to subsume all other networking technologies on the planet. So we were trying to plan ahead. Then stuff happened. MIT's Chaosnet ended up sticking with host tables until we shut it off, so we never did implement this in JEEVES or CHIVES. Symbolics may have gotten as far as using CH A RRs as one of the many inputs to their Namespace system, but that was pretty late in their corporate life cycle, so I doubt many users ever saw it in the wild. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
