List of Archived Posts

2001 Newsgroup Postings (04/22 - 05/24)

April Fools Day

Blame it all on Microsoft

Block oriented I/O over IP

"Bootstrap"

Block oriented I/O over IP

SIMTICS

Blame it all on Microsoft

Blame it all on Microsoft

Blame it all on Microsoft

MIP rating on old S/370s

SIMTICS

High Level Language Systems was Re: computer books/authors (Re: FA:

Blame it all on Microsoft

High Level Language Systems was Re: computer books/authors (Re: FA:

Climate, US, Japan & supers query

Blame it all on Microsoft

Pre ARPAnet email?

Pre ARPAnet email?

Pre ARPAnet email?

SIMTICS

Pre ARPAnet email?

High Level Language Systems was Re: computer books/authors (Re: FA:

High Level Language Systems was Re: computer books/authors (Re: FA:

Pre ARPAnet email?

Pre ARPAnet email?

Pre ARPAnet email?

Can I create my own SSL key?

Can I create my own SSL key?

Pre ARPAnet email?

IBM Reference cards.

Pre ARPAnet email?

High Level Language Systems was Re: computer books/authors (Re: FA:

Blame it all on Microsoft

Can I create my own SSL key?

Blame it all on Microsoft

Can I create my own SSL key?

Can I create my own SSL key?

Can I create my own SSL key?

IBM Dress Code, was DEC dress code

Can I create my own SSL key?

Can I create my own SSL key?

Where are IBM z390 SPECint2000 results?

OT: Ever hear of RFC 1149? A geek silliness taken wing

Can I create my own SSL key?

Where are IBM z390 SPECint2000 results?

VM/370 Resource Manager

Can I create my own SSL key?

Where are IBM z390 SPECint2000 results?

Where are IBM z390 SPECint2000 results?

Can I create my own SSL key?

"IP Datagrams on Avian Carriers" tested successfully

OT: Ever hear of RFC 1149? A geek silliness taken wing

Pre ARPAnet email?

Pre ARPAnet email?

line length (was Re: Babble from "JD" <dyson@jdyson.com>)

Pre ARPAnet email?

Need explaination of PKI and Kerberos

line length (was Re: Babble from "JD" <dyson@jdyson.com>)

Wireless Interference

Design (Was Re: Server found behind drywall)

Estimate JCL overhead

Estimate JCL overhead

Modem "mating calls"

Modem "mating calls"

Design (Was Re: Server found behind drywall)

Stoopidest Hardware Repair Call?

line length (was Re: Babble from "JD" <dyson@jdyson.com>)

line length (was Re: Babble from "JD" <dyson@jdyson.com>)

Estimate JCL overhead

line length (was Re: Babble from "JD" <dyson@jdyson.com>)

Modem "mating calls"

line length (was Re: Babble from "JD" <dyson@jdyson.com>)

Stoopidest Hardware Repair Call?

CS instruction, when introducted ?

CS instruction, when introducted ?

Apology to Cloakware (open letter)

Stoopidest Hardware Repair Call?

Apology to Cloakware (open letter)

digital signature and certificates in xml

digital signature and certificates in xml

The Mind of War: John Boyd and American Security

Passwords

The Mind of War: John Boyd and American Security

The Mind of War: John Boyd and American Security

April Fools Day

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: April Fools Day
Newsgroups: alt.folklore.computers
Date: Sun, 22 Apr 2001 20:32:44 GMT

jata@aepiax.net (Julian Thomas) writes:

Yes, I remember this well.  Let's see - xxx = HAL <gg>?

at least H worked for them ... and then formed H&L (aka HAL) with a
lot of funding from somebody before being totally taken over by them.
supposedly one of the reasons for the non-stop MD11 out of San Jose by
American was because HAL had standing seat reservations on the plane
every week (on the other hand gates were tight at sfo).

--
Anne & Lynn Wheeler   | lynn@garlic.com, http://www.garlic.com/~lynn/

Blame it all on Microsoft

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blame it all on Microsoft
Newsgroups: comp.os.linux.advocacy,comp.theory,comp.arch,comp.object
Date: Sun, 22 Apr 2001 20:41:35 GMT

Toon Moene writes:

The problem with VMS is not that it's VMS - it's that you spoil your
eyes on the microfiche trying to read the source.

there is the joke/story about MVS from the late '70s where somebody
wanted to get the exact (microfiche) listings that corresponded to the
binaries that they were executing. after the company spent a couple
million looking into the opportunity, they finally concluded that
there was no way of absolutely guarentee'ing that an exact set of
microfiche listings could be created that exactly corresponded to
binaries being execuated.

--
Anne & Lynn Wheeler   | lynn@garlic.com, http://www.garlic.com/~lynn/

Block oriented I/O over IP

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Block oriented I/O over IP
Newsgroups: comp.arch
Date: Sun, 22 Apr 2001 20:58:22 GMT

"Stephen Fuld" writes:

IBM's MVS can use a system inherited from older IBM operating systems where
a single disk is shared.  Unfortunately, locking is at the volume level.

IBM's TPF (formerly called ACP) supports locking at a record level and is
very high performance.  It uses locking commands in the disk controller.

TPF/ACP started out using the standard IBM disk controller
reserve/release commands (from the 360 days). Early to mid 70s, the
3830 disk controller was enhanced (originally called the ACP-RPQ) to
support fine-grain logical locks (i.e. software can use nearly any
naming convention for the locks ... including convention to achieve
record level locking).

For awhile, my wife was in POK responsible for "loosely-coupled"
architecture and created peer-coupled shared data architecture which
became the basis for IMS hot-standby and sysplex.

When she and I ran skunk-works that developed HA/CMP ... we supported
shared SCSI in "mode1" (mostly 1+1, but possible N+1, N+M), "mode2"
(independent operation with either failing over to the other but
degradation), and "mode3" (concurrent activity).

I got to the design and the first prototype implementation for the
distributed lock manager. One of the benefits was working with some of
the DBMS vendors that had versions running on VAX-clusters and at
least two of them provided us with "top ten things done wrong in
VAX-clusters" and since I had the opportuunity to start from scratch
(plus long history with 360 & 370 loosely-coupled configurations)
... that they figured that I shouldn't make the same mistakes.

I believe the semantics for that is still used ... even in the case
where at least one of the DBMS vendors has done a generic version that
allows it to run on other platforms.

I've even run across relatively recent marketing blurps by other
vendors that nearly reads word-for-word the same as some stuff I wrote
in the late '80s for HA/CMP.

random refs:
http://www.garlic.com/~lynn/subtopic.html#hacmp

--
Anne & Lynn Wheeler   | lynn@garlic.com, http://www.garlic.com/~lynn/

"Bootstrap"

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: "Bootstrap"
Newsgroups: alt.folklore.computers
Date: Mon, 23 Apr 2001 18:21:13 GMT

jcmorris@jmorris-pc.MITRE.ORG (Joe Morris) writes:

2914?

No, later than that - 3xxx series.

3914.  (Or maybe 3814?  I don't recall if the S/370 flavor of the switch
was considered an RPQ (x9xx) or a control unit (x8xx).

the 2914(?) version was typically blue-box with rotory switches on
back panel ... something like 8-10(?) rotory switches with possibly
8?-16? positions ... effectively switching channel cables to
processors.

i remember the 3914(?) version was beige and displays and programmic input

the disk engineering labs used a number of them for switching test
cells between different processors.

i'm on trip ... so don't have references at the moment to cross-check

random refs:
http://www.garlic.com/~lynn/subtopic.html#disk

--
Anne & Lynn Wheeler | lynn@garlic.com, http://www.garlic.com/~lynn/

Block oriented I/O over IP

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Block oriented I/O over IP
Newsgroups: comp.arch
Date: Mon, 23 Apr 2001 18:44:18 GMT

"Bill Todd" writes:

W.r.t. the HA/CMP DLM, my impression had been that it was developed by CLAM
Associates around 1994 (and at least at the interface level was almost a
dead-exact clone of the VMS DLM - likely to make OPS happy), so was the DLM
you're referring to above a prototype that was its precursor or is my
understanding just incorrect?

my wife and I subcontracted out a lot of HA/CMP development work to
CLaM starting in '89 when they were just a three person shop of former
IBM'ers in Cambridge ( it is actually "C", "L", & "M" ... where "C" at
one time had been my wife's manager in G'burg when she worked on FS
(future system) advanced I/O.

Some of the semantics were similar to VMS DLM (in part because at
least two of the DBMS vendors were adapting their cluster product from
VMS to ha/cmp). However there were other pieces of the semantics and
various internal pieces that were different specifically because they
were on their list of things done "wrong" in vms.

I got to do the original design and prototype ... but CLaM did majority of
the actual product.

as per
http://www.garlic.com/~lynn/95.html#13

we had concurrent access running in 91 (we had non-concurrent access
with fall-over in '89) ... and was looking at scaling the support
during '92.

random refs:
http://www.garlic.com/~lynn/2000c.html#9
http://www.garlic.com/~lynn/2000c.html#56
http://www.garlic.com/~lynn/2000c.html#77

--
Anne & Lynn Wheeler   | lynn@garlic.com, http://www.garlic.com/~lynn/

SIMTICS

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SIMTICS
Newsgroups: alt.os.multics
Date: Tue, 24 Apr 2001 01:13:04 GMT

ehrice@his.com (Edward Rice) writes:

Off-topic for alt.os.multics but on-topic (sort of) in
alt.folklore.computers -- Lynn Wheeler has written in some detail about the
many-Linux-instances efforts, and if you're interested in that you really
should go back and find what he's written.  If you grep for his name and
"cluster" and "S/390" you'll come up with at least part of it, but the
topic has surfaced at least twice.

note that this wasn't a cluster but VM (virtual machine) operating in
a single LPAR (aka LPAR is sort of a stripped down flavor of VM
running in the microcode of the real hardware). So it was the real
processor ... with the microcode set to partition the real hardware
into multiple "LPAR" logical machines ... and VM operating system
running in one of the LPARs providing multiple virtual machines, in
this case, 41,400 virtual machines ... each running a different copy
of Linux.

copied from a posting
http://www.garlic.com/~lynn/2000b.html#8

--
Anne & Lynn Wheeler   | lynn@garlic.com, http://www.garlic.com/~lynn/

Blame it all on Microsoft

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blame it all on Microsoft
Newsgroups: comp.os.linux.advocacy,comp.theory,comp.arch,comp.object
Date: Wed, 25 Apr 2001 18:30:22 GMT

Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:

Mr Stallman did not invent the concept, he just advocates something
patterned after the operating procedures used with the PDP-1 at
MIT about 1962 or so.  Quite a bit before anything called "XMODEM"
I would say.

while not '62 ... I worked with both HASP (starting mid '67) and CP/67
(starting 1/68) which had distributed source. I think that it was
between the june 23rd, 1969 announcement (where everything became
separately priced ... presumably, at least in part to various
gov. activities) and 370 that a lot more attention was paid to
software ownership (started seeing copyright statements in source and
then later in the '70s the big furor over "OCO" ... object-code-only
... debate that crops up in some newsgroups & mailing lists to this
day).

i believe early machines in the '50s may have had freely available
source ... but there would have been much less of it. One could
contend that gov. activities to make everything separately priced is
as much to do with the situation as anything else.

--
Anne & Lynn Wheeler   | lynn@garlic.com, http://www.garlic.com/~lynn/

Blame it all on Microsoft

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blame it all on Microsoft
Newsgroups: comp.os.linux.advocacy,comp.theory,comp.arch,comp.object
Date: Wed, 25 Apr 2001 21:37:11 GMT

Kilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:

When I entered into this discussion thread, it was not merely about the
availability of source but about the "hacker" ethic of each person putting
their changes back into a common source pool, all the time.  At the MIT
PDP-1 this was accomplished with physical access to the paper tape tray
that held popular programs.  That closely-knit community was what I was
relating, not the mere availability of source.

both HASP and CP/67 had extremely strong user community of people
putting source back into the product and being redistributed.

for instance ... one of the things I did as undergraduate on CP/67 was
implement all the TTY/ASCII terminal support which was incomporated
back into the source and distributed. Tom Van Vleck ... somewhere on
the multics "site" has a story about modifying the ASCII support on
one of the MIT machines running production service (national urban
planning something or other, i believe) and have it crash and
re-ipl/boot 26 times in a single day. some comment about one of the
drivers behind doing the (new) multics filesystem was to get it so a
crash & re-ipl didn't take much of 1st shift.

--
Anne & Lynn Wheeler   | lynn@garlic.com, http://www.garlic.com/~lynn/

Blame it all on Microsoft

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blame it all on Microsoft
Newsgroups: comp.os.linux.advocacy,comp.theory,comp.arch,comp.object
Date: Wed, 25 Apr 2001 21:40:30 GMT

Michael Lyle writes:

Wow. I would never claim that SNA was superior to TCP/IP, or even NCP.
If I recall correctly, SNA was a strict tree topology, with no peer to
peer communication possible.  A graph (as used by TCP/IP and its
ancestors) seems much more robust, scalable and manageable than a tree
for communications.  I never read much about the specifics of DECnet,
so I can't comment, but I certainly felt that it was proprietary and
far too complex.

there is strong conjecture that (at least original) structure of SNA,
VTAM (the software monitor that ran in the mainframe, and NCP (not the
arpanet NCP, but ibm's NCP; ran in the terminal/line mainframe control
unit) was largely precipitated by a project that I worked on as an
undergraduate that originated the 360 PCM (plug compatible manufactur)
mainframe control unit.

random ref:
http://www.garlic.com/~lynn/subtopic.html#360pcm

--
Anne & Lynn Wheeler   | lynn@garlic.com, http://www.garlic.com/~lynn/

MIP rating on old S/370s

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: MIP rating on old S/370s
Newsgroups: bit.listserv.ibm-main
Date: Wed, 25 Apr 2001 21:55:16 GMT

jmaynard@CONMICRO.CX (Jay Maynard) writes:

370/168, or perhaps a small 4381...dunno about anything newer. It's
definitely faster than a 370/158 and a 4341. (So's my PIII-500 laptop...I
can walk around with enough machine to run MVS 3.8 faster than the first 370
I ever worked on for a living. Amazing, these computers...)

some 370 numbers for floating point numbers
http://www.garlic.com/~lynn/2000d.html#0

note that the 158 & the 3031 were supposedly the same processor
... the difference was that the 158 was sharing the engine with both
370 and channel microcode. The 3031 had two dedicated "158" engines
... one exclusive for 370 microcode and one exclusive for channel I/O
microcode (even difference on benchmark doing dedicated processing and
no i/o).

the later 168-3 supposedly got over 3mips (as opposed to the earlier
168-1).

--
Anne & Lynn Wheeler   | lynn@garlic.com, http://www.garlic.com/~lynn/

SIMTICS

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SIMTICS
Newsgroups: alt.os.multics
Date: Wed, 25 Apr 2001 23:27:41 GMT

Anne & Lynn Wheeler writes:

copied from a posting
http://www.garlic.com/~lynn/2000b.html#8

oops, finger slip

http://www.garlic.com/~lynn/2000b.html#62

--
Anne & Lynn Wheeler   | lynn@garlic.com, http://www.garlic.com/~lynn/

High Level Language Systems was Re: computer books/authors (Re: FA:

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: High Level Language Systems was Re: computer books/authors (Re: FA:
Newsgroups: comp.arch,alt.folklore.computers
Date: Thu, 26 Apr 2001 17:50:31 GMT

Charles Richmond writes:

Assembly macros can get very complex...the set of macros available from
IBM for our IBM 370 was a convoluted mass!!!  IMHO, no one really understood
what all of it did...

The IBM operating systems like MVS had a very large body of system &
library services ... each with their own invokation and most with a
corresponding "macro" to access the service. It wasn't so much that
there were macros for the sake of having macros .... it was more a
case that every system service and library service had one or more
macros.

GET/PUT had at least a DCB (data control block) macro that initialized
a lot of the I/O parameters, explicit OPEN & CLOSE macros that invoked
the file open/close functions and GET/PUT that actually performed the
data transfer. READ/WRITE was similar but in addition it would have a
ECB macro (event control block) that was data structure for
serialization and at least a WAIT for serialization (and possibly
POST).

--
Anne & Lynn Wheeler   | lynn@garlic.com, http://www.garlic.com/~lynn/

Blame it all on Microsoft

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blame it all on Microsoft
Newsgroups: comp.os.linux.advocacy,comp.theory,comp.arch,comp.object
Date: Thu, 26 Apr 2001 18:19:21 GMT

Jan Vorbrueggen writes:

And MVS and VM had two different implementations of RSCS (the basis of
BITNET), done by two indepedent groups I believe, which resulted in certain
files crashing any MVS machine they happened to traverse when sent via BITNET
(a store and forward network). Of course, RSCS is a resilient protocol, so
when the other side came back again after the crash, the file was resent...

VM had RSCS (done originally in cambridge) ... HASP originally had
some networking code that I believe was originally/partially developed
by triangle university (at least some amount of the code in HASP made
reference to them). That was ported over into JES2 (when HASP became
JES2) ... and was generically labeled NJE (network job entry).

The JES2 NJE implementation shared some similar shortcomings with
ARPANET NCP ... networking, line-drivers, etc protocol somewhat all
mixed together ... no real "internetworking" support yet. The mixture
of different information corresponding to different levels of a
"protocol stack" in NJE headers caused them a lot of
problems. Different versions of JES2/NJE would frequently not
inter-operate ... and there were more than a few instances of where
one version of JES2/NJE attempting to process a network file from a
differen level of JES2/NJE would bring the whole system crashing.

CPREMOTE/RSCS/VNET (i.e. VM's system which went thru various naming
iterations) had much cleaner layered implementation with effectively
internetworking & gateway support from just about its origins (and was
major reason that the internal network was larger than the whole
arpanet/internet up thru about '85). A typical RSCS/VNET might have
some number of "native" drivers as well as JES2/NJE drivers ... as
well as special drivers.

Because of the shortcomings in the NJE implementation (frequently
mixing all sorts of stuff in their headers) ... it was not uncommong
to find a RSCS node sitting between two JES2/NJE nodes ... where the
RSCS node had drivers for all the different versions of NJE ... and
would provide the appropriate header conversions in order to keep
different JES2/NJEs from crashing each other.

Because of various corporate issues, the native RSCS/VNET "native"
drivers eventually came into disuse in favor of standardized NJE
protocol (in part because RSCS/VNET operation was relatively protocol
neutral while NJE was tightly wedded to its protocol ... even tho
RSCS/VNET "native" drivers might have significantly higher thruput),
but it still continued to be common to find RSCS/VNET being
intermediate nodes between NJE nodes ... minimizing their ability to
corrupt and crash each other with version and/or maintenance activity.

random refs:
95.html#7 Who built the Internet? (was: Linux/AXP.. Reliable?)
http://www.garlic.com/~lynn/99.html#33 why is there an "@" key?
http://www.garlic.com/~lynn/99.html#34 why is there an "@" key?
http://www.garlic.com/~lynn/99.html#212 GEOPLEX
http://www.garlic.com/~lynn/2000b.html#29 20th March 2000
http://www.garlic.com/~lynn/2000b.html#43 Migrating pages from a paging device (was Re: removal of paging device)
http://www.garlic.com/~lynn/2000b.html#67 oddly portable machines
http://www.garlic.com/~lynn/2000c.html#29 The first "internet" companies?
http://www.garlic.com/~lynn/2000d.html#72 When the Internet went private
http://www.garlic.com/~lynn/2000e.html#14 internet preceeds Gore in office.
http://www.garlic.com/~lynn/2000e.html#15 internet preceeds Gore in office.
http://www.garlic.com/~lynn/2000g.html#24 A question for you old guys -- IBM 1130 information
http://www.garlic.com/~lynn/2001b.html#71 Z/90, S/390, 370/ESA (slightly off topic)
http://www.garlic.com/~lynn/2001b.html#85 what makes a cpu fast
http://www.garlic.com/~lynn/2001c.html#4 what makes a cpu fast
http://www.garlic.com/~lynn/2001c.html#5 what makes a cpu fast

--
Anne & Lynn Wheeler  | lynn@garlic.com, http://www.garlic.com/~lynn/

High Level Language Systems was Re: computer books/authors (Re: FA:

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: High Level Language Systems was Re: computer books/authors (Re: FA:
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 27 Apr 2001 22:46:17 GMT

"Charlie Gibbs" writes:

To be fair, there were times such a practice could be justified -
or at least rationalized.  Programmers had rock-bottom priority on
our (single-tasking) Univac 9300, which was kept busy all day long
running production jobs.  In the case of one large program which
took 20 minutes to assemble, it was often easier to patch the
executable, especially if the fix was needed RIGHT NOW.  This
would go through several iterations over time, until eventually
the program would collapse under the weight of 30 or 40 REP cards.
Only then would I edit the source deck with all of the changes I
had been marking up the listing with, and try to scrounge enough
machine time for a re-assembly.

before I found out about rep cards ... I would repunch the binary
original. This was in undergraduate days ... and I would have 48hr
shift of dedicated machine time on the weekend and didn't want to
waste it on a 30-50 minute re-assemble. I got pretty good at being
able to read card punch holes in binary.

random refs:
http://www.garlic.com/~lynn/93.html#15 unit record & other controllers
http://www.garlic.com/~lynn/93.html#17 unit record & other controllers
http://www.garlic.com/~lynn/93.html#23 MTS & LLMPS?
http://www.garlic.com/~lynn/94.html#53 How Do the Old Mainframes
http://www.garlic.com/~lynn/95.html#4 1401 overlap instructions
http://www.garlic.com/~lynn/96.html#24 old manuals
http://www.garlic.com/~lynn/97.html#21 IBM 1401's claim to fame
http://www.garlic.com/~lynn/98.html#9  Old Vintage Operating Systems
http://www.garlic.com/~lynn/98.html#15 S/360 operating systems geneaology
http://www.garlic.com/~lynn/99.html#59 Living legends
http://www.garlic.com/~lynn/99.html#100 Why won't the AS/400 die? Or, It's 1999 why do I have to learn how to use
http://www.garlic.com/~lynn/99.html#102 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
http://www.garlic.com/~lynn/99.html#130 early hardware
http://www.garlic.com/~lynn/2000.html#79 Mainframe operating systems
http://www.garlic.com/~lynn/2000.html#83 Ux's good points.
http://www.garlic.com/~lynn/2000b.html#77 write rings
http://www.garlic.com/~lynn/2000c.html#11 IBM 1460
http://www.garlic.com/~lynn/2000c.html#75 Does the word "mainframe" still have a meaning?
http://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
http://www.garlic.com/~lynn/2000d.html#34 Assembly language formatting on IBM systems
http://www.garlic.com/~lynn/2000d.html#37 S/360 development burnout?
http://www.garlic.com/~lynn/2000d.html#46 Charging for time-share CPU time
http://www.garlic.com/~lynn/2000d.html#48 Navy orders supercomputer
http://www.garlic.com/~lynn/2001.html#3 First video terminal?
http://www.garlic.com/~lynn/2001.html#11 IBM 1142 reader/punch (Re: First video terminal?)
http://www.garlic.com/~lynn/2001b.html#0 Java as a first programming language for cs students
http://www.garlic.com/~lynn/2001b.html#22 HELP
http://www.garlic.com/~lynn/2001b.html#26 HELP
http://www.garlic.com/~lynn/2001b.html#27 HELP
http://www.garlic.com/~lynn/2001b.html#36 [OT] Currency controls (was: First OS?)
http://www.garlic.com/~lynn/2001b.html#71 Z/90, S/390, 370/ESA (slightly off topic)

--
Anne & Lynn Wheeler   | lynn@garlic.com, http://www.garlic.com/~lynn/

Climate, US, Japan & supers query

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Climate, US, Japan & supers query
Newsgroups: comp.sys.super,comp.arch
Date: Fri, 27 Apr 2001 22:58:14 GMT

David Brower writes:

Program trading makes money, and the analysis that drives it can
consume as much cpu as you choose to throw at it.  I'm given to
believe that such applications are happily looking at the economics
of beowulf-like intel clusters nowadays.   Classical supercomputers
really are dinosaurs whose carcasses are being eaten by the killer
micros.

there was a story about a particular system in a large metropolitan
skyscrapper (50+ stories) ... the claim was that in 24hrs the system
accounted for more profit than 1 year lease on the whole building plus
1 year salary for all people working in the building (conversely, if
the system was down for 24hrs ... it didn't make that).

totally random ref:
http://www.garlic.com/~lynn/95.html#13
http://www.garlic.com/~lynn/2001e.html#4

--
Anne & Lynn Wheeler   | lynn@garlic.com, http://www.garlic.com/~lynn/

Blame it all on Microsoft

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blame it all on Microsoft
Newsgroups: comp.os.linux.advocacy,comp.theory,comp.arch,comp.object
Date: Sun, 29 Apr 2001 17:59:23 GMT

Toon Moene writes:

It's probably because I've been spoiled by CDC.  Not only did we get all
of the sources with our operating system (and the build jobs - which we
threw away and re-did better), but also we learned that it was a good
thing (technically, not just socially) to return our fixes for everyone
to share - that way they would be incorporated in the standard
distribution, which would save us a headache next time round ...

CP/67 and then VM/370 were both distributed in source. I believe that
at one time there was some analysis that there was twice as much
kernel code (modifications) on the share waterloo tape as code in the
distributed kernel.

--
Anne & Lynn Wheeler   | lynn@garlic.com, http://www.garlic.com/~lynn/

Pre ARPAnet email?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Pre ARPAnet email?
Newsgroups: alt.folklore.computers
Date: Mon, 30 Apr 2001 23:58:23 GMT

echomko@polaris.umuc.edu (Eric Chomko) writes:

Yes, they did somehow. So the standarization of those internetworking
became TCP/IP, which back between 1969 and 1978? did not exist by the
name: TCP/IP.

Your point is well taken, however, in that the OSI Reference model is more
of a design construct than an implementation construct. But we all know
that sometimes you have to implement it first and then design it later! :)

there are RFCs for TCP on arpanet/NCP predating the IP work.

The thing that IP brought was the internetworking layer ... along with
gateways .... something that really wasn't in OSI either ... much more
traditional hierarchical homogeneous protocol stack ... rather than
allowing for a lot of heterogeneous networking.

the great cut-over from arpanet/NCP to IP in 1/1/83 was one of the
enabling things allowing big growth spurt in the size of the internet
... so that by sometime in possibly '85 the "internet" was finally
larger than the internal network (which effectively had hetergeneous
gateway support in its nodes from just about the beginning)

random refs:
http://www.garlic.com/~lynn/99.html#33 why is there an "@" key?
http://www.garlic.com/~lynn/99.html#34 why is there an "@" key?
http://www.garlic.com/~lynn/99.html#37b Internet and/or ARPANET?
http://www.garlic.com/~lynn/99.html#39 Internet and/or ARPANET?
http://www.garlic.com/~lynn/99.html#44 Internet and/or ARPANET?
http://www.garlic.com/~lynn/99.html#112 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
http://www.garlic.com/~lynn/99.html#114 What is the use of OSI Reference Model?
http://www.garlic.com/~lynn/99.html#115 What is the use of OSI Reference Model?
http://www.garlic.com/~lynn/99.html#212 GEOPLEX
http://www.garlic.com/~lynn/2000.html#51 APPC vs TCP/IP
http://www.garlic.com/~lynn/2000b.html#0 "Mainframe" Usage
http://www.garlic.com/~lynn/2000b.html#1 "Mainframe" Usage
http://www.garlic.com/~lynn/2000b.html#4 "Mainframe" Usage
http://www.garlic.com/~lynn/2000b.html#8 "Mainframe" Usage
http://www.garlic.com/~lynn/2000b.html#10 "Mainframe" Usage
http://www.garlic.com/~lynn/2000b.html#59 7 layers to a program
http://www.garlic.com/~lynn/2000b.html#67 oddly portable machines
http://www.garlic.com/~lynn/2000b.html#79 "Database" term ok for plain files?
http://www.garlic.com/~lynn/2000d.html#63 Is Al Gore The Father of the Internet?
http://www.garlic.com/~lynn/2000d.html#67 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000d.html#70 When the Internet went private
http://www.garlic.com/~lynn/2000d.html#72 When the Internet went private
http://www.garlic.com/~lynn/2000e.html#15 internet preceeds Gore in office.
http://www.garlic.com/~lynn/2000e.html#18 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000e.html#19 Is Al Gore The Father of the Internet?^
http://www.garlic.com/~lynn/2000g.html#24 A question for you old guys -- IBM 1130 information
http://www.garlic.com/~lynn/2001b.html#81 36-bit MIME types, PDP-10 FTP
http://www.garlic.com/~lynn/2001b.html#85 what makes a cpu fast
http://www.garlic.com/~lynn/2001c.html#4 what makes a cpu fast
http://www.garlic.com/~lynn/2001e.html#12 Blame it all on Microsoft

--
Anne & Lynn Wheeler   | lynn@garlic.com, http://www.garlic.com/~lynn/

Pre ARPAnet email?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Pre ARPAnet email?
Newsgroups: alt.folklore.computers
Date: Wed, 02 May 2001 00:17:08 GMT

Ric Werme writes:

Europe was supposed to embrace OSI thanks to the greater power of the
telephony people, but the infusion of free, working TCP/IP code kicked
out OSI's foundation.  I still have a memo I wrote at DEC soon after
the demise of Alliant where I commented on an industry analyst
comments about OSI deploying in significantly smaller numbers than
previously expected.  Like 10% of the old estimate.  My claim was that
it would be much less.

us gov. w/gosip was dictating adoption of osi also.

misc. gosip refs
http://www.garlic.com/~lynn/99.html#114 What is the use of OSI Reference Model?
http://www.garlic.com/~lynn/99.html#115 What is the use of OSI Reference Model?
http://www.garlic.com/~lynn/2000b.html#0 "Mainframe" Usage
http://www.garlic.com/~lynn/2000b.html#59 7 layers to a program
http://www.garlic.com/~lynn/2000b.html#79 "Database" term ok for plain files?
http://www.garlic.com/~lynn/2000d.html#16 The author Ronda Hauben fights for our freedom.
http://www.garlic.com/~lynn/2000d.html#43 Al Gore: Inventing the Internet...
http://www.garlic.com/~lynn/2000d.html#63 Is Al Gore The Father of the Internet?
http://www.garlic.com/~lynn/2000d.html#70 When the Internet went private

--
Anne & Lynn Wheeler   | lynn@garlic.com, http://www.garlic.com/~lynn/

Pre ARPAnet email?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Pre ARPAnet email?
Newsgroups: alt.folklore.computers
Date: Wed, 02 May 2001 17:40:35 GMT

Lars Poulsen writes:

Since the directory did not exist, it could be theoretically
perfect. The fact that email did not actually work was just
a temporary setback. The actual mail protocol was good,
"and just as soon as directory is completed, it will start
working, and be much better than the internet stuff, which
requires the user to memorize these arcane codewords such
as hostnames and usernames".

i remember being at some DBMS conference circa '90/'91 and listening
to a talk about these x.500 networking types busily re-inventing 1960s
database technology.

--
Anne & Lynn Wheeler   | lynn@garlic.com, http://www.garlic.com/~lynn/

SIMTICS

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: SIMTICS
Newsgroups: alt.os.multics
Date: Thu, 03 May 2001 08:41:59 GMT

Barry Margolin writes:

There was a Unix emulator that run on top of Multics.  I don't think there
was port that ran directly on the iron, but I don't think it would have
been infeasible.  Unix was ported to IBM mainframes, and I imagine the
level of difficulty would be similar (mostly writing all the device
drivers).

AT&T had a port of Unix on top of TSS/370 that I believe had fairly
wide deployment inside AT&T (i.e. tss/370 supervisor/kernel provided
all the devices drivers and lot of page mapped file stuff ... along
with misc.  services).

There was a port to 360 at Princeton. That work was possibly picked up
by Amdahl (corporation, ibm mainframe clones) and evolved into UTS
with native 370 device drivers. It saw deployment most frequently in
VM virtual machines (analogous to the previous posting about linux)

random refs:
http://www.albion.com/security/intro-3.html
http://www.amdahl.com:80/cgi-bin/press-index/20000516-001.htm
http://www-sor.inria.fr/mirrors/usenix98/brochure/FREENIXprogram2.html
http://web.archive.org/web/20020304232915/http://www-sor.inria.fr/mirrors/usenix98/brochure/FREENIXprogram2.html
http://www.byte.com/art/9410/sec8/art3.htm

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

Pre ARPAnet email?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Pre ARPAnet email?
Newsgroups: alt.folklore.computers
Date: Thu, 03 May 2001 18:13:48 GMT

Anne & Lynn Wheeler writes:

there are RFCs for TCP on arpanet/NCP predating the IP work.

as an aside, last week 2822 & 2821 came out obsoleting 822 & 821
(presumably took some planning to get 2822 & 2821 reserved for that
purpose).

ref:
http://www.garlic.com/~lynn/rfcidx9.htm#2822
http://www.garlic.com/~lynn/rfcidx9.htm#2821
http://www.garlic.com/~lynn/rfcietff.htm

there was use of cp/67, single machine, information files transferred
between users in the late '60s.

sometime in the early to mid-70s, i remember being on a business trip
in europe and going thru some gyrations to be able to read my email
back in the states.

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

High Level Language Systems was Re: computer books/authors (Re: FA:

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: High Level Language Systems was Re: computer books/authors (Re: FA:
Newsgroups: comp.arch,alt.folklore.computers
Date: Thu, 03 May 2001 20:55:07 GMT

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:

Yes, it did.  If I remember correctly, BXH and BXLE were NOT part
of the original instruction set, though I cannot remember if they
came in with the 370 extensions.  They were also very slow on
some of the models, and it could be quite a lot faster not to
use them.  This then changed, of course.

IBM system/360 reference data greencard (gx20-1703)

branch on index high      BXH       RS         86       R1,R3,D2(B2)
branch on index low
         or equal         BXLE      RS         87       R1,R3,D2(B2)

I don't remember them being that slow (at least on 65/67).

Translate and Translate & Test instructions were slow ... it was
relatively easy to show loops (with bxh/bxle) as being faster than TR
& TRT.

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

High Level Language Systems was Re: computer books/authors (Re: FA:

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: High Level Language Systems was Re: computer books/authors (Re: FA:
Newsgroups: comp.arch,alt.folklore.computers
Date: Thu, 03 May 2001 23:34:53 GMT

johnl@iecc.com (John R Levine) writes:

Hmmn, let me check my 360/67 Functional Characteristics (which you can
still order from IBM's web site, by the way.)  On a Model 67-1, a BCT
took 1.15us, while BXH or BXLE took 1.6us for no branch, 1.4us for
branch taken.  Considering that you'd typically need a separate add or
subtract with BCT to update the control variable, which would take
another 0.65us if the addend were in a register or 1.4us if not, they
don't look slow to me.

i couldn't get list for 360/67 ... but they did list s360 model 30 as
still available

they also have

s/360 s/370 s/390 i/o interface channel to control unit OEMI
(ga22-6974-10) and its available in softcopy (aka other equipment
manufactur interfact or pcm ... plug compatible manufactur)

http://www.elink.ibmlink.ibm.com/public/applications/publications/cgibin/pbi.cgi?SSN=01ECW0004681095661&FNC=PBL&PBL=GA22-6974-10PBCEEBOI00030243&TRL=SRH

This publication provides a functional description of the interface
lines between Sys/360, Sys/370, Sys/390 channels and control units
designed by any manufacturer to operate with this I/O interface, said
to be the "parallel I/O" interface. It does not cover the interface
between the control unit and the I/O device, nor does it cover the
Sys/390 ESCON I/O interface. This publication is intended for
designers of programs and equipment associated with the parallel-I/O
interface and for service personnel maintaining that equipment, but
anyone concerned with the functional details of this interface will
find it useful.

we had it a little harder when we did it the first time ... random ref

http://www.garlic.com/~lynn/subtopic.html#360pcm

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

Pre ARPAnet email?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Pre ARPAnet email?
Newsgroups: alt.folklore.computers
Date: Fri, 04 May 2001 05:38:15 GMT

Ric Werme writes:

Here's that memo, somewhat sanitized, probably less than should be since
not all words are mine.  I'll compensate by not changing the subject line
above.  ;-)

and a 4/1 memo on the same subj3ct

From: meese@kremvax.arpa
Newsgroups: comp.protocols.tcp-ip,comp.protocols.iso
Message-ID: <880401@kremvax.arpa>
Date: 1 Apr 88 00:00:01 GMT
Posted: Fri Apr  1 00:00:01 1988

    WASHINGTON -- In a simultaneous announcement that took the
computer industry by surprise, OSI leaders today said that they were
abandoning their effort to promote the OSI Protocol Suite in favor of
the existing US Department of Defense (DoD) ARPANET Protocol Suite.

    The official reason cited for the decison was a new report from
the Office of Technology Assessment stating that the manpower required
to fully implement and test even the few OSI protocols that are now
defined would consume the entire output of American university computer
science programs for the rest of the century, and that printing and
distributing the necessary protocol specifications would consume the
entire American and Canadian paper supplies for the next five years.

    However, one high-placed source speaking on condition of
anonymity said, ``The whole OSI thing was a practical joke one of the
guys cooked up a few years ago.  Nobody ever expected anybody to take it
seriously.  I mean, who would believe an organization supposedly
dedicated to tearing down barriers to free and open communications
between computers when it's run by a former director of the National
Security Agency? I guess computer people are a lot more gullible than we
thought.  We kept dropping hints, making the whole thing more and more
ridiculous. We hoped that people would eventually catch on, but it didn't
work.  Finally, our consciences got to us.''

    In related news, officials at the Mitre Corporation in Bedford,
Massachussetts reported that one of their employees, as yet publicly
unidentified, froze ``as solid as stone'' when he heard the announcement.
Medical experts have as yet been unable to communicate with the victim
or get him to relax his facial muscles, which are reportedly locked into
what was described as an ``enormous grin''.

    AP-NR-04-01-88 0001EST

Pre ARPAnet email?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Pre ARPAnet email?
Newsgroups: alt.folklore.computers
Date: Fri, 04 May 2001 05:49:54 GMT

Ric Werme writes:

Here's that memo, somewhat sanitized, probably less than should be since
not all words are mine.  I'll compensate by not changing the subject line
above.  ;-)

and a 4/20/89 "trip report" regarding ansi x3s3.3 meeting on
submission of HSP (high speed protocol) proposal

A "high speed networking & transport protocol" proposal was submitted
by the xtp people at the x3s3.3 meeting. After various discussions it
was decided to submit a "study proposal for high speed protocols" to
the x3 committee ... the work product of which will be some number of
protocol proposals.

Problems with the original protocol proposal were numerous. Many
people objected to it violating the OSI reference model (and in fact
it is not possible to submit a protocol proposal to X3 that violates
the reference model ... although it is possible to approve an ANSI
standard that does violate the reference model ... but that takes some
fine work ... case in point are the LAN protocols ... especially with
FDDI coming up thru level 1 and 2 well into level 3).

The other camps were that existing protocols could be modified ... and
then of course the XTP camp. Existing protocol modification camp
doesn't adequately take into account that hardware/technology (x3s3.3
is responsible for levels 3 & 4) is eating them from below (and
high-speed protocol standard will have to face that reality).

The current plan is to attempt having the work group responsible for
the high-speed protocol study to co-schedule the meetings with the XTP
TAB meetings.

Also during the meeting, there was mention of a recent paper from
Berkeley that mentioned they have done some sort of enhanced
perfomance TCP/IP that gets the pathlength down to 200 instructions
(modifications to mbuffs, timer handling, interrupt handling, etc).

Pre ARPAnet email?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Pre ARPAnet email?
Newsgroups: alt.folklore.computers
Date: Fri, 04 May 2001 06:13:00 GMT

Ric Werme writes:

Here's that memo, somewhat sanitized, probably less than should be since
not all words are mine.  I'll compensate by not changing the subject line
above.  ;-)

and 1990 european work item. basically osi had been a telco,
slow-speed, high-error rate point-to-point copper wire design
point. Even IEEE WANs and LANs violated the OSI model.

        ESPRIT Project Nr 5341

1. Title of the project

High performance OSI protocols with multimedia support on HSLAN's and B-ISDN

2. Acronym

OSI 95

3. Origin

In the framework of the second call for proposals of ESPRIT II, the
proposal for this project has been submitted to the Commission of the
European Communities on January 1990, by the following consortium:

BULL SA (France), Coordinating contractor
ALCATEL-BELL TELEPHONE (Belgium)
ALCATEL-AUSTRIA ELIN (Austria)
INRIA (France)
OLIVETTI RESEARCH LIMITED (U.K.)
UNIVERSITE DE LIEGE (Belgium)
UNIVERSITY OF LANCASTER (U.K.)

After evaluation by the experts of the Commission, the proposal was
shortlisted for further review in April 1990.

After discussion with the Commission, the project has been accepted
for two years and with the following extended consortium:

BULL SA (France), Coordinating contractor
  (with INT (Institut National des Telecommunications) as Associae Contrator)
ALCATEL-BELL TELEPHONE (Belgium)
ALCATEL-AUSTRIA ELIN (Austria)
INRIA (France)
INTRACOM (Greece)
OLIVETTI RESEARCH LIMITED (U.K.)
UNIVERSITE DE LIEGE (Belgium)
UNIVERSIDAD POLITECNICA DE MADRID, DIT (Spain)
UNIVERSITY OF LANCASTER (U.K.)

The project started officially on October 29, 1990.

4. Summary

OSI 95 will revisit the OSI Reference Model in many of its aspects
from layer 2 up to the application level with only one objective: the
design of high performance protocols for the new communication and
application environments.  This project, which lasts only two years is
the first step towards this goal.

Today, the potential bandwidth offered by the new communication
environments such as HSLAN's MAN's and soon by the B-ISDN is
jeopardized by the existing OSI protocols of layers 3 to 7. On the
other hand, new requirements are coming from the application layer
which tries to accommodate the evolving computing environment, such as
multimedia, ODP or new distributed systems.

The objective of OSI 95 is to integrate high-speed MAN and WAN into
the OSI Reference Model and to revisit the OSI protocols of layers 3
to 7, in order to offer adequate high performance services up to the
application layer.

A first major step is the design, the formal specification and the
validation of a high performance transport - internet protocol, called
TPX, based on the standard LLC type 1 service and offering the
standard transport connection-mode service. It has been considered
important that the underlying and provided services of TPX be the
current OSI standards in order to guarantee an easy migration.
Moreover, the design of TPX will take into account as many criteria as
possible to allow later on an easy implementation on silicon.

The project will, in parallel, actively support the creation of one or
several new Work Items on "High Speed Protocols and Services" in
various standardization environments (National Associations, ECMA,
ISO, ETSI, ...), a prerequisite to the standardization of TPX.

It is however very likely that the current LLC and transport services
will be inadequate to cover all the new communication and application
environments.  Therefore, in preparation of the design of a variant of
TPX which will take place after the first two years, the second major
step of the project will be the study of the lower and upper protocols
in order to propose new LLC, transport and application services.

On the LLC side, ATM-based networks will be analyzed in order to
characterize and specify the provided services. This is an essential
step towards the integration of these networks into the OSI world
without relying on gateways which are very often performance killers.

Above the transport layer, the objective of the project is the study
of the evolving computing environment in order to define more adequate
upper layer services and protocols, and the new transport services
they will require.

Three elements of this environment have been identified and will be
studied in detail:

- multimedia : many new applications will require the handling of
multimedia objects composed of voice, text, image and video, which
require new facilities not currently defined in the OSI standards

- new distributed systems : the ESPRIT projects COMMANDOS and ISA
illustrate that trend. The current OSI protocols do not offer them a
suitable service.  Therefore we will evaluate their needs in order to
propose solutions which will be fully compatible with the OSI world

- ODP : The support environment for ODP must provide distribution
transparencies which include access, location, concurrency,
replication and migration transparency. It is clear that investigation
is needed to avoid duplication of functions between the SE-ODP and the
communication systems.

With respect to these three elements, the project will focus on high
performance issues related to the session and presentation layers, and
on the synchronization functions.

It is the intent of the project to specify as much as possible the new
protocols and services in one of the ISO languages, Estelle and LOTOS.
It is however very likely that the new communication and application
environments will require some extensions to these languages. In
particular, the need for the introduction of time in LOTOS has been
anticipated and some solutions will be studied by the project.

It is envisaged that this two year project will be continued during
another three years to achieve the global goal of the project : make
OSI an efficient solution for the systems that we will have in 1995.

5. Contacts

Jacques Levasseur, Project Manager      Tel: +33 1 39 02 48 67
BULL SA                                 Fax: +33 1 39 02 48 18
68, route de Versailles                 Telex: 697030 F
BP 3                                    E-mail:
F-78430 Louveciennes                    Jacques.Levasseur@dprdrcg.bull.fr
France

Andre Danthine, Professor               Tel: +32 41 56 26 91
UNIVERSITE DE LIEGE                     Fax: +32 41 56 29 89
Institut d'electricite B28              Telex: 41797 saunlg b
B-4000 Liege                            E-mail: danthine@BLIULG11.bitnet
Belgium

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

Can I create my own SSL key?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Can I create my own SSL key?
Newsgroups: comp.security.unix
Date: Fri, 04 May 2001 13:58:48 GMT

vek@pharmnl.ohout.pharmapartners.nl (Villy Kruse) writes:

I, as a client, need to see your server certificate so I can check you are
who you claim to be.  If you are not, then I can't trust your server for
anything.

For test environment, or a closed intranet server a homemaid certificate
is perfectly OK, but not for a public server where the identity of the
server is important.

there are a huge number of connections made in the world each day w/o
SSL where the clients pretty much trust the server (w/o needing SSL,
server certificates, CA certificates, CA policies, etc).

somebody may desire to have an SSL session to address the case of
evesdropping even when they pretty much already trust that they are
talking to who they think they are talking to (separating the two SSL
issues of 1) privacy and 2) authentication).

furthermore, there has been some amount of discussion that all of the
server certificates is so much fabrication (even the highest quality
certificates) with regard to do you really trust that you are talking
to who you think you are talking to.

For the most part, internet depends on the domain name infrastructure
to make sure that you are talking to who you think you are talking to.
A SSL server certificate tends to have a domain name that the client
cross-checks with the domain name that it is using and if they match,
supposedly the client is talking to who it thinks it is talking to.

The SSL server certificate then addresses possible integrity problems
in the domain name infrastructure.

However, who is the authoritative agency that all the SSL server
certificate issuing CAs must contact regarding domain name ownership
(when a SSL server certificate is being requested)? It is the same
domain name infrastructure that supposedly has integrity problems
necessitating the use of SSL server certificate.

At the very core, after peeling back all the CA issuing processes, all
the cryptography, all the CA practice statements, etc., CAs issuing
SSL server certificates have to contact the domain name infrastructure
as the authoratative agency with regard to domain name ownership. This
is the very same domain name infrastructure that supposedly has the
integrity problems that give rise to the necessity for issuing and
using SSL server certificates for purpose of authentication (but, in
fact, is what SSL server certificates are ultimately based on).

There is some work in the domain name infrastructure that involves
registering a public key at the same time a domain name is
registered. This would address a lot of the integrity problems that
face CAs when faced with the issue of whether they can actually trust
the domain name authoritative agencies with regard to domain name
ownership.

The interesting thing is that if public keys were registered with the
domain name infrastructure at the same time domain names are
registered (improving the integrity of the domain name infrastructure
with respect to domain name ownership so that CAs can trust the
information), then supposedly the domain name infrastructure could
server up those same keys at the same time they perform the domain
name to ip address service. In effect, the solution that allows
trusted SSL server certificates to be really depended on, would also
obsolete the need for the SSL server certificates.

Furthermore, having the domain name infrastructure register and serve
up domain name public keys would be a much more efficient SSL
implementation; effectively serves up real-time public keys (w/o the
need for even having CRLs and/or other certificate revokation/status
protocols) as well as much lower overhead (compared to all the
certificate traffic in the current SSL protocol).

random refs:
aadsm2.htm#inetpki A PKI for the Internet (was RE: Scale (and the SRV
aadsm2.htm#integrity Scale (and the SRV record)
aadsm3.htm#kiss4 KISS for PKIX. (Was: RE: ASN.1 vs XML (used to be RE: I-D ACTION :draft-ietf-pkix-scvp- 00.txt))
aadsm5.htm#asrn2 Assurance, e-commerce, and some x9.59 ... fyi
aadsm5.htm#asrn3 Assurance, e-commerce, and some x9.59 ... fyi
aepay3.htm#sslset2 "SSL & SET Query" ... from usenet group
aepay4.htm#comcert Merchant Comfort Certificates
aepay4.htm#comcert3 Merchant Comfort Certificates
aepay4.htm#comcert5 Merchant Comfort Certificates
aepay4.htm#comcert9 Merchant Comfort Certificates
aepay4.htm#comcert10 Merchant Comfort Certificates
aepay4.htm#comcert11 Merchant Comfort Certificates
aepay4.htm#comcert12 Merchant Comfort Certificates
aepay4.htm#comcert13 Merchant Comfort Certificates
aepay4.htm#comcert14 Merchant Comfort Certificates
aepay4.htm#comcert16 Merchant Comfort Certificates
aepay4.htm#dnsinteg2 Domain Name integrity problem
aepay4.htm#3dssl VISA 3D-SSL
aepay6.htm#gaopki4 GAO: Government faces obstacles in PKI security adoption
2000b.html#40 general questions on SSL certificates
2000b.html#93 Question regarding authentication implementation
2000e.html#40 Why trust root CAs ?
2000e.html#47 Why trust root CAs ?
2000e.html#50 Why trust root CAs ?
2000e.html#51 Why trust root CAs ?
2000g.html#25 SSL as model of security
2001c.html#8 Server authentication
2001c.html#9 Server authentication
2001c.html#62 SSL weaknesses

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

Can I create my own SSL key?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Can I create my own SSL key?
Newsgroups: comp.security.unix
Date: Fri, 04 May 2001 17:18:02 GMT

alun@texis.com (Alun Jones) writes:

And we've recently discovered that one of the biggest "trustworthy third
parties" doesn't even bother to check identities on a company as important
as Microsoft.  How do you know which third party is trustworthy?

note that the in the case of SSL domain name certificates ... the
company details in the certificate have almost never been verified by
anybody (requires them to actually visually inspect the SSL domain
name server certificate).

as a result, even if all the TTP (trusted third parties) always
executed the absolute highest standards with respect to corporate
information and never made a mistake ... it is relatively pointless
for SSL domain name server certificate, since nobody looks at that
information.

the information that is checked in the SSL protocol is the domain name
(i.e. does the domain name specified in the certificate match the one
that the client is using ... so the client is probably actually
talking to the server that it thinks it is talking to).

However, all CAs have to check with the domain name infrastructure as
to the true owner of a domain name prior to issuing an SSL domain name
server certificate. They have no other choice, the domain name
infrastructure is the authoratative agency with respect to domain name
ownership.

TTP CAs can do all the checking they want to with regard to corporate
names and it doesn't really mean anything (in the case of SSL domain
name server certificates) since effectively nobody looks at that
information anyway. The information that is verified in the SSL
protocol is the domain name ... and for that all TTP CAs have to rely
on the domain name infrastructure as the authoritative agency as to
the validity of domain name ownership.

However, it is integrity issues with those exact same domain name
infrastructures that supposedly is the justification for having SSL
certificates in the first place (at least as far as authentication
issues are concerned).

Now, the interesting thing is that most of the fixes for the domain
name infrastructure that would resolve integrity issues from the
standpoint can a TTP CA trust the domain name ownership authoritative
agency (i.e. the domain name infrastructure) also pretty much
eliminate justification for having SSL domain name server certificates
(in so far as authentication issues are concerned).

random refs:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

Pre ARPAnet email?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Pre ARPAnet email?
Newsgroups: alt.folklore.computers
Date: Fri, 04 May 2001 21:22:17 GMT

Bernie Cosell writes:

Obsoleting?  have 2822 and 2821 become standards already?  I thought they
were just at the beginning of the standards track....

it is one of glitches in the IETF standards process.

An RFC is published and it lists the RFCs that it "obsoletes" (check
the actual RFC and/or the rfc editor's announcement).

While the standard documented by 821 & 822 are not obsoleted (possibly
until the protocols documented by 2822 & 2821 become standards)
... RFCs 821 & 822 that document the standard are obsoleted by RFCs
2822 & 2821.

I guess the "bug" in the process gets resolved by differentiating
between the RFC that documents the standard ... and the standard
itself.

It is one of the things that I started catching early on trying to
instantiate the whole process with knowledge patterns. Postel use to
include the obsolete list as section 6.10 in STD1s. The more recent
generation of of STD1s have eliminated that section but I still
maintain the information at:
http://www.garlic.com/~lynn/rfcietff.htm

current list of Obsoleted RFCs that are standards:
http://www.garlic.com/~lynn/rfcietf.htm#obsol

verbage taken from RFC2000, STD1.

6.10.  Obsolete Protocols

Some of the protocols listed in this memo are described in RFCs that
are obsoleted by newer RFCs.  "Obsolete" or "obsoleted" is not an
official state or status of protocols.  This subsection is for
information only.

While it may seem to be obviously wrong to have an obsoleted RFC in
the list of standards, there may be cases when an older standard is in
the process of being replaced.  This process may take a year or two.

Many obsoleted protocols are of little interest and are dropped from
this memo altogether.  Some obsoleted protocols have received enough
recognition that it seems appropriate to list them under their current
status and with the following reference to their current replacement.

Thanks to Lynn Wheeler for compiling the information in this
subsection.

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

IBM Reference cards.

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Reference cards.
Newsgroups: bit.listserv.ibm-main
Date: Fri, 04 May 2001 21:30:39 GMT

Rob.Schramm@53.COM (Schramm, Rob) writes:

Ed,

I think dayglow orange.  That way it would be easier to find when I lose it
under the mass of paper on my desk.  When it comes to manuals ... I lament
the loss of paper manuals.  Sure the CD's are easier to search... but they
are tougher to flip pages. :)

Future:  Son, give up the manual.. we have you surrounded. Never! he cried
and off in the distance a tree sighed relief.

the VMSHARE Users Guide reference card (dated January 1980) comes very
close to dayglow orange.

the next closest is The Virtual Machine Products Commands reference
card (SX20-4401-0, sept. 1980) which is closer to a dayglow pink.

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

Pre ARPAnet email?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Pre ARPAnet email?
Newsgroups: alt.folklore.computers
Date: Fri, 04 May 2001 21:46:57 GMT

Bernie Cosell writes:

Obsoleting?  have 2822 and 2821 become standards already?  I thought they
were just at the beginning of the standards track....

it is actually slightly more complicated .... i typically drive my
information off the rfc editor announcements (along with the most
recent STD1) and only periodically cross-check with the actual
RFCs.

Turns out the rfc editor announcement for RFC2821 listed it as
obsoleting 821 and 974 (and updating 1123).

821 is STD 10 (along with 1869 and 1870)
974 is STD 14
1123 is STD 3 (along with 1122)

cross checking RFC2821 just now, it lists as obsoleting 821, 974, and
1869 (in addition to updating 1123). The RFC editor announcement had
missed the reference to obsoleting 1869.

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

High Level Language Systems was Re: computer books/authors (Re: FA:

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: High Level Language Systems was Re: computer books/authors (Re: FA:
Newsgroups: comp.arch,alt.folklore.computers
Date: Fri, 04 May 2001 23:00:07 GMT

Toon Moene writes:

Sigh - and I thought Ed Post ("REAL PROGRAMMERS DON'T WRITE PASCAL")
dreamed that one up:

... from someplace in the archives

                  Real Programmers Don't Eat Quiche

Real Programmers don't eat quiche.  They like Twinkies, Coke and
palate-scorching Szechwan food.

Real Programmers don't write application programs, they program right
down on the bare metal.  Application programming is for dullards who
can't do systems programming.

Real Programmers don't write specs.  Users should be grateful for
whatever they get; they are lucky to get any programs at all.

Real Programmers don't comment their code.  If it was hard to write,
it should be hard to understand and harder to modify.

Real Programmers don't document.  Documentation is for simpletons who
can't read listings or the object code from the dump.

Real Programmers don't draw flowcharts.  Flowcharts are (after all)
the illiterate's form of documentation.  Cavemen drew flowcharts; look
how much good it did for them.

Real Programmers don't read manuals.  Reliance on a reference is the
hallmark of the novice and the coward.

Real Programmers don't write in COBOL.  COBOL is for gum-chewing
dimwits who maintain ancient payroll programs.

Real Programmers don't write in FORTRAN.  FORTRAN is for wimp
engineers who wear white socks.  They get excited over finite state
analysis and nuclear reactor simulation.

Real Programmers don't write in PL/I.  PL/I is for insecure anal
retentives who can't choose between COBOL and FORTRAN.

Real Programmers don't write in BASIC.  Actually, no programmers write
in BASIC after reaching puberty.

Real Programmers don't write in APL, unless the whole program can be
written on one line.

Real Programmers don't write in LISP, because only faggot programs
contain more parentheses than actual code.

Real Programmers don't write in PASCAL, BLISS, ADA, or any of those
other sissy computer science languages.  Strong typing is a crutch for
people with weak memories.

Real Programmers' programs never work right the first time.  But if
you throw them on the machine they can be patched into working order
in "only a few" 30-hour debugging sessions.

Real Programmers never work 9 to 5.  If any Real Programmers are
around at 9 AM, it's because they were up all night.

Real Programmers don't play tennis, or any other sport which requires
a change of clothes.  Mountain climbing is OK, and Real Programmers
wear climbing boots to work in case a mountain should suddenly sprong
up in the middle of the machine room.

Real Programmers disdain structured programming.  Structured
programming is for compulsive neurotics who were prematurely
toilet-trained.  They wear neckties and carefully line up sharp
pencils on an otherwise clear desk.

Real Programmers don't like the Team Programming concept.  Unless, of
course, they are the Chief Programmer.

Real Programmers have no use for managers.  Managers are a necessary
evil.  They exist only to deal with personnel bozos, bean counters,
senior planners, and other congenital defectives.

Real Programmers scorn floating point arithmetic.  The decimal point
was invented for pansy bedwetters who are unable to "think big".

Real Programmers don't drive clapped-out Mavericks.  They prefer BMWs,
Lincolns, or pickup trucks with floor shifts.  Fast motorcycles are
highly regarded.

=========================

               Real Software Engineers Don't Read Dumps

Real software engineers don't read dumps.  They never generate them,
and on the rare occasions that they come across them, they are vaguely
amused.

Real software engineers don't comment their code.  The identifiers are
so mnemonic they don't have to.

Real software engineers don't write applications programs, they
implement algorithms.  If someone has an application that the
algorithm might help with, that's nice.  Don't ask them to write the
user interface, though.

Real software engineers eat quiche.

If it doesn't have recursive function calls, real software engineers
don't program in it.

Real software engineers don't program in assembler.  They become
queasy at the very thought.

Real software engineers don't debug programs, they verify correctness.
This process doesn't necessarily involve executing anything on a
computer, except perhaps a Correctness Verification Aid package.

Real software engineers like C's structured constructs, but they are
suspicious of it because they have heard that it lets you get "close
to the machine."

Real software engineers play tennis.  In general, they don't like any
sport that involves getting hot and sweaty and gross when out of range
of a shower.  (Thus mountain climbing is Right Out.)  They will
occasionally wear their tennis togs to work, but only on very sunny
days.

Real software engineers admire PASCAL for its discipline and Spartan
purity, but they find it difficult to actually program in.  They don't
tell this to their friends, because they are afraid it means that they
are somehow Unworthy.

Real software engineers work from 9 to 5, because that is the way the
job is described in the formal spec.  Working late would feel like
using an undocumented external procedure.

Real software engineers write in languages that have not actually been
implemented for any machine, and for which only the formal spec (in
BNF) is available.  This keeps them from having to take any machine
dependencies into account.  Machine dependencies make real software
engineers very uneasy.

Real software engineers don't write in ADA, because the standards
bodies have not quite decided on a formal spec yet.

Real software engineers like writing their own compilers, preferably
in PROLOG (they also like writing them in unimplemented languages, but
it turns out to be difficult to actually RUN these).

Real software engineers regret the existence of COBOL, FORTRAN and
BASIC.  PL/1 is getting there, but it is not nearly disciplined
enough; far too much built in function.

Real software engineers aren't too happy about the existence of users,
either.  Users always seem to have the wrong idea about what the
implementation and verification of algorithms is all about.

Real software engineers don't like the idea of some inexplicable and
greasy hardware several aisles away that may stop working at any
moment.  They have a great distrust of hardware people, and wish that
systems could be virtual at ALL levels.  They would like personal
computers (you know no one's going to trip over something and kill
your DFA in mid-transit), except that they need 8 megabytes to run
their Correctness Verification Aid packages.

Real software engineers think better while playing WFF 'N' PROOF.

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

Blame it all on Microsoft

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blame it all on Microsoft
Newsgroups: comp.os.linux.advocacy,comp.theory,comp.arch,comp.object,alt.folklore.computers
Date: Sat, 05 May 2001 02:41:56 GMT

"Glenn C. Everhart" writes:

DECnet has some interesting features: needs no ARP, has link
level access passwords. The file copy has an end to end CRC
(which saved the company I worked for a few times; memory problems
in routers were shown up by it). It supports a distributed file
system and has done so since the late 70s at least. The major
problem with Phase IV was that its addresses were too short;
you had only 16 bits for node address (broken into 64 areas
of 1024 addresses each). The USG insistence that it would deep-six
TCP/IP and force a move to OSI caused DECnet phase IV to be
started maybe 1985 (or even earlier) as an OSI implementation
but it wasn't finished for something like 10 years as it became
clear to everyone that tcp/ip was not going away anytime soon.

there has been some OSI & gosip discussion in the "Pre ARPAnet email"
thread in alt.folklore.computers

misc random refs:
http://www.garlic.com/~lynn/2001e.html#17
http://www.garlic.com/~lynn/2001e.html#18
http://www.garlic.com/~lynn/2001e.html#23
http://www.garlic.com/~lynn/2001e.html#24
http://www.garlic.com/~lynn/2001e.html#25
http://www.garlic.com/~lynn/subtopic.html#xtphsp

and blast from the past

Subject: "DEC details 18-month Phase V plan"
Source:  Network World, 9/17/90, pg 1, Tom Smith

Bud Haber, Hughes Aircraft manager of advanced network integration
o "extreme disappointment" with the 18-month rollout of DECnet Phase V
o 'I don't know how many more delays we have to go through'
  'The vendor community really <needs to> get serious about doing what
   needs to be done in opening up their systems'
  'I have formally requested of DEC over the past 6 to 8 months a
   rollout schedule, and they have stonewalled my request'

Hal Folts, Omnicom president
o 'All this stuff takes time'
  'DEC has a comprehensive plan that I'm quite impressed with'

Audrey Augun, DEC open networks systems manager
o DEC X.25 Access for Ultrix V2.0
  - 'a significant step toward Phase V'  Augun
o most Phase V products will be available in the 1st 9 months
  - X.500 Directory and Virtual Terminal support will be later
o Phase V will be done in logical segments
  'We feel it behooves us to make absolutely certain that the transition
   for those people is smooth before we announce the products'

Howard Niden, Price Waterhouse senior manager
o DECs failed to deliver key components this month as promised
o 'As late as last October...Digital was saying Phase V was on target
   for September'

Steve Wendler, Gartner Group VP
o Phase V was a victim of internal problems
  'I think the project has been mismanaged'

David Judson, Wright Patterson AFB, integration technology div. director
o the government has already mandated the Gov't OSI Profile
o 'The GOSIP train left in August, and that was last month'
  'I'm trying to be compliant'

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

Can I create my own SSL key?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Can I create my own SSL key?
Newsgroups: comp.security.unix
Date: Sun, 06 May 2001 16:26:22 GMT

bpalmer writes:

The point to having a CA is so you can't forge a SSL signature.  SSL is about privacy
AND authentication.  Using OpenSSL,  you can get the privacy part just fine.  If that's
all you're looking for,  then you're fine.  If you want your customers to be sure it's
you,  you need a CA,  a 'trusted' third party to sign the cert.  That said,  the only
secure certs would then be the one that pops up for the user to look at and confirm.
If you don't need to check and make sure that 1)  a CA YOU as the client trusts signed
the key and 2) the key points to the company you think it should,  it's pointless.  I
would much rather have the SSL dialog box popup so I can check the cert by hand...

but who does the CA contact to validate the the entity requesting an
SSL domain name server certificate really owns the domain name
(i.e. who is the authoratative agency for domain names that all TTPs
have to rely on as to whether somebody really owns the domain name
they are requesting a certificate for)?

It is the domain name infrastructure that supposedly has integrity
problems which result in the necessity for needing SSL certificates in
the first place.

random refs:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

The protocol in SSL doesn't check for whether something points to a
company name that you think it should (that is something a person has
to do by manually examining the SSL certificate ... something that can
be assumed to effectively never happen, or happen so seldom that it is
nothing to worry about).

SSL checks the domain name in the certificate against the domain name
that the client is using.

The supposedly reason for doing this is that the domain name
infrastructure has integrity problems and the client could be
mis-pointed to some other server.

However, the TTP CAs also have to check with this very same domain
name infrastructure as the authoritative agency for domain name
ownership for issuing SSL domain name server certificates.

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

Blame it all on Microsoft

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Blame it all on Microsoft
Newsgroups: comp.os.linux.advocacy,comp.theory,comp.arch,comp.object,alt.folklore.computers
Date: Sun, 06 May 2001 19:23:16 GMT

Paul Repacholi writes:

Another good source is Radia Perlmans book on networking. I suspect it
has been, ah, 'well edited' from what she originally said about some
of the stuff. Also, PhIV was almost done with much larger addresses.

some misc. other stuff. in this era, there was significant
institutional, governmental and public mind-set that things would
shortly all be OSI implementations.

One might be tempted to lump the OSI, X.500, and X.509 efforts all together

misc. additional stuff from the era

Subject: Bill Hancock on "The Controversial DECnet Phase V Route"

A very interesting article was found in the June 25th issue of
"digital review".  Bill Hancock, as most DECUS attendees would
agree, is very animated and sometimes controversial when it comes
to networking, DECnet and the surrounding issues.

A quote from the article:

"Running the DECnet Phase V routing algorithm on anything other
 than a dedicated network routing system is like asking for a
 voluntary lobotomy".

Source:   Network World, 8/6/90, pg 1, Jim Brown
Occasion: Interview with Robert McCauley, DEC's OSI migration manager

DECnet V is OSI-based and migration problems are expected
o DEC has setup a migration team to assist customers
  - headed by Robert McCauley, OSI migration manager
o DEC's Easynet:  a 54,000 node internal network
  - three subnets at engineering sites were selected as testbeds
    . Reading England, were routers are developed
    . Littleton MA, communications and networking
    . Nashua NH, VMS engineering
    . collectively, the subnets were known as TransitionNet, or T-Net
  - the subnets connections to Easynet were maintained
    . they talked to each other as well as the Phase IV Easynet
  - over the next two quarters, the main part of Easynet will go Phase V
o no production is being done on T-net as yet
  - probably at least 6 months away from running production applications
  - DECnet/Ultrix, DEC network management, and routers are on T-net, but
    VMS Phase V isnt available outside the engineering development sites

What should users be doing?
o thorough planning involving all organizations involved in the network
  - "it's imperative that people make a good business case for why they
    are migrating to Phase V...because there is some cost to it"  McCauley
o the name service has to be carefully looked at
  - its much more critical in Phase V than Phase IV
  - how many to use, what platforms, access control
  - a hierarchic approach is planned on Easynet
    . at least two servers at any reasonably sized site (about 200 sites)
    . 10 superservers at the second level, maybe as many as 20 later
      . they will keep master copies of names and node addresses
    . Phase V auto-configuration and auto-registration not planned yet
o the name server function is important due to name translation
  - simple names are mapped into physical addresses
  - its network-wide, not the VMS commands used today
o customers may need to utilize additional hardware for the function
  - as DEC has done
  - "It is also not clear, and I guess this is something that has to be
     spelled out to each customer - what the incremental cost of the
     hardware would be in a particular case"
  - some capacity for the name server is needed, but it may be offsetting
    . in DECs case the site-servers were seen as needed function anyway
    . the superservers are delta due to Phase V
  - how much extra capacity is needed will be evaluated as DEC migrates
o capacity planning is needed:  Phase V has larger addresses & packets
  - "in the worse case, it could be a 20% degradation in circuit
     performance"
  - "We do expect some degradation in throughput, at least in the first
     version of Phase V routing software"

"Some customers need the multiprotocol and multi-T1 link capabilities"
o DEC Router 2000 cannot drive more than one T1
  - "At this point I don't think we have anything that addresses that"
  - "There is a lot going on <in DEC> to come up with <competitive> routers"
  - "we have joint development plans with StrataCom, and have made some
     of our protocols available to companies like cisco and Wellfleet"

Source:  Communications Week, 9/17/90, pg 1, P. Korzeniowski & A. Knowles

Digital won't "deliver as expected" on its 3 year-old promise on OSI
o DEC had said it would have full OSI support by this year
  - DEC announced its DECnet evolutionary program September 1987
    . for DECnet Phase V, VMS, Ultrix
  - DECnet Phase V will be another 18 months
    'Our customers want us to proceed more slowly'
    . Audrey Augen, DEC open network software marketing manager
  - industry analysts say technical problems between with VMS & Phase V
    . performance and functionality both unsatisfactory
  - Ultrix, DECs Unix, was demo'ed with Phase V at a recent exhibition
o DEC has concentrated heavily on TCP/IP
  - customers don't seem alarmed
o Stanley Rose, Bankers Trust VP of technical architecture
  'Given the choice of an expedient product today and a reliable product
   next year, I will opt for the reliable product'
   - Bankers Trust has a DECnet Phase IV network with 1,000 nodes
   - they wanted to migrate directly to OSI with Phase V
     . avoiding TCP/IP
   'It looks like we'll have to install TCP/IP and we want DEC to provide it'
    I believe DECs embrace of TCP/IP is one of the reasons for the delay'

A network management tool was announced, and token-ring support wasn't
o DEC, and the Systems Center, together announced network management tool
  - a joint marketing agreement to link Net/Master and DECmcc
    . a new network management tool to challenge IBMs NetView
o token-ring support won't be available as expected either
  - the announcement was cancelled due to lack of product development funds
    . Steve Wendler, The Gartner Group analyst

random refs:
http://www.garlic.com/~lynn/subtopic.html#xtphsp
http://www.garlic.com/~lynn/subpubkey.html#sslcerts
http://www.garlic.com/~lynn/subtopic.html#radius

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

Can I create my own SSL key?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Can I create my own SSL key?
Newsgroups: comp.security.unix
Date: Wed, 09 May 2001 05:17:44 GMT

JPM@lrz.fh-muenchen.de (Juergen P. Meier) writes:

Some german banks have their certificates signed by their own CA's, coupled
with clear and simple instructions how to import this  CA's cert into user
browsers/homebanking-apps and a clear instruction/warning to be alert when
their client-app suddenly mourns about wrong cert's, it's quite a good way.
One particular bank does distribute the cert + the banks public key this way:
The Client has to show up at the bank, and identify himself with a passport.
He then recieves a smartcard with the cert and the key and a card-reader
for his pc. This way the client can trust the bank to be the bank (its
pretty hard for an attacker to take over a bank's settelment or build up
a fake agency) and the bank can trust the identity of the client (if
the clerk's have clear instructions to verify the passport/ID of the
customer).

SSL server domain name certificate is supposedly because a client
after asking the domain name infrastructure to give them the
IP-address and contacts the web-server ... it doesn't trust the domain
name infrastructure and needs additional verification that it is
really talking to the web site it thinks it is talking to.

However, what does the SSL server domain name certificate really
represent?

1) somebody applied to a CA stating they wanted a certificate
specified with their domain name,

2) the CA contacts the domain name infrastructure to authenticate the
entity requesting the SSL domain name server certificate is really entitled
to it.

3) but then, supposedly the reason that the client needs the assurance
of the ssl domain name server certificate is because the domain name
infrastructurew isn't trusted.

Some european banks are issuing client relying-party-only
certificates ... i.e. with their own self-signed CA.

The client relying-party-only certificates basically

1) contain only an account number

2) are not "identity" certificates because of the serious privacy
issues associated with certificates containing names and other
personal information.

3) are not enabled for acceptance by other relying-parties because of
the desire not to incure the liability difficulties.

The process to create these relying-party-only certificates

1) client performs the public-key registration process for their
account with the banks Registration Authority.

2) the banks Registration Authority does the standard stuff and passes
off to the banks Certification Authority

3) The banks Certification Authority performs the standard certification
process (validating the association of the client to the account number)

4) The banks Certification Auhtority generates a relying-party-only
certificate for the client containing the client's account number and
public key

5) The banks Certification Authority saves a copy of the
relying-party-only certificate in the client's account record

