Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!umich!samsung!brutus.cs.uiuc.edu!psuvax1!psuvm!CALSTATE!1GTLEJS From: 1GTLEJS@CALSTATE.BITNET (Ed Skochinski) Newsgroups: bit.listserv.nodmgt-l Subject: Re: :routtab tableformat for NJEF Message-ID: Date: 8 Feb 90 22:03:02 GMT Sender: Node Management Discussion Reply-To: Node Management Discussion Lines: 67 Approved: NETNEWS@PSUVM Gateway Michael Gettes wrote: > Very good. So, I argue for the removal of the table-format information > from the :routtab tag. Table format is not an issue if we create generic > tables such as the one created by pathalias. I argue for the continued > use of :routtab to have the originator and recipient fields for the > purposes of providing the generation of the generic table by network > services such as NETSERV (or other such needed processors). I could live with this. I'm taking fair advantage of the *current* :routtab definition. JES node numbers may be taken from existing tags, but the OFFSET "O=nn" most certainly is local information. Since there is this precedent of :routtab containing local information, I see no problem with NJEF needing local information. Without the precedent, I wouldn't be defending my position. I suppose I could insist, "If you forbid NJEF local parameters, then you *must* remove O=nn." Acceptance of this would be a Pyrrhic victory. It's just dumb luck that JES2's local part is cosmetically clean and NJEF is somewhat messy. Eric Thomas wrote: > Let's put the problem another way. Let's say that I'm the techrep of a > new node running software XYZ, which needs routing tables but which is > not supported by GENROUTS, and requires the specification of the colour > of the cable going from my communication controller to my modem in the > routing tables. > ... > And I would find it normal that the BITEARN > NODES specifications are not changed for my system, since it is not an > absolute requirement for the information to be there (that is > unfortunately not the case of JES node numbers), and since other sites > obviously do not care about the colour of my modem cables. How about this way: Let's say that software XYZ needs bizarre text strings, such as "ROUTE" in front of the destination node and neighbor node. And, I can determine this as side effect of the name of their networking software. I should find it normal that BITEARN NODES does not carry this information, and should not expect the routing table generator to be special-cased to handle this side effect, no matter how deterministic it might be. Other sites obviously do not care about the spelling and format of my configuration statements, so long as I keep up to date. Furthermore, a large percentage of the hosts on the network have this software, but their weighty presence is not sufficient to force a network supported program to special-case only the software with clout derived from their quantity. I should be VERY happy to receive a list containing only two columns of data: A destination node name and a neighboring node name to whom I can pass. Eric's argument is excellent support of the format-independent table proposed by Michael. However, GR creates configuration statements, not just a tailored network snapshot. NJEF sites have as much right to run-ready congiguration statements as do the rest. Eric Thomas writes: > To summarize, let's try to keep whatever is local local. We now treat :netsoft as informational only. This is obviously local data, let's remove it. If I read the descriptions correctly, tags :nodedesc, :machine, :system, and :remarkN are local. Keep them out of BITEARN NODES. I assume that the wars over inclusion of these tags are long since over. Why should we tolerate this local data, and at the same time forbid information which enhances the service provided to a member's site? Ed Skochinski Operating Systems Support The California State University