Skip to main content

You're viewing an archived page. It is no longer being updated.


RIPE Meeting:


Working Group:



1st Draft

Revision Number:


Please mail comments/suggestions on:

Netnews-WG meeting RIPE-36

participants: 13

chair: Dave Wilson

scribe: Felix Kugler

Admin stuff

* mailing list: [email protected], subscribe at [email protected]
* Agenda bashing: added RIPE NCC workplan 2001

Review of the RIPE-35 minutes

no comments

NHNS presentation (Daniel Diaz)

NHNS is a new approach to solve the newsgroup synchronisation problem.

Current status

* 10 hierarchies covered. Still waiting for more maintainers to join
* info source:, currently hosted at

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
* new statistics tool

DNS integration.

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!

* could not be registered by Elmar Bins
* 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 to go ahead; is the new
web server, TLHs to be stored under !

Quality of NHNS data

* update date has to be coded into the zone files serial number in the
format yyyymmddxx
* 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 (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
master server.

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 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.

future options:

* 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
later on.