6) The banks Certification Authority returns a copy of the client's
relying-party-only certificate to the client.

7) At some point in the future, the client generates an electronic
message or transactions that contains the account number as part of
the standard information and digitally signes it with their private
key.

8) The client appends the digital signature to the electronic message
and then appends the copy of the relying-party-only certificate to the
combination of the electronic message and digital signature

9) the client takes the combined message (original electronic message,
digital signature, and copy of the relying-party-only certificate) and
transmits it to the bank

10) the bank extracts the account number from the message and
retrieves the account record which also contains the original of the
client's relying-party-only certificate.

11) the bank discards the copy of the relying-party-only certificate
transmitted to the bank by the client and uses the original of the
relying-party-only certificate just read (instead of the superfluous
copy transmitted by the client).

12) using the public key in the original of the client's
relying-party-only certificates (resident in the client's account
record), the bank verifies the client's digital signature
... validating the correctness of the message and authenticating the
sender of the message.

The assertion is that

a) the client when sending signed messages to the bank can improved
the payload weight and transmission throughput by compressing the copy
of their relying-party-only certificate to zero bytes (using a
technique called field compression)

b) since it can be shown that the client will alwas perform field
compression on the copy of client's relying-party-only certificate
prior to transmitting it to the relying-party ... the bank's (aka
relying-party) Certification Authority can improve throughput by
precompressing the copy of the client's relying-party-only certificate
prior to returning the copy of the client. This precompressed copy of
the client's relying-party-only certificate is now only zero bytes and
makes it much more efficient compared to using a full-sized
certificate.

