🚀 go-pugleaf

The UT System Office of Telecommunication Services is pleased to announce a
new and more robust method for maintaining the THEnet DECnet node database:
the THEnet Update Processor (TUP).  The concept behind TUP is very similar
to the Update Verification Processor used on BITNET.  Like the UVP, TUP
works by accepting electronic mail messages sent to a certain address,
THENIC::UPDATE or update@nic.the.net, and parsing them as a series of
commands which add, modify, or delete nodes and other information in the
THEnet nodes database.  The master database is no longer the flat ASCII file
THENET_NODES_FULL.COM, but is a set of three indexed files which contain the
information in a form which makes it much easier to manipulate. 
THENET_NODES_FULL.COM and THENET_NODES.COM can be generated from the
contents of these databases.

TUP defines three sorts of objects which it stores in its three indexed
files:  handles, areas, and nodes.  For those of you familiar with the
Internet concept of a handle, you'll be glad to know that a TUP handle is
the same sort of thing.  For those of you not familiar with the concept, a
handle is a short alphanumeric string which is assigned to a particular
person in order to represent that person, much like a username on a computer
system.  All the biographical information about a person is stored in that
person's handle entry.  All references to that person anywhere else in the
database are made with the handle.  This means that biographical information
needs to be updated in only one place, in the person's handle entry, and it
will take effect everywhere else in the TUP databases automatically.  A
handle entry contains the person's full name, employer, department, postal
address, voice and fax telephone numbers, and DECnet and Internet electronic
mail addresses.  Most of this information is optional, but the person's full
name, employer and department, voice telephone number, and DECnet mail
address are used in some of the reports generated by TUP, such as
THENET_NODES_FULL.COM.  A person may update the information in his or her
handle at any time.  The name of a person's handle is formed by taking the
person's initials and appending to them a numeric string used to make the
handle name unique.  For example, since my full name is Donald L. Nash, my
handle could be "DLN1".  For people who already have an Internet handle and
who need a THEnet handle, their THEnet handle can be made the same as their
Internet handle to minimize confusion (assuming that the requested THEnet
handle isn't already in use).

Handles are used for more than just concentrating all biographical
information in a central location.  All modifications to the TUP databases
are subject to access control, so any update job must begin by identifying
the person who is making the changes.  For those of you familiar with
BITNET's UVP, you know that this authentication is done based on the e-mail
address of the requestor.  This scheme does work, but it limits people to
sending in their updates from a specific account on a specific node.  TUP,
on the other hand, bases authentication on the requestor's handle, which
must be presented to TUP before any database modification commands are
allowed.  Each handle has a password associated with it, and a TUP user must
present this password along with the handle in order to be authenticated. 
Once a person is successfully authenticated, he may make changes to those
parts of the database to which he has access.  The exact form of the access
control will be explained shortly.

While it is understood that sending passwords in the clear in an electronic
mail message is not a very good idea, it was the only solution we could
think of which would allow TUP to be implemented quickly and would not make
it difficult to use.  It should be noted that BITNET has not solved this
problem either, and they've had more time to work on it that we have.  We do
have some ideas on how to solve this problem and suggestions are welcome. 
Since TUP is not due to go into production until January, we do have a
little bit of time to work on this.

The second sort of object known to TUP is the DECnet area, or more
precisely, a subset of a DECnet area.  The TUP area database contains an
entry for each DECnet area currently in use in THEnet, along with optional
starting and ending node addresses to allow subsets of areas to be
specified.  Each area entry contains a description of what the area is used
for or who it belongs to, and a list of up to eight handles for the people
who are responsible for this area.  Only people whose handles are listed in
the area entry are allowed to add nodes with addresses in that area. 
Further, any person who is listed as the contact for an area is implicitly
given permission to modify or delete any node in that area, regardless of
who is specified as the contact for that individual node.  Finally, area
contacts may make some changes to the area entry itself.  They may change
the descriptive text and the contact list associated with the entry, but
they may not change the area number or the starting and ending node
addresses.  In other words, they cannot change or extend their authority. 
Lastly, only staff members at OTS can add or delete area entries, so new
area requests must be done via some means other than TUP.  This restriction
also applies to the creation and deletion of handles, but since none of
these operations are expected to happen very often, this will hopefully not
be seen as a shortcoming.

The last sort of object known to TUP is the DECnet node.  Node entries
contain the node's name and DECnet address, CPU type, operating system, and
some descriptive text.  Nodes may have their own contact list as well,
although this is not required since all the contacts for the area containing
this node are implicitly made contacts for the node.  Node contacts may
change the CPU type, operating system and descriptive text for a node.  Only
area contacts may change the address of a node.  Nodes may not be renamed,
they must be deleted and a new node created.

The most important feature of TUP is its ability to make checks on a node
entry before adding it.  Nodes with names which are not valid DECnet node
names or whose names already exist in the database will not be added.  Also,
TUP detects an attempt to use a DECnet address which is already in use and
will disallow the request.  Finally, all handles listed as contacts for a
node are looked up in the handle database to make sure they exist before
they are added to the node's entry.  Sanity checks are also performed when
entries in the area and handle databases are added or modified.  Syntax
errors also cannot be introduced into the database as they can now, since
the mail message read by TUP is parsed by a command language (which was
written using the VMS callable CLI routines).  Any syntax errors in the mail
message will be detected by the CLI.

In addition to being able to add, modify, and delete information from the
databases, TUP also allows objects to be displayed in a variety of formats. 
When an update job is mailed in to TUP, TUP will process the job and mail
back a log of the job's execution back to the sender.  Information requested
from the database will be included in this job log. TUP can also generate
new versions of the THENET_NODES_FULL.COM and THENET_NODES.COM files and
mail them to the requestor.

Here is a sample TUP update job:

authenticate dln1 junkmail
add node thenic 19.213 /contact=dln1 -
    /description="Texas Higher Education Network Information Center" -
    /cpu=vax -
    /opsys=vms
modify node thenic /comment="Don lives here!"
show node thenic/format=full
show area 19 /format=full
show handle dln1 /full

It should be mostly self-explanatory.  Since the command language was
written using the VMS callable CLI routines, everything not in quotation
marks is converted to uppercase during processing.  The AUTHENTICATE command
is used to establish the identity of the person submitting the job, in this
case "DLN1".  The password for "DLN1" is "JUNKMAIL".  TUP passwords have the
same syntactic restrictions as VMS passwords: they are limited to uppercase
letters, digits, the dollar sign, and the underscore, and can be no more
than 32 characters long.

The ADD NODE command adds a node named "THENIC" with an address of 19.213 to
the node database.  The only contact for THENIC is DLN1; THENIC is described
as the THEnet Network Information Center, and it is a VAX running VMS.

The MODIFY NODE command modifies the node just added to specify the comment
that Don lives there.

The SHOW NODE command displays the entry for node THENIC.  The /FORMAT=FULL
qualifier indicates that all available information should be displayed. 
There are four other formats available, depending on the need at hand.

The SHOW AREA command shows the entry for area 19, and again the
/FORMAT=FULL qualifier indicates that all available information is to be
displayed.  There are two other formats available as well.

The SHOW HANDLE command displays the entry for handle DLN1.  There is no
/FORMAT qualifier because there are only two formats, /FULL and /NOFULL.

Here is the log file which was produced by the job:

%DDU-I-NOTAUTHENT, not currently authenticated
%DDU-I-NOMODCMD, database modification commands disabled


authenticate dln1 junkmail
%DDU-I-AUTHSUCCESS, authentication succeeded, modification commands enabled
-DDU-I-AUTHENTAS, authenticated as DLN1


add node thenic 19.213 /contact=dln1 -
    /description="Texas Higher Education Network Information Center" -
    /cpu=vax -
    /opsys=vms
%DDU-I-ADDNODE_OK, node THENIC added


modify node thenic /comment="Don lives here!"
%DDU-I-MODNODE_OK, node THENIC modified


show node thenic/format=full
	Node:		THENIC
	Address:	19.213
	Created at:	 5-NOV-1992 10:35:13.13 by DLN1
	Modified at:	 5-NOV-1992 10:35:13.19 by DLN1 (1)
	Flags:		None
	Contacts:	DLN1
	CPU:		VAX
	Oper. System:	VMS
	Description:	Texas Higher Education Network Information Center
	Comments:	Don lives here!

show area 19 /format=full
	Area:		19
	Start range:	1
	End range:	1023
	Created at:	14-OCT-1992 16:09:23.98 by DLN1
	Modified at:	 5-NOV-1992 10:30:46.69 by DLN1 (7)
	Flags:		None
	Contacts:	ABM1, DLN1
	Description:	University of Texas at Austin
	Comments:	

show handle dln1 /full
	Handle:		DLN1
	Created at:	15-OCT-1992 11:56:43.04 by DLN1
	Modified at:	 5-NOV-1992 10:32:47.17 by DLN1 (9)
	Flags:		
	Personal Name:	Donald L. Nash
	Title:		Networking System Specialist
	Institution:	University of Texas System
	Department:	Office of Telecommunication Services
	Mailstop:	
	Address:	Service Building Room 319
	City:		Austin
	State:		TX
	Zip Code:	78712-1024
	Country:	US
	Telephone:	(512) 471-2419
	Fax Phone:	(512) 471-2449
	DECnet Mail:	THENIC::DON
	Internet Mail:	D.Nash@utexas.edu


%DDU-I-DONE, Completed with 0 warnings, 0 errors, and 0 severe errors.

Again, this should be mostly self-explanatory, so I'll only mention a few
things here.  First, note that a creation and a modification time are kept
for each entry, and that the handle of the creator and most recent modifier
are also recorded.  The number in parentheses after the modification time is
the number of times this object has been modified since it was created.

Second, note that there are Flags fields for all three types of objects. 
However, the contents and use of these fields are currently undocumented and
reserved for future use.

Finally, you probably noticed that the facility name for all the messages in
the log file is "DDU".  This is short for "DECnet Database Utility", which
is the engine at the heart of TUP.  DDU itself has no concept of THEnet in
particular and can be used without modification to manage node databases for
other DECnet networks.

Rather than go into a detailed description of all the DDU commands, I'll
leave that to the on-line help text.  You can log in interactively to the
UPDATE account on THENIC and use DDU that way.  You won't be able to make
any changes that way (since it would bypass the audit trail kept by TUP),
but you can browse the database and read the help text.  The help text is
presented using the standard VMS help facility, so you shouldn't have any
trouble figuring it out.

The databases are not yet populated with the current contents of
THENET_NODES_FULL.COM.  This procedure will take some time, so it will
probably be mid or late November before all the information is available. 
If you are listed as a node or area contact in THENET_NDOES_FULL.COM, you
will automatically be issued a THEnet handle.  If you already have an
Internet handle, then your THEnet handle will be the same as your Internet
handle.  You'll need to send me mail to find out how to get your password.

Once all the information has been put into the databases, we'll be ready to
try some field testing.  Most of TUP has already been tested, and I'm fairly
confidant that it will work as advertised.  However, more extensive testing
can't hurt, and I'd like some feedback on ways to improve it.  I've set up a
MAILSERV-based mailing list called info-tup@nic.the.net and THENIC::INFO-TUP
for discussions about TUP during the field testing.  If you want to
participate in the field test, you can join the list by sending the
following command in an e-mail message to mailserv@nic.the.net or
THENIC::MAILSERV:

subscribe info-tup

Be sure to put this in the message body, not in the Subject line.  I'll send
mail to info-tup once all the data is in the database.

If you are a THEnet node or site administrator, then you are encouraged to
participate in the field test.  TUP was written as much to ease your burden
as it was to ease ours, so your input on its usefulness is important.

Oh yeah, one more thing.  Once TUP goes into production,
THENET_NODES_FULL.COM will still be issued once a month, although it will be
possible to request intermediate versions which reflect all changes since
the previous version.  However, we make now guarantees on the consistency or
correctness of such intermediate versions.  As bullet-proof as we hope TUP
will prove to be, we still plan on shutting it down for a few days at the
end of the month in order to perform manual consistency checks on all the
data before issuing a new version of THENET_NODES_FULL.COM.  Once we firm up
a procedure for this, we'll announce it to the THEMGR mailing list.

Finally, if you have any questions at all about TUP, send them to the
info-tup list.  I'm already on that list, so I'll see them.

                                ++Don Nash

Internet:  D.Nash@utexas.edu    The University of Texas System
THEnet:    THENIC::DON          Office of Telecommunication Services