Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!columbia!rutgers!sri-spam!ames!ptsfa!ihnp4!occrsh!occrsh.ATT.COM!authorplaceholder
From: rct@occrsh.ATT.COM
Newsgroups: news.admin
Subject: Re: Negative Article ID's
Message-ID: <147300001@occrsh.ATT.COM>
Date: Fri, 24-Apr-87 15:18:00 EDT
Article-I.D.: occrsh.147300001
Posted: Fri Apr 24 15:18:00 1987
Date-Received: Sun, 26-Apr-87 22:07:18 EDT
References: <3673@drutx.ATT.COM>
Lines: 42
Nf-ID: #R:drutx.ATT.COM:-367300:occrsh.ATT.COM:147300001:000:2339
Nf-From: occrsh.ATT.COM!rct    Apr 24 14:18:00 1987


Perhaps I can explain the negative article IDs.  The primary feed site
for uokmax (occrsh.ATT.COM) is running a NEWS <--> notes gateway.
Although the notes software is not directly involved in any of the traffic
between uokmax and upstream sites, many of the sites fed by occrsh are
running notes and receive articles posted at uokmax.

Approximately two weeks ago, I made the decision to recompile the
notes software on occrsh to reflect the proper domain name.  In the
following days, many old articles were suddenly unleased by downstream
notes sites that were a bit slow to edit their notes support files and
rename the sequencer files for occrsh (to Sy:occrsh.ATT.COM from
Sy:occrsh.UUCP).  Most of the old articles never made it across the
NEWS <--> notes gateway because I'm running the latest news software
which correctly places such articles in "junk".  Unfortunately, a
few appear to have made it through:  I can only hope that the number
of such articles was minimal.

Why the negative article IDs?  Notes cannot deal with article IDs of
the format <x@y.z> where 'x' is not all digits, so the local gateway
software takes all article IDs where 'x' is not all digits and passes
'x' through a 32-bit crc generator.  The resulting number is unique
enough to satisfy USENET standards, and is reproducible for identical
'x'.  (The reason that the articles you mentioned ended up in junk was
not because of the negative article ID per se, rather, it was because
of the posting date of the article).

In summary, although the notes software makes it all too easy for
such things to happen, the direct cause of the old articles being
re-released was cockpit error, mostly on my part for failing to
correctly identify all the notes support files that needed changing.
One of the contributing factors that should be considered before
flaming anyone is the fact that most of the notes sites involved
are administered by folks that get paid to do other things.  Thus,
their failure to update the appropriate support files immediately
should be understandable, even if some folks would consider it
unforgivable.  For my part, all I can do is apologize and tell you
that many lessons were learned from a bad experience that should
prevent a reoccurence of this kind of thing from my end of the net.

--Bob Tracy
{most AT&T sites}!occrsh!rct