====================

The other explanation is that it is redundant and superfluous to
transmit a copy of a a relying-party-only certificate to the
relying-party when it is known that 1) the relying-party possesses the
original of the relying-party-only certificate and 2) the relying-party
must read the record containing the original of the relying-party-only
certificate as part of executing the message and/or transaction
service requested by the client (remember the relying-party-only
certificate contains nothing but the account number because of serious
privacy issues).

aka in a relying-party-only certification environment, it is trivially
shown that the digitally signed message a client sends to the bank
either contains a zero byte compressed certificate (using certificate
field compression) or contains no certificate at all because the bank
already has the original of the certificate.

as an aside, is there a method of determining the difference between
the lack of a transmitted certificate from a transmitted certificate
that has been compressed to zero bytes?

==========================

 certificate field compression demonsrates all fields already in the
possession of the relying party can be eliminated from the copy of the
certificate transmitted to the relying party; since the relying party
is known to contain the original of the client's relying-party-only
certificate, the assertion is that the original of the client's
relying-party-only certificate contains all the same fields that are
in the copy of the client's relying-party-only certificate. If it can
be shown that all fields in the copy of the relying-party-only
certificate are in possession of the relying party (because it
posseses the original), then all fields can be compressed from the
copy of the client's relying-party-only certificate that the client
transmits to the relying party. If all fields can be compressed from the
copy of the client's relying-party-only certificate transmitted to the
relying party, the assertion is that the resulting compression results
in a zero byte certificate appended to the message transmitted to the
relying party.

