Subj : z1b link
To   : Ross Cassell
From : Carl Austin Bennett
Date : Sun Apr 15 2001 05:26 am

 RC> Perhaps, but is this vanity?

 CS> No.  MRVIA stats added.  I dont know what 3 Foxy used though so I 
 CS> cant say more.

 RC> I find it troublesome to even advocate the flags be used to denote 
 RC> any sort of reliability.

The only real reliability issue with *RVIA at this point is that the *RVIA set 
in some regions is badly incomplete. That's why I was surprised to see a 
listkeeper report fewer downlinks than could be read right off the nodelist.

If anything, "grep MRVIA nodelist.103" would report too few, not too many.

 RC> A. NODELIST only updates weekly, you gonna impose upon NC's to report 
 RC> routes? Will a NC have to report a pending change?

The requirement that a local net report changes already exists. Still there.

 RC> B. Will the NC be burned at the stake if s/he doesnt get a change 
 RC> listed in  time or at all for one reason or the other?

The NCs still have to account to their respective local nets for the accuracy 
of the segments. That political process is already in place and unchanged.

 RC> C. What if all nets, regions arent implementing this?

This creates the same situation as we have with the regional ROUTELST files; we 
have good info from some regions and problems in regions like R14 or R15.

There is no source that can provide us reliable info for a problem region. The 
zone list hides these problems by defaulting routes to the RC but is not a fix

If the nodelist is inaccurate (and at one point it was reporting more nodes in 
R14 than in R12) all of these lists show routes to nets which no longer exist.

 RC> D. Dead nets and nodes, still a problem?

If the NC is also NEC and goes AWOL, every list out there goes out of date.

It is up to the RC to verify periodically that the in-region NCs still exist.
It is up to the NC to verify that the nodes in his or her segment still exist.

In this region, a dead net can escape detection for a few weeks but not for a 
few months. I can't comment on other regions; maybe you could ask your RC?

 RC> E. What if a NC is doing his best in this area, but his nodes arent 
 RC> reporting to him up to date or accurate info?

A route to one individual node only gets missed entirely from the ROUTELSTs.

Only the RVIA flag can be used to identify these, and sysops who don't report 
changes to their own entries only have themselves to blame if last-known info 
of any kind is reported. In some cases (such as nodes switching from POTS to 
telnet-only without informing listkeepers) a node may be misidentified DOWN.

Any system is going to be limited by whatever data is input to it, but *RVIA 
does appear to solve a few problems that needed to be addressed.

The *RVIA flag accomplishes three things:
  1) It gives control over a net's info to the NC instead of allowing errors
     made by out-of-region sysops to corrupt this data (ask Ruth about this!)

  2) It provides all information which used to come from the various regional
     ROUTELSTs in a standardised and machine-readable format to which all
     Fidonet nodes have easy access without depending on a central listkeeper

  3) It provides a means to identify nodes with independent feed which would
     not be identified in the ROUTELSTs because they don't feed a whole net

With the ever-increasing quantity of Internet-based nodes, the number of 
independent feeds is increasing. There are two nets in-region (229 and 2401) in 
which both the NC and the majority of nodes are ION and *RVIA is often the only 
way to identify all of the links into such a network.

There is still one key limitation: the need for somewhere to list the top-level 
matrix connections. The length of a nodelist entry is limited to 157 characters 
and this may not be enough to list every possible route to a Tier1.

A complete *RVIA set (or a complete set of ten regional routelst's) therefore 
does not remove a requirement that a top-level matrix be provided separately.

--- Msged/LNX TE 06 (pre)
 * Origin: Pause-Cafe Kingston 613-549-5599 telnet:cafe.dyndns.org (1:249/116)

.