On Sat, 26 Nov 2011 12:05:30 +0100, you wrote: networks. "Ownership" of area 1 may possibly have ego involved though I doubt that Johnny would care much. That's not our case. We just picked area 1 because it was the most "natural" choice. At first many of us didn't bother about DECnet at all and choose the first available value, i.e. 1.1. Then, when we started dreaming and thinking about a network, we started choosing address ranges in the 1.1 to 1.1023 range: one location from 1.1 to 1.9, another from 1.10 to 1.19, and so on. Each location (not always a physical one) was assigned to an administrator, and when that administrator filled its ten-addresses range, it received an additional one, not always contiguous to the previous. When the network became reality we implicitly choose to keep that numbering standard. We have also a few exceptions: the first was our Simh VAX/VMS V4.7 node that earned 1.666 because was evil to set up to our needs; the other is 1.1010 for the TOPS-10 node which also got DIECI as its node name (because dieci is the italian word for ten: compare it to decem in latin). There was a time when we considered changing our area number to 39 (the international dial code for Italy), but then there was really no need to do that and some members of our network are somewhat difficult to reach and speak with, so we would have ended with a mixture of areas 1 and 39, and that led to the cancellation of the renumbering project. When you, Hans, renumbered your systems, you were just one single person renumbering his personal nodes, under your direct control. We are in a situation which is more like asking the whole HECnet (or a major part of it) to change numbers. In another message on this thread I have posted a link to our node list. In that list there is a column showing the administrator nickname for every node. Well, that column does not tell the real story: there is a good number of nodes administered by one person, but physically located remotely from that person. Some nodes are active, but some others are switched off and do come online from time to time, without prior advice and it's not so easy to tell the relevant people to remember not to come online without prior intervention from some of us in order to change the DECnet address. So, go figure what would happen if someone comes online with e.g. the MIM address. What I've read about the "enhancements" to the bridge program is yet another matter. First off, it ain't called bridge for nothing: like any layer 2 bridge the program moves packets between ports and is transparent to both the content of the datagrams and the functionality of the protocol. Including DNS like functionality violates that rule. In my opinion, if anyone wants a central name repository for DECnet please upgrade to DECnet phase V. Which is my way of saying that I'm not too fond of this "enhancement"... I think you have misunderstood our DNS functionality. Our bridge just tries to resolve bridge endpoint IP addresses, but it is completely DECnet transparent, i.e. it does not and never did try to resolve DECnet node names into DECnet addresses. That's a service specific to DECnet Phase V, as you correctly appear to suggest. If our bridge does not receive anything (that is neither data nor even a hello packet) from an endpoint defined as dynamic, after a certain amount of time it tries to resolve again the hostname of that endpoint only. Because our bridges are transmitting and receiving most of the time, the resolve routine gets called quite seldom, so the delay issues explained by Johnny may be encountered as seldom as an IP address change, and we consider it a honest "price" to pay to have automatic dynamic IP addresses working. Bye, G. P.S. please, forgive any syntax or grammar error: I'm not English native.