--
Anne & Lynn Wheeler   | lynn@garlic.com, http://www.garlic.com/~lynn/

Can I create my own SSL key?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Can I create my own SSL key?
Newsgroups: comp.security.unix
Date: Wed, 09 May 2001 05:24:55 GMT

Christer Palm writes:

I'm sure about that. But it's not who _you_ can trust that counts. It's
about who anyone to which you are trying to prove your identity can
trust.

note again that the basic premise justifying SSL domain name server
certificates is that the client can't really trust the domain name
infrastructure to correctly match the client up with the correct web
server.

however, the only thing that any certification authority can do when
generating a SSL domain name server certificate is to contact the
domain name infrastructure to validate that the entity requesting the
domain name certificate is the actual entity owning that certificate.

what prevents everybody in the world from requesting amazon.com?
basically they can't demonstrate they are the owner of the amazon.com
domain registered with the domain name infrastructure. The CA has no
way of prooving this one way or another ... only the domain name
infrastructure has the record prooving who the actual owner is. The
only course of action in the scenerio is for the CA to contact the
domain name infrastructure prior to issuing the SSL domain name
certificate.

This is true independent of all other factors that might be associated
with the dependability and integrity of any particular certification
authority. The TTP certification authorities, at best, can contact the
actual authority in possession prooving the assertion or binding of
information that goes into the certificate.

