RE: NOC communications

[Sean Donelan <SEAN () SDG DRA COM>]

> How about a major oversimplification of a fix.  Closed mailing list.  One
> primary contact for each company is designated and allowed to join the list.
> Every 2 weeks (maybe a month?) an email is autogenerated that must be ACK'd
> or that companies NOC entry is considered stale.  The person on the mailing
> list is responsible for ensuring contact info is updated.

Uhm, the usual problem is the contact person leaves the company.  The
exit interview rarely includes updating the contact information.  Everyone
else will know the information is out-dated, assuming you ban people from
setting up procmail to auto-ack the message.  But how do you get the
replacement's contact information if the replacement doesn't know about
the list, database, server, etc and you don't know who the replacement
is?

In any case, I'd be happy to participate in such a list.  Although
in some sense you are preaching to the converted.

If you would like a sample message, how about something similar to
what a previous government contractor used to send every six months or
so when they managed the NIC database.  Perhaps change the "do not
respond," to "respond with 'ok 123456'" to make the procmail folks work
a little harder writing their auto-ack scripts. 

> Date: Tue, 25 Sep 90 01:09:33 PDT
> From: HOSTMASTER () NIC DDN MIL
> Subject: Network Administrator Update
> To: sean () DRANET DRA COM
>
> Dear Network Coordinator,
>    
>   Here is the current information pertaining to your network.
>   Please review it and return any corrections to
>   HOSTMASTER () NIC DDN MIL.
>
>   ** If no changes are needed, you do not need to respond to this
>      message. **
>
>   The file
>
>      NETINFO:NETWORK-CONTACTS.TXT
>
>   on the NIC.DDN.MIL machine (network address 192.67.67.20) contains
>   information regarding network contacts for every IP network registered
>   with the DDN Network Information Center.  This file may be FTPed by
>   invoking FTP at your local host and connecting to NIC.DDN.MIL, using
>   USERID = 'anonymous', PASSWORD = 'guest'.
>
>  Please allow 8 working days for changes to be processed.
>    
>  Thanks,
>
>  Hostmaster Staff
>  DDN Network Information Center
>
> -----------
>
>
> NAME of responsible organization: Data Research Assoicates, Inc.
>
>
>   Network Name: DRA-STL
>   Network Number: 192.65.218.0
>
>   Coordinator:
>      Donelan, Sean M.  (SMD1)  sean () DRANET DRA COM
>      (314) 432-1100

I'm a firm believer in keeping things simple.  But I also think we have
to understand the nature of institutional entropy.  Any system that
relies on the active, continuing participation of a particular individual,
no matter how well intentioned and no matter how minor, will run off
the same cliff.  The system has to be inserted directly into the
institutional gut. Where the institution goes, it goes.  And it needs to
be more painful for the institution to remove it, than to leave it in.

ARIN meets the criteria of gut wrenching pain.  But I wonder how often
and how long they can really apply sanctions against a network provider
before it becomes easier for the network provider to take some
alternative action.  So they give ARIN a phone number, get their
addresses and disconnect the phone line a week later.  In six months
or a year, when they need more addresses they plug the phone back in,
and call ARIN.  I really wish I was just being cynical, but can I
see a show of hands of those providers who thought the same thing?


Maybe I'm just slow to catch on, but here are what I see the basic
principles of an inter-NOC communications system:

   1) require an affirmative management action to start participation
        pay a dollar, cut a ribbon, sign something, do something, anything
        to avoid the 'NOC cowboy' problem, and everything that engineer
        did being tainted when he or she leaves.  Ok, the CEO doesn't
        have to understand how it works, she just has to think it was her
        brillant idea.
   2) once in use it should require an affirmative action to disconnect
        not require anyone to remember to update it.  not require anyone
        to reload the special software on the PC after Microsoft does
        its periodic self-destruct.  neglect shouldn't kill it, only
        yanking the wires out of the wall or some virtual equivalent should
        do it in.
   3) must not be annoying, but still a pain
        if it doesn't involve me, don't bother me.  the 'normal'
        channels should be the easiest to use.  If you can't show
        the normal channels failed, you shouldn't be using this.
        If all else fails, it should get Someone's attention by Klaxon,
        sirens, flashing lights, you name it.  If you answer it, it
        will shut up.
   4) must be a 'visible' system
        can't be buried on an individual's PC hard drive, or inside
        a PBX's programming.  Even if no one tells them about it, new
        NOC engineers should trip over it in their normal course of
        business (i.e. before they need it).  "Hey wally, what's that
        funny machine in the corner for?"
   4a) preferably something pointy-haired managers can point to when
        they are giving tours of the NOC
        "This is CNN, and this is our inter-NOC communications link"
        I thought about plugging a EAS-like box into the NOC's CNN feed,
        since everyone seems to already have CNN in their NOCs.  See
        klaxon, siren, flashing lights above.
    5) Positive ID required
        Everyone (and I mean Everyone) must be able to know exactly
        who (at least by organizational affiliation) is on, and off
        the NOC communications net.  The list of participants must be
        able to be published, without fear a non-participant could use
        the information to intrude into the NOC-net.   It should be
        possible to show the system works to an outsider, without the
        outsider becoming an insider (i.e. learning the secret handshake).
        Likewise, it should be possible to positively disprove a
        non-participant's claim they are on-net if they aren't.  No
        signing MLPA's and never connecting.

and I'm a bit leery of #6, but the more I speak with people who give
me reasons why they haven't/won't participated in the previous attempts,
I can't find a way around it.

    6) a STRONG acceptable use policy, and a 'moderator' enforcing it
        The clash between 'open' and 'private' is a big one.  Some folks
        have said the previous attempts had too much 'noise' and not
        enough 'signal.'  Although from my experience the problem
        was usually ZERO signal, and ZERO noise.  But maybe my filters
        aren't as sensitive as other peoples'.

Since we have not yet created a sucessfull system, all previous attempts
going down in the flames of neglect.  Who knows if any of those principles
are even close to what's required.  I hope you noticed most of the
my principles involve human or organizational behaivor issues, not
technical requirements.  I think technically, almost any of the
previous systems could have worked.


> BTW, I think the line printer idea rules :)

In the old days, when I had to walk 20 miles in the snow up hill both
ways to school, TYMNET used to send their X.25 outage notifications to
customers via Western Union teletype.  It wasn't an ASR33, but some
type of Telex thermal printer at the time.  You knew when it fired
up, trouble was on its way.
-- 
Sean Donelan, Data Research Associates, Inc, St. Louis, MO
  Affiliation given for identification not representation