Release 1.7d of LISTSERV will introduce support for the "nodename change" tags (':oldnode.' and ':newnode.'), to make name change, consolidation (several small machines -> one big machine) and deletion of nodes easier for list owners. What I have implemented does not correspond exactly to the formal specifications, for reasons you will understand later. Since I don't think these tags have ever been used (read, they have never appeared in BITEARN NODES as far as I know), it is not too late to update the specifications. In any case, the NIC and NCC should definitely review the verification rules they might have for these tags and make sure that a procedure exists to prevent abusive use. LISTSERV attempts to detect the obvious cases, but it can only go so far. NEWTAGS DESCRIPT defines a ':oldnode.' tag which one may put in the entry of a node which has replaced, or is about to replace, the node in question. That is, one would code ':node.NEW :oldnode.OLD' to tell the world that node OLD has become or is going to become node NEW. OLD must be a NJE nodeid, and may or may not be present in BITEARN NODES; if it is present, it must contain a ':newnode.NEW' tag (see below). LISTSERV recognize the ':oldnode.' tag and accepts more than one old nodeid. This is necessary to make it possible to merge several machines into a single node; I would like the specifications to be extended to allow this. If the "old node" is not in BITEARN NODES, LISTSERV replaces all occurences of the old node with the new node in mailing list subscriptions, AFD, FUI and password files. If the "old node" is still there but does not have a reciprocal ':newnode.' tag, or if several nodes claim the same "old node" (which the specifications should clearly disallow), LISTSERV throws away the entry and Eric Thomas posts yet another unprofessional message to NODMGT-L, as this should in principle never happen. If the old node still exists and has the reciprocal tag, LISTSERV ignores it and only processes the ':newnode.' tag (see below). NEWTAGS DESCRIPT defines a ':newnode.' tag which one puts in the entry of a node which is going to be deleted and replaced with the node in question. This must be an NJE nodeid, it must exist and there must be a reciprocal ':oldnode.' tag in the entry in question. LISTSERV accepts either an Internet hostname or a NJE nodeid in this tag. In the case of a NJE nodeid, the cross-verifications described above are performed and the ill-worded message is posted in case of failure, or if more than one hostname is specified. For Internet hostnames LISTSERV has no way to check anything, which is why the NIC/NCC's should check these tags manually. LISTSERV performs the same one-time change to mailing lists et al as described above and, in addition, automatically translates the origin of future incoming commands (and the parameters to most list owner commands), in order to prevent new entries with the old nodename from being added anywhere. This is particularly important in the case of Internet hostnames, which will not have the opportunity to go through another "cleanup" operation once the node is deleted - the new name is not in BITEARN NODES and thus cannot have a ':oldnode.' tag. LISTSERV ignores any ':internet.' tag in the entry of a NJE node with a ':newnode.' tag, in order to avoid internal complications. Theoretically, LISTSERV could solve these problems by internally moving the tag to the entry of the new node. This however raises the issue of what the proper behaviour should be if the new node also has its own ':internet.' tag. In practice, there are only two cases: 1. Node A is being renamed to node B, same machine. The ':internet.' tag should be moved to the entry of node B with the update that adds the ':newnode.' tag; this has to be done sooner or later, anyway. 2. The node is going away, or is being merged into a machine with a different Internet address. In that case the ':internet.' tag is no longer needed, as all records with NJE nodenames will be gone and records with Internet addresses will match directly; there no longer is a NJE nodeid the users can send commands from. IMPORTANT: This is a BITNET node deletion and renaming facility, not a "force all users from my node to use Internet addresses even if they don't want to because I say so" facility. Once you place the ':newnode.' tag in BITEARN NODES, there is no way for users to issue commands under the old address. There is no point in cleaning up all files one month before the deletion if you allow users to re-add obsolete entries during the month in question. If the new address is an NJE address, all requests will be processed under that name, and you have to consider whether this is acceptable in case the old and new nodeids are not yet the same physical machine. If the new address is an Internet address, the users no longer have an NJE address and have to use mail to order files and so on. Think twice before you use that tag for purposes it was not meant to have. Eric