--
Anne & Lynn Wheeler   | lynn@garlic.com, http://www.garlic.com/~lynn/

Can I create my own SSL key?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Can I create my own SSL key?
Newsgroups: comp.security.unix
Date: Wed, 09 May 2001 05:29:32 GMT

Christer Palm writes:

Which is why certificates also carry the real name and location of the
company.

but the SSL protocol totally ignores the real name and location of the
company. effectively nobody reads and/or saves the ssl domain name
server certificates.

it is trivially easier to register totally valid "front companies"
that have nothing associated with them.

assuming that the domain name infrastructure is at risk then it is
possible to do something ... and then apply for any domain using a
perfectly valid "front company" ... and get a certificate issued with
that domain name.

--
Anne & Lynn Wheeler   | lynn@garlic.com, http://www.garlic.com/~lynn/

IBM Dress Code, was DEC dress code

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: IBM Dress Code, was DEC dress code
Newsgroups: alt.folklore.computers
Date: Wed, 09 May 2001 16:48:59 GMT

jmfbahciv writes:

I've got an IBM coffee bug which is blue and yellow! Yes, bright yellow
background. Must have been a faulty batch.

my brother use to be a regional apple rep ... he had this gimmick of
fondling and admiring ibm coffee cups at customer locations ... and
saying he just had to have one ... and would the customer just
possibly part with the cup in return for one or five apple mugs.

