Please mail comments/suggestions on:
- content to the Chair of the working group.
- format to webmaster _at_ ripe _dot_ net.
Netnews-WG meeting RIPE-36
chair: Dave Wilson
scribe: Felix Kugler
* mailing list: netnews-wg _at_ ripe _dot_ net, subscribe at majordomo _at_ ripe _dot_ net
* Agenda bashing: added RIPE NCC workplan 2001
Review of the RIPE-35 minutes
NHNS presentation (Daniel Diaz)
NHNS is a new approach to solve the newsgroup synchronisation problem.
* 10 hierarchies covered. Still waiting for more maintainers to join
* info source: http://nh.nhns.net, currently hosted at satec.es.
new achievements since last meeting:
* newssync script replaced innsync
o includes patches from Oli Osvaldsson
o now also supports bCandid software (formerly Highwind), i.e.
cyclone, typhoon, twister,...
o plans to support diablo, but this needs volunteers whith diablo
experience. None found in the audience
* new update scripts (see below!)
* new face for NHNS official site nh.nhns.net
* new statistics tool
During the first pilot phase, a separat inofficial DNS tree was used and
all TLHs were stored under the usenet. domain. Dedicated BIND servers had
to be setup with non-standard configurations. The final integration into the
standard DNS tree has now been decided!
* usenet.int could not be registered by Elmar Bins
* nhns.net registered by Dave Wilson, it is now available for NHNS
* Daniel Diaz to update all scripts and documents to reflect new
* audience decides to use nhns.net to go ahead; nh.nhns.net is the new
web server, TLHs to be stored under usenet.nhns.net !
Quality of NHNS data
* update date has to be coded into the zone files serial number in the
* this feature allows to write a simple script to verify the
correctness (freshness") of NHNS data, mechanism to alert users when data
sets are older than a certain number of days (e.g. 1 month)
Remote update tools
The first pilot phase since fall 1999 clearly showed up an administrative
problem. Only in few cases a Usenet TLH maintainer is in a position to
directly maintain or even update a DNS server. This leads to additional
delays for updates to the TLH master files at best, to outdated NHNS data
in the worst case.
To faciliate the maintanance process, it has been split into two separate
* the hierarchy maintainer adds/deletes/modifies NHNS records from a
(known) remote site using the "permit update" facility in new BIND
releases (no special BIND/DNS knowledge required)
* the admin of the DNS server initially installs the master zone file
for a TLH. No special Usenet knowledge is required from his part, nor is
he involved in future modifications to the TLH zone.
* update scripts to reflect decision about DNS integration (Daniel
* modify NHNS servers, i.e. store TLHs under usenet.nhns.net (TLH
* port to Diablo (no volunteers available in audience)
* lobbying to achive wider deployment (working group members)
Q: how much effort is needed to join in with a hierarchy ?
A: of NHNS server maintainer and hierarchy maintainer can be split now.
The maintainer can more or less safely get update rights on his dedicated NHNS
Flowmaps (Kai Siering)
Learn about news traffic flows in order to improve peerings.
Brief overview about history of flowmaps back to the times of Heiko Rupp
* direct creation of a postscript file from path-header data
* it is difficult to find useful 2D geographical representation of news
* new approach with geomview package
* newsdist-like approach with logical rather than geographical
* makefeedmap: nice if a server has a few peers only, but suboptimal in
case of a tightly meshed server
* Cichlid from caida.org: uses 3D, colors, line thickness, line colors;
clickable servers allow to get detail information
* Cichlid package (Unix, Windouze)
* Setup Cichlid server and viewers on client stations
* collect path headers by modified inpath program (expect 100M
* Kai Siering to provide scripts which allow Cichlid representation as
well as his modified inpath software. URL will be provided on the
netnews-wg list later on.
* display volume instead of number of articles; this needs minor
modifications in INN code.
RIPE NCC workplan
What could RIPE do for the WG: no input from the audience.
Agenda RIPE-37: same topics as now, additional stuff can always be added