--
Anne & Lynn Wheeler   | lynn@garlic.com, http://www.garlic.com/~lynn/

Can I create my own SSL key?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Can I create my own SSL key?
Newsgroups: comp.security.unix
Date: Wed, 09 May 2001 17:11:56 GMT

Christer Palm writes:

The thing that I guess one should worry the most about is the
possibility of someone aquiring a certificate for a common name or
company name that is already "owned" by someone else, allowing this
person to masquerade as the valid owner (like the Microsoft/Verisign
incident). Today, this would be perfectly possible - the impostor "just"
has too fool a trusted CA different from the CA the valid owner uses
into signing their certificate. Of course, if the impostor would go to
the same CA as with whom the valid certificate is already registered,
the warning bell would hopefully go off.

there have been press-releases regarding "domain name" hijacking with
regard to somebody convincing a domain name infrastructure to change
the ip address and company name for a "domain name".

it then becomes an issue of going to a CA and using that company name.

front companies are very straight forward to setup that totally pass
all reasonable checking done by a CA

the original posting way earlier in this thread ... was that the CA (&
others) proposal for fixing the domain name infrastructure problem was
to have somebody send in both their ip address and their public key
for registration when they acquire ownership of a domain name. that
doesn't need a certificate.

then anytime somebody communicates with the domain name infrastructure
regarding their domain name ... they sign it with their private key
and send the message. again they don't need a certificate ... which
primarily is a way of distributing public key ... since the domain
name infrastructure already is in possession of the public key
registered for the domain name.

the registration of that public key then provides the basis for fixing
all sorts of domain name infrastructure problems. however, fixing the
domain name infrastructure problems .... so that a CA can rely on the
infrastructure for issuing SSL domain name server certificates
... also eliminates the reason a client needs to have an SSL domain
name server certificate in order to authenticate the web server
because it doesn't trust the domain name infrastructure.

If the domain name infrastructure is at risk ... and not only does
a client have a problem trusting it ... but also CAs have an issue
... and if CAs have an issue then also should everybody that relies on
certificates from those CAs that rely on that information.

If the domain name infrastructure is not at risk ... and/or has been
fixed so that CAs can trust it for issuing certificates ... it turns
out then that clients also can trust it ... which eliminates client
trust issues leading to them wanting SSL server certificates for
authenticating webservers (because they can't really trust the domain
name infrastructure).

So either the domain name infrastructure is at risk ... for everybody
... or it is not at risk ... but if it is not at risk ... then it is
also not at risk for everybody.

Finally, as part of eliminating integrity exposures in the domain name
infrastructure where a domain name owner registers both their
ip-address and public key (so that CAs can depend on the integrity of
the domain name infrastructure for issuing SSL domain name server
certificates) ... then it is possible for the domain name
infrastructure to distribute a registered public key at the same name
they distribute the registered ip-address as part of domain name
resolution.

So fixing the domain name infrastructure so CAs can rely on the
integrity ... not only eliminates the need for clients to need SSL
domain name server certificates for authentication ... but it also
provides a way for a much more efficient SSL setup protocol because
the client can get the public key at the same time it gets the ip-address
(a real time distribution w/o reguiring CRLs, certificates or any of
the other CA-based infrastructure gorp).

random refs:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

--
Anne & Lynn Wheeler   | lynn@garlic.com, http://www.garlic.com/~lynn/

Can I create my own SSL key?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Can I create my own SSL key?
Newsgroups: comp.security.unix
Date: Wed, 09 May 2001 17:18:39 GMT

alun@texis.com (Alun Jones) writes:

The reason the client is looking for assurance in the certificate is that it
doesn't trust the DNS entry hasn't been spoofed.  The certificate allows it
to verify that the site providing that certificate has been verified by the
trusted third party, through means _other_ than a DNS lookup, to be the
owner of that domain.

there have been instances of domain name hijacking. the only thing
that the CA can contact with regard to who actually owns a domain name
is the domain name infrastructure.

the proposal to improve the integrity of the domain name
infrastructure so that the CA can "trust" the validating of who owns
the domain name as part of issuing a SSL domain name server
certificate is to have the domain name owner to register a public key
at the same time they register the domain name.

however, improving the integrity of the domain name infrastructure (to
improve its trust for use by CAs) ... also provides the mechanism for
improving the integrity of the domain name infrastructure for
everybody in the world ... negating the desire of clients for checking
SSL domain name server certificates in order to authenticate the web
server.

The CA method of improving the integrity of the domain name
infrastructure so that CAs can trust the domain name infrastructure
for validating the owner of a domain name (as part of issuing an SSL
domain name server certificate) ... also provides the seed for
real-time, trusteed distribution of domain name public keys by the
domain name infrastructure w/o needing any of the CA certificate, CRL,
and/or other gorp. This would also significantly improve the
performance of the SSL session setup w/o needing any of the associated
certificate handling gorp.

random refs:
http://www.garlic.com/~lynn/subpubkey.html#sslcerts

--
Anne & Lynn Wheeler   | lynn@garlic.com, http://www.garlic.com/~lynn/

Where are IBM z390 SPECint2000 results?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Where are IBM z390 SPECint2000 results?
Newsgroups: comp.arch
Date: Fri, 11 May 2001 23:01:11 GMT

Sander Vesik writes:

Well, see, the problem here is the same as in security - if the potential
loss from having less RAS capability in the Unix solution is less than
the cost delta, it is pointless to buy the higher RAS system.

it is difficult to saw ... having worked on both mainframe solutions
and having done the original HA/CMP stuff (dlm, fall-over, etc) with
my wife ... both have a lot of capability.

however, the mainframe "market" has a service that captures customer
machine logs and publishes numbers for mainframe market (including
various clones so that you get to see real live comparisons).

one of the discussions at the recent dependable computing workshop was
that the "unix" (and other) vendors are somewhat resistant to give up
such information ....

random refs:
http://www.garlic.com/~lynn/subtopic.html#hacmp
http://www.garlic.com/~lynn/subtopic.html#disk
http://www.hdcc.cs.cmu.edu/
http://www.hdcc.cs.cmu.edu/may01/index.html
http://www.hdcc.cs.cmu.edu/may01/schedule.html

--
Anne & Lynn Wheeler   | lynn@garlic.com, http://www.garlic.com/~lynn/

OT: Ever hear of RFC 1149? A geek silliness taken wing

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: OT:  Ever hear of RFC 1149?  A geek silliness taken wing
Newsgroups: bit.listserv.ibm-main
Date: Fri, 11 May 2001 23:33:21 GMT

Peter.Duffy@MAIL.CO.VENTURA.CA.US (Peter Duffy) writes:

For some geek humor:

http://news.bbc.co.uk/hi/english/sci/tech/newsid_1321000/1321176.stm

some other geek humor (recently posted in alt.folklore.computers but
from early 80s)
 http://www.garlic.com/~lynn/2001e.html#31

in general the ref'ed RFC is in long hallowed tradition of april 1st RFCs

go to
http://www.garlic.com/~lynn/rfcietff.htm

select RFCs listed by term and scroll down to "april1" ... aka

3092 3091 2795 2551 2550 2549 2325 2324 2323 2322 2321 2100 1927 1926 1925
1924 1776 1607 1606 1605 1437 1313 1217 1149 1097 852 748

misc. other
http://www.garlic.com/~lynn/2001d.html#51
http://www.garlic.com/~lynn/2001e.html#23

--
Anne & Lynn Wheeler   | lynn@garlic.com, http://www.garlic.com/~lynn/

Can I create my own SSL key?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Can I create my own SSL key?
Newsgroups: comp.security.unix
Date: Sat, 12 May 2001 06:31:31 GMT

alun@texis.com (Alun Jones) writes:

You still need CRL - after all, if I register example.com, and get my
private key and certificate, and then my payments lapse, and someone else
buys example.com, there are now two people with certificates saying they own
example.com.  The first one has to be revoked.

no, the domain name infrastructure handles all that ... there is
real-time, online distributed query ... with local caching that have
"time-outs".

in the CA case .... it creates (effectively) replicated, R/O
distributed copies (originally primarily for offline situations) with
very long "time-outs" (aka a certificate is logical a R/O, replicated
cached copy of the database entry at the CA ... the CA uses CRLs to
distribute the equivalent of "cache" invalidation signals because the
lifetimes of the cached copies are on the order of a year).

the domain name infrastructure supports real-time, online, queries,
with distributed cached copies ... but with typical time-outs on the
order of minutes to hours. as a result, online queries return to the
master database much more frequently than typical CRLs would be
distbributed (if CRLs for the general SSL domain name server
certificate scenerio was something other than somebody's dream).

For the general, SSL domain name server certificate case, the issue of
CRLs are purely hypothetical.  Furthermore, for the general SSL domain
name server certificate case, in theory (again ... these CRL things
are purely hypothetical in these cases) ... all CAs issuing SSL domain
name server certificates would need to have their CRLs reach all
clients in the world that potentially could be remotely interested in
contacting the servers in question.

Lets say there are on the order of 100 million clients in the world
which could possibly wish to contact servers that make use of SSL
domain name server certificates ... and lets say that there are
possibly 20 CAs in the world that issue SSL domain name server
certificates ... and purely for arguments sake lets assume that these
(non-existant) CRLs were distributed once a day by each of these 20
CAs to each of the 100 million possible clients in the world. We are
now talking about traffic on the order of some really major spamming.

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

Where are IBM z390 SPECint2000 results?

From: Anne & Lynn Wheeler <lynn@garlic.com>
Subject: Re: Where are IBM z390 SPECint2000 results?
Newsgroups: comp.arch
Date: Sat, 12 May 2001 06:40:20 GMT

nmm1@cus.cam.ac.uk (Nick Maclaren) writes:

Now, this balance is different between the HPC area and the
'transaction processing' area, but even there I have reason to
believe that hardware failures have not dominated over software
ones since the 1970s.  At the high end, which meant mainframes
until recently, of course.

a quote from one of the major financial transaction processing
services a couple years ago was that they had 100% availability for
over six years which they attributed primarily to

• IMS hot-standby
• automated operator

random ref:
http://www.garlic.com/~lynn/2001d.html#70

however, my original point about industry reporting services was that
the existance of such an industry reporting service (for hardware
failures, downtime, soft failures, etc) is indicative of the
importance that the customers in the market segment place on
availability (i.e. they need metrics in order to make informed
decisions) ... conversely, the lack of such a service may indicate
that the market segment is still maturing.

--
Anne & Lynn Wheeler   | lynn@garlic.com -  http://www.garlic.com/~lynn/

VM/370 Resource Manager