From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: April Fools Day Newsgroups: alt.folklore.computers Date: Sun, 22 Apr 2001 20:32:44 GMTjata@aepiax.net (Julian Thomas) writes:
--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/
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 GMTToon Moene writes:
--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/
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:
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:
https://www.garlic.com/~lynn/subtopic.html#hacmp
--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: "Bootstrap" Newsgroups: alt.folklore.computers Date: Mon, 23 Apr 2001 18:21:13 GMTjcmorris@jmorris-pc.MITRE.ORG (Joe Morris) writes:
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:
https://www.garlic.com/~lynn/subtopic.html#disk
--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/
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:
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
https://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:
https://www.garlic.com/~lynn/2000c.html#9
https://www.garlic.com/~lynn/2000c.html#56
https://www.garlic.com/~lynn/2000c.html#77
--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: SIMTICS Newsgroups: alt.os.multics Date: Tue, 24 Apr 2001 01:13:04 GMTehrice@his.com (Edward Rice) writes:
copied from a posting
https://www.garlic.com/~lynn/2000b.html#8
--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/
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 GMTKilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:
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, https://www.garlic.com/~lynn/
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 GMTKilgallen@eisner.decus.org.nospam (Larry Kilgallen) writes:
for instance ... one of the things I did as undergraduate on CP/67 was implement all the TTY/ASCII terminal support which was incorporated 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, https://www.garlic.com/~lynn/
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 GMTMichael Lyle writes:
random ref:
https://www.garlic.com/~lynn/submain.html#360pcm
--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/
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 GMTjmaynard@CONMICRO.CX (Jay Maynard) writes:
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, https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: SIMTICS Newsgroups: alt.os.multics Date: Wed, 25 Apr 2001 23:27:41 GMTAnne & Lynn Wheeler writes:
https://www.garlic.com/~lynn/2000b.html#62
--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/
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 GMTCharles Richmond writes:
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, https://www.garlic.com/~lynn/
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 GMTJan Vorbrueggen writes:
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?)
https://www.garlic.com/~lynn/99.html#33 why is there an "@" key?
https://www.garlic.com/~lynn/99.html#34 why is there an "@" key?
https://www.garlic.com/~lynn/99.html#212 GEOPLEX
https://www.garlic.com/~lynn/2000b.html#29 20th March 2000
https://www.garlic.com/~lynn/2000b.html#43 Migrating pages from a paging device (was Re: removal of paging device)
https://www.garlic.com/~lynn/2000b.html#67 oddly portable machines
https://www.garlic.com/~lynn/2000c.html#29 The first "internet" companies?
https://www.garlic.com/~lynn/2000d.html#72 When the Internet went private
https://www.garlic.com/~lynn/2000e.html#14 internet preceeds Gore in office.
https://www.garlic.com/~lynn/2000e.html#15 internet preceeds Gore in office.
https://www.garlic.com/~lynn/2000g.html#24 A question for you old guys -- IBM 1130 information
https://www.garlic.com/~lynn/2001b.html#71 Z/90, S/390, 370/ESA (slightly off topic)
https://www.garlic.com/~lynn/2001b.html#85 what makes a cpu fast
https://www.garlic.com/~lynn/2001c.html#4 what makes a cpu fast
https://www.garlic.com/~lynn/2001c.html#5 what makes a cpu fast
--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/
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:
random refs:
https://www.garlic.com/~lynn/93.html#15 unit record & other controllers
https://www.garlic.com/~lynn/93.html#17 unit record & other controllers
https://www.garlic.com/~lynn/93.html#23 MTS & LLMPS?
https://www.garlic.com/~lynn/94.html#53 How Do the Old Mainframes
https://www.garlic.com/~lynn/95.html#4 1401 overlap instructions
https://www.garlic.com/~lynn/96.html#24 old manuals
https://www.garlic.com/~lynn/97.html#21 IBM 1401's claim to fame
https://www.garlic.com/~lynn/98.html#9 Old Vintage Operating Systems
https://www.garlic.com/~lynn/98.html#15 S/360 operating systems geneaology
https://www.garlic.com/~lynn/99.html#59 Living legends
https://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
https://www.garlic.com/~lynn/99.html#102 IBM 9020 computers used by FAA (was Re: EPO stories (was: HELP IT'S HOT!!!!!))
https://www.garlic.com/~lynn/99.html#130 early hardware
https://www.garlic.com/~lynn/2000.html#79 Mainframe operating systems
https://www.garlic.com/~lynn/2000.html#83 Ux's good points.
https://www.garlic.com/~lynn/2000b.html#77 write rings
https://www.garlic.com/~lynn/2000c.html#11 IBM 1460
https://www.garlic.com/~lynn/2000c.html#75 Does the word "mainframe" still have a meaning?
https://www.garlic.com/~lynn/2000d.html#7 4341 was "Is a VAX a mainframe?"
https://www.garlic.com/~lynn/2000d.html#34 Assembly language formatting on IBM systems
https://www.garlic.com/~lynn/2000d.html#37 S/360 development burnout?
https://www.garlic.com/~lynn/2000d.html#46 Charging for time-share CPU time
https://www.garlic.com/~lynn/2000d.html#48 Navy orders supercomputer
https://www.garlic.com/~lynn/2001.html#3 First video terminal?
https://www.garlic.com/~lynn/2001.html#11 IBM 1142 reader/punch (Re: First video terminal?)
https://www.garlic.com/~lynn/2001b.html#0 Java as a first programming language for cs students
https://www.garlic.com/~lynn/2001b.html#22 HELP
https://www.garlic.com/~lynn/2001b.html#26 HELP
https://www.garlic.com/~lynn/2001b.html#27 HELP
https://www.garlic.com/~lynn/2001b.html#36 [OT] Currency controls (was: First OS?)
https://www.garlic.com/~lynn/2001b.html#71 Z/90, S/390, 370/ESA (slightly off topic)
--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/
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 GMTDavid Brower writes:
totally random ref:
https://www.garlic.com/~lynn/95.html#13
https://www.garlic.com/~lynn/2001e.html#4
--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/
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 GMTToon Moene writes:
--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Pre ARPAnet email? Newsgroups: alt.folklore.computers Date: Mon, 30 Apr 2001 23:58:23 GMTechomko@polaris.umuc.edu (Eric Chomko) writes:
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:
https://www.garlic.com/~lynn/99.html#33 why is there an "@" key?
https://www.garlic.com/~lynn/99.html#34 why is there an "@" key?
https://www.garlic.com/~lynn/99.html#37b Internet and/or ARPANET?
https://www.garlic.com/~lynn/99.html#39 Internet and/or ARPANET?
https://www.garlic.com/~lynn/99.html#44 Internet and/or ARPANET?
https://www.garlic.com/~lynn/99.html#112 OS/360 names and error codes (was: Humorous and/or Interesting Opcodes)
https://www.garlic.com/~lynn/99.html#114 What is the use of OSI Reference Model?
https://www.garlic.com/~lynn/99.html#115 What is the use of OSI Reference Model?
https://www.garlic.com/~lynn/99.html#212 GEOPLEX
https://www.garlic.com/~lynn/2000.html#51 APPC vs TCP/IP
https://www.garlic.com/~lynn/2000b.html#0 "Mainframe" Usage
https://www.garlic.com/~lynn/2000b.html#1 "Mainframe" Usage
https://www.garlic.com/~lynn/2000b.html#4 "Mainframe" Usage
https://www.garlic.com/~lynn/2000b.html#8 "Mainframe" Usage
https://www.garlic.com/~lynn/2000b.html#10 "Mainframe" Usage
https://www.garlic.com/~lynn/2000b.html#59 7 layers to a program
https://www.garlic.com/~lynn/2000b.html#67 oddly portable machines
https://www.garlic.com/~lynn/2000b.html#79 "Database" term ok for plain files?
https://www.garlic.com/~lynn/2000d.html#63 Is Al Gore The Father of the Internet?
https://www.garlic.com/~lynn/2000d.html#67 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2000d.html#70 When the Internet went private
https://www.garlic.com/~lynn/2000d.html#72 When the Internet went private
https://www.garlic.com/~lynn/2000e.html#15 internet preceeds Gore in office.
https://www.garlic.com/~lynn/2000e.html#18 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2000e.html#19 Is Al Gore The Father of the Internet?^
https://www.garlic.com/~lynn/2000g.html#24 A question for you old guys -- IBM 1130 information
https://www.garlic.com/~lynn/2001b.html#81 36-bit MIME types, PDP-10 FTP
https://www.garlic.com/~lynn/2001b.html#85 what makes a cpu fast
https://www.garlic.com/~lynn/2001c.html#4 what makes a cpu fast
https://www.garlic.com/~lynn/2001e.html#12 Blame it all on Microsoft
--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Pre ARPAnet email? Newsgroups: alt.folklore.computers Date: Wed, 02 May 2001 00:17:08 GMTRic Werme writes:
misc. gosip refs
https://www.garlic.com/~lynn/99.html#114 What is the use of OSI Reference Model?
https://www.garlic.com/~lynn/99.html#115 What is the use of OSI Reference Model?
https://www.garlic.com/~lynn/2000b.html#0 "Mainframe" Usage
https://www.garlic.com/~lynn/2000b.html#59 7 layers to a program
https://www.garlic.com/~lynn/2000b.html#79 "Database" term ok for plain files?
https://www.garlic.com/~lynn/2000d.html#16 The author Ronda Hauben fights for our freedom.
https://www.garlic.com/~lynn/2000d.html#43 Al Gore: Inventing the Internet...
https://www.garlic.com/~lynn/2000d.html#63 Is Al Gore The Father of the Internet?
https://www.garlic.com/~lynn/2000d.html#70 When the Internet went private
--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Pre ARPAnet email? Newsgroups: alt.folklore.computers Date: Wed, 02 May 2001 17:40:35 GMTLars Poulsen writes:
--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: SIMTICS Newsgroups: alt.os.multics Date: Thu, 03 May 2001 08:41:59 GMTBarry Margolin writes:
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
https://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 - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Pre ARPAnet email? Newsgroups: alt.folklore.computers Date: Thu, 03 May 2001 18:13:48 GMTAnne & Lynn Wheeler writes:
ref:
https://www.garlic.com/~lynn/rfcidx9.htm#2822
https://www.garlic.com/~lynn/rfcidx9.htm#2821
https://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 - https://www.garlic.com/~lynn/
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 GMTnmm1@cus.cam.ac.uk (Nick Maclaren) writes:
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 - https://www.garlic.com/~lynn/
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 GMTjohnl@iecc.com (John R Levine) writes:
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
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
https://www.garlic.com/~lynn/submain.html#360pcm
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Pre ARPAnet email? Newsgroups: alt.folklore.computers Date: Fri, 04 May 2001 05:38:15 GMTRic Werme writes:
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Pre ARPAnet email? Newsgroups: alt.folklore.computers Date: Fri, 04 May 2001 05:49:54 GMTRic Werme writes:
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).
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Pre ARPAnet email? Newsgroups: alt.folklore.computers Date: Fri, 04 May 2001 06:13:00 GMTRic Werme writes:
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.
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
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 GMTvek@pharmnl.ohout.pharmapartners.nl (Villy Kruse) writes:
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 - https://www.garlic.com/~lynn/
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 GMTalun@texis.com (Alun Jones) writes:
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:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Pre ARPAnet email? Newsgroups: alt.folklore.computers Date: Fri, 04 May 2001 21:22:17 GMTBernie Cosell writes:
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:
https://www.garlic.com/~lynn/rfcietff.htm
current list of Obsoleted RFCs that are standards:
https://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 - https://www.garlic.com/~lynn/
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 GMTRob.Schramm@53.COM (Schramm, Rob) writes:
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 - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Pre ARPAnet email? Newsgroups: alt.folklore.computers Date: Fri, 04 May 2001 21:46:57 GMTBernie Cosell writes:
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 - https://www.garlic.com/~lynn/
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 GMTToon Moene writes:
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 - https://www.garlic.com/~lynn/
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:
misc random refs:
https://www.garlic.com/~lynn/2001e.html#17
https://www.garlic.com/~lynn/2001e.html#18
https://www.garlic.com/~lynn/2001e.html#23
https://www.garlic.com/~lynn/2001e.html#24
https://www.garlic.com/~lynn/2001e.html#25
https://www.garlic.com/~lynn/subnetwork.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 - https://www.garlic.com/~lynn/
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 GMTbpalmer writes:
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:
https://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 - https://www.garlic.com/~lynn/
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 GMTPaul Repacholi writes:
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 canceled due to lack of product development funds
. Steve Wendler, The Gartner Group analyst
random refs:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
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 GMTJPM@lrz.fh-muenchen.de (Juergen P. Meier) writes:
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, https://www.garlic.com/~lynn/
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 GMTChrister Palm writes:
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, https://www.garlic.com/~lynn/
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 GMTChrister Palm writes:
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, https://www.garlic.com/~lynn/
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 GMTjmfbahciv writes:
--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/
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 GMTChrister Palm writes:
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:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/
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 GMTalun@texis.com (Alun Jones) writes:
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:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/
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 GMTSander Vesik writes:
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:
https://www.garlic.com/~lynn/subtopic.html#hacmp
https://www.garlic.com/~lynn/subtopic.html#disk
http://www.hdcc.cs.cmu.edu/
https://web.archive.org/web/20011004023230/http://www.hdcc.cs.cmu.edu/may01/index.html
https://web.archive.org/web/20011004023230/http://www.hdcc.cs.cmu.edu/may01/schedule.html
--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/
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 GMTPeter.Duffy@MAIL.CO.VENTURA.CA.US (Peter Duffy) writes:
in general the ref'ed RFC is in long hallowed tradition of april 1st RFCs
go to
https://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
https://www.garlic.com/~lynn/2001d.html#51
https://www.garlic.com/~lynn/2001e.html#23
--
Anne & Lynn Wheeler | lynn@garlic.com, https://www.garlic.com/~lynn/
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 GMTalun@texis.com (Alun Jones) writes:
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-existent) 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 - https://www.garlic.com/~lynn/
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 GMTnmm1@cus.cam.ac.uk (Nick Maclaren) writes:
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 - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: VM/370 Resource Manager Newsgroups: alt.folklore.computers Date: Sat, 12 May 2001 06:57:16 GMT25 years old.
much of the work i had done while undergraduate in the '60s and was incorporated into CP/67 Release 3.1 and 3.2. It was dropped in the CP/67 to VM/370 conversion ... and then re-introduced.
a couple of the things in getting it released
1) they told me that the company had yet to charge for SCP (aka kernel) softwoare ... there had been fee licenses for application software but this was going to be the first case of fee licenses for operating system software. I got to spend six months off and on with business practices and pricing people formulating how the company would price for operating system software
2) a automated benchmarking methodology was developed as part of the resource manager and over 2000 benchmarks were performed taking three months elapsed time in calibrating and verifying the resource manager.
related information:
https://www.garlic.com/~lynn/subtopic.html#wsclock
https://www.garlic.com/~lynn/subtopic.html#fairshare
following is off a "blue letter" wall plaque
VM/370 Resource Management PRPQ Is Announced
5799-ARQ (PRPQ P09006)
The VM/370 Resource Management PRPQ consists of a series of
modifications to the VM/370 control program. The PRPQ objective is to
improve VM/370 resource management for the larger VM/370 users (Model
155 II and above with one megabyte or more of storage). Based on the
workload and options selected by the installation, problem state
throughput and terminal response time for interactive transactions can
be expected to improve. It is also expected that the system will be
able to drive larger number of interactive terminals.
Highlights
Enhancements are made to VM/370 in these areas:
Scheduling ALgorithm. A fair share approach to distribute the
resources of the system equally among the users with improved
interactive performance on trivial commands.
Page Migration. Designation of preferred paging areas on DASD with
migration to other devices is based on how long the pages are unused.
Swaptable Migration. Seldom used segment tables are swapped to DASD
thereby freeing up main storage.
Reset Pages and Time Stamp Segments. The working set algorithm
improves page selection, while time stamping facilitates page
migration and swaptable migration.
Working Set Estimate. Dynamically adjusted multiprogramming levels are
achieved by periodic evaluation of total system performance based on
feedback control.
Fast Redispatch Extension. The number of cases where fast redispatch
implementation is used after privileged instruction simulation and I/O
interruptions are increased.
Enable Window. It increases the extent to which VM/370 runs enabled and
thus can accept I/O and external interruptions
Set Favored Extension. The specification of multiple users with the
set favored percent option is provided.
Indicate Command Extension. Additional performance status data is made
available to the systems performance evaluation routine.
Selective Path Length Reductions.
Publications. Documentations consists of updates to the VM/370 User's
Guide, a programmer and system logic guide, and an installation guide
contained on the distribution tape as Conversational Monitor System
(CMS) Disk Dump print files. A memo will be provided with each tape,
containing a description of the contents, and instructions for its
used.
Marking Information. Regional VM/370 support representatives have been
provided with VM/370 Resource Management PRPQ documanation and can
provide marketing and assistance.
The monthly charge of $850. Programming service classification is
A. Planned availability is July 30, 1976, and it will be distributed
as a sparately orderable tape from PID. Pre-installation test is two
months.
The VM/370 Resource Management PRPQ is designed to a base of VM/370
Release 3. Program update services will be available with every third
VM/370 program level change (PLC) from the initial PRPQ release.
Education. Will be made available on an RPQ basis
Ordering Information. Is on the reverse side.
J. M. Henson
Vice President Market Planning
Announced via ITPS, see Memorandom to Branch Managers B76-72
Release Date: May 11, 1976
Distribution: DP managers, marketing representatives, system
engineers, and administrative account specialists
FE managers and programing support representatives
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
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 07:48:43 GMTalun@texis.com (Alun Jones) writes:
in the domain name case, an entity generates their public/private key, somehow obtains a IP-address and then registers the public key and the IP-address with the domain name infrastructure for their domain name. The domain name infrastructure doesn't send back anything (much).
Other relying parties wishing to communicate with the domain name ... then ask ask the domain name infrastructure for the IP-address for the specific domain (they can't ask the domain name owner, because they don't yet have the domain name owner's IP-address in order to talk to them). However, the domain name infrastructure is perfectly capable of (and does) returning additional information (besides IP-address) associated with the domain name. In the projected case of registering the public key, the domain name infrastructure could return both the IP-address and the public key as part of a real-time query.
There are no certificates ... and therefor there is no requirement for a certificate invalidation protocol (domain name infrastructure supplies ip-address information today w/o the need for certificates).
The domain name infrastructure already handles the case where somebody else obtains the domain name "example.com" and registers a different IP-address. The case of all the relying parties with the "old" IP-address for the old owner of "example.com" is pretty mute since any caching of the information has time-out typically on the order of minutes or hours. New queries by relying parties get the new ip-address. If a public key was registered for the domain, the domain name infrastructure could also return the appropriate public key in response to a real time query.
The primary difference between the CA design point and the domain name infrastructure ... is that the domain name infrastructure is "online" and the CA design point is for "offline" relying parties ... i.e. relying parties that need to have something verified and they are unable to perform an online connection to the CA in order to get the real time information. Instead, for these offline relying parties, "certificates" act as a "stand-in" for being able to contact the CA directly in real-time.
By comparison, the domain name infrastructure is an "online" design point, relying parties directly contact the domain name infrastructure in real time for information. There is no need for having the (frequently stale) information packaged up into replicated offline packages (aka certificates) and sprayed all over the universe (with the CA having absolutely no idea where all the possible places the stale, replicated information packages might exist).
Furthermore, with the CA having absolutely no idea where all the possible places the stale, replicated information packages (aka certificates) might have propagated to ... in order to perform an information/cache invalidation (aka CRL), it needs to broadcast a message to all possible places. In the case that such a CRL strategy was really ever to come into existance for the general SSL domain name server certificate case, it would probably be mistaken for one of the largest spamming events ever concocted (i.e. attempting to transmit the invalidation information to every potential client relying party in the world).
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Where are IBM z390 SPECint2000 results? Newsgroups: comp.arch Date: Sat, 12 May 2001 07:56:27 GMTnmm1@cus.cam.ac.uk (Nick Maclaren) writes:
automated operator tends to have a set of heuristics that intercept operator requests and attempt to provide automated action for recognizable situations.
the automated operator operations don't tend to be of the nature of handling hardware and/or (a lot of) software failures ... but more mundane stuff. the issue with automated operator is that human mistakes performing mundane tasks were resulting in service failures (i.e. hardware could be perfect, and majority of the software could be perfect ... but service could still be interrupted because of human error).
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Where are IBM z390 SPECint2000 results? Newsgroups: comp.arch Date: Sat, 12 May 2001 14:32:33 GMTAnne & Lynn Wheeler writes:
An IT organization is likely to need pretty good metrics about various component & system availability before signing up for some penalty clauses (for instance calculate risk/probability associated with making a profit or not .... or whether the in-house IT executives get incentive bonus that year).
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
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 16:24:00 GMTalun@texis.com (Alun Jones) writes:
and
The Shocking Truth About Digital Signatures and Internet Commerce
http://www.smu.edu/~jwinn/shocking-truth.htm
https://web.archive.org/web/20020403012718/faculty.smu.edu/jwinn/
NOTE moved to
http://www.law.washington.edu/Faculty/Winn/Publications/The%20Emperor's%20New%20Clothes.htm
Conventional Public Key Infrastructure:
An Artefact Ill-Fitted to the Needs of the Information Society
http://www.anu.edu.au/people/Roger.Clarke/II/PKIMisFit.html
The Fundamental Inadequacies of Conventional Public Key Infrastructure
http://www.anu.edu.au/people/Roger.Clarke/II/ECIS2001.html
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: "IP Datagrams on Avian Carriers" tested successfully Newsgroups: alt.folklore.computers Date: Mon, 14 May 2001 16:19:10 GMTehrice@his.com (Edward Rice) writes:
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)
https://www.garlic.com/~lynn/2001e.html#31
in general the ref'ed RFC is in long hallowed tradition of april 1st RFCs
go to
https://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
https://www.garlic.com/~lynn/2001d.html#51
https://www.garlic.com/~lynn/2001e.html#23
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
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,alt.folklore.computers Date: Mon, 14 May 2001 16:44:57 GMTgsduran@FRESNO.K12.CA.US (Gary Duran) writes:
random ref:
https://www.garlic.com/~lynn/2001e.html#45
two other characteristics
1) for people that remember muscle cars of the '60s and the slogan "The Racer's Edge" ... the module implementing the dynamic adaptive feedback control stuff was DMKSTP (all VM/370 modules carried the 3-letter prefix DMK).
2) dynamic adaptive code tuned the operation to load and configuration in real time; however some of the product people insisted that because the MVS SRM had all these tuning parameters so that system programmers could attenpt to manually tune a system to the load and ocnfiguration ... that the VM/370 RM needed similar tuning parameters before it could be shipped. So a couple of tuning parameters were implemented in a module called DMKSRM. Now, since it is 25 years later ... all the code was published for the implementation and all the formulas for how the parameters worked were published however nobody caught the joke (within the last couple years, I ran into some recent graduate claiming to have been taught the "wheeler scheduler"). in dynamica adaptive feedback control algorithms, besides the straight-forward algorithm there is something called degrees of freedom ... basically bounds on the range that values can take. In any case, the manual tuning parameters had significantly lower degrees of freedom than the dynamic adaptive parameters in the formulas (to some extent a system programmer could do no wrong since the dynamic adaptive code could compensate for most of what they might try and do).
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Pre ARPAnet email? Newsgroups: alt.folklore.computers Date: Mon, 14 May 2001 17:07:28 GMTBernie Cosell writes:
new STD1 (2800) is out today with new format for some sections ... note verbage for STD4, STD10 and a couple others.
-------- Internet Official Protocol Standards 2800 1
-------- Assigned Numbers 1700 2
-------- Requirements for Internet Hosts - Communication 1122 3
Layers
-------- Requirements for Internet Hosts - Application 1123 3
and Support
-------- [Reserved for Router Requirements. See RFC 1812] 4
IP Internet Protocol 791 5
ICMP Internet Control Message Protocol 792 5
-------- Broadcasting Internet Datagrams 919 5
-------- Broadcasting Internet datagrams in the presence 922 5
of subnets
-------- Internet Standard Subnetting Procedure 950 5
IGMP Host extensions for IP multicasting 1112 5
UDP User Datagram Protocol 768 6
TCP Transmission Control Protocol 793 7
TELNET Telnet Protocol Specification 854 8
TELNET Telnet Option Specifications 855 8
FTP File Transfer Protocol 959 9
SMTP [Reserved for Simple Mail Transfer Protocol (SMTP). 10
See RFC 2821.]
SMTP-SIZE SMTP Service Extension for Message Size Declaration 1870 10
MAIL [Reserved for Internet Message Format. See RFC 11
2822.]
NTP [Reserved for Network Time Protocol (NTP). See 12
RFC 1305.]
DOMAIN Domain names - concepts and facilities 1034 13
DOMAIN Domain names - implementation and specification 1035 13
DNS-MX [Was Mail Routing and the Domain System (RFC974). 14
Now Historic.]
SNMP Simple Network Management Protocol (SNMP) 1157 15
SMI Structure and identification of management 1155 16
information for TCP/IP-based internets
Concise-MI Concise MIB definitions 1212 16
MIB-II Management Information Base for Network Management 1213 17
of TCP/IP-based internets:MIB-II
EGP [Was Exterior Gateway Protocol (RFC904). Now 18
Historic.]
NETBIOS Protocol standard for a NetBIOS service on 1001 19
a TCP/UDP transport: Concepts and methods
NETBIOS Protocol standard for a NetBIOS service on 1002 19
a TCP/UDP transport: Detailed specifications
ECHO Echo Protocol 862 20
DISCARD Discard Protocol 863 21
CHARGEN Character Generator Protocol 864 22
QUOTE Quote of the Day Protocol 865 23
USERS Active users 866 24
DAYTIME Daytime Protocol 867 25
TIME Time Protocol 868 26
TOPT-BIN Telnet Binary Transmission 856 27
TOPT-ECHO Telnet Echo Option 857 28
TOPT-SUPP Telnet Suppress Go Ahead Option 858 29
TOPT-STAT Telnet Status Option 859 30
TOPT-TIM Telnet Timing Mark Option 860 31
TOPT-EXTOP Telnet Extended Options: List Option 861 32
TFTP The TFTP Protocol (Revision 2) 1350 33
RIP1 [Was Routing Information Protocol (RIP). Replaced 34
by STD 56.]
TP-TCP ISO transport services on top of the TCP: 1006 35
Version 3
IP-FDDI Transmission of IP and ARP over FDDI Networks 1390 36
ARP Ethernet Address Resolution Protocol: Or converting 826 37
network protocol addresses to 48.bit Ethernet
address for transmission on Ethernet hardware
RARP Reverse Address Resolution Protocol 903 38
-------- [Was BBN Report 1822 (IMP/Host Interface). Now 39
Historic.]
IP-WB Host Access Protocol specification 907 40
IP-E Standard for the transmission of IP datagrams 894 41
over Ethernet networks
IP-EE Standard for the transmission of IP datagrams 895 42
over experimental Ethernet networks
IP-IEEE Standard for the transmission of IP datagrams 1042 43
over IEEE 802 networks
IP-DC DCN local-network protocols 891 44
IP-HC Internet Protocol on Network System's HYPERchannel: 1044 45
Protocol specification
IP-ARC Transmitting IP traffic over ARCNET networks 1201 46
IP-SLIP Nonstandard for transmission of IP datagrams 1055 47
over serial lines: SLIP
IP-NETBIOS Standard for the transmission of IP datagrams 1088 48
over NetBIOS networks
IP-IPX Standard for the transmission of 802.2 packets 1132 49
over IPX networks
ETHER-MIB Definitions of Managed Objects for the Ethernet- 1643 50
like Interface Types
PPP The Point-to-Point Protocol (PPP) 1661 51
PPP-HDLC PPP in HDLC-like Framing 1662 51
IP-SMDS Transmission of IP datagrams over the SMDS Service 1209 52
POP3 Post Office Protocol - Version 3 1939 53
OSPF2 OSPF Version 2 2328 54
IP-FR Multiprotocol Interconnect over Frame Relay 2427 55
RIP2 RIP Version 2 2453 56
RIP2-APP RIP Version 2 Protocol Applicability Statement 1722 57
SMIv2 Structure of Management Information Version 2578 58
2 (SMIv2)
CONV-MIB Textual Conventions for SMIv2 2579 58
CONF-MIB Conformance Statements for SMIv2 2580 58
RMON-MIB Remote Network Monitoring Management Information 2819 59
Base
SMTP-Pipe SMTP Service Extension for Command Pipelining 2920 60
ONE-PASS A One-Time Password System 2289 61
--
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Pre ARPAnet email? Newsgroups: alt.folklore.computers,bit.listserv.ibm-main Date: Mon, 14 May 2001 17:40:51 GMTAnne & Lynn Wheeler writes:
rfc3, rfc5, rfc6, rfc21, rfc23, rfc24, rfc25, rfc27, rfc28, rfc29, rfc30, rfc344, rfc567, rfc593
RFC6 ... discussion about BB&N providing character code conversion. This isn't an easy problem (in many cases). While undergraduate in '68 I had put TTY/ASCII support into CP/67 ... which was incorporated and distributed as part of the standard release. There were some codes that it was very difficult to provide symmetric conversion for ... at least in one case, I tried to map characters in ASCII to valid EBCDIC because I needed some character in ASCII. On the 2741, "at"-sign and "cent"-sign were on the same key and CP/67 had a convention that used (lowercase) "at"-sign (in line editing) for character delete and "cent"-sign for line delete. The TTY keyboard didn't have cent-sign ... so I mapped (been a number of years) "left" bracket.
Then in late '68 because of various difficiences in the mainframe 2702 terminal controller, four of us started a project to build the first mainframe PCM control unit using Interdata3s. Had to build our own channel attach card that attached the Interdata3 to the mainframe I/O channel. An emulated line-scanner was built in the Interdata3 that was targeted at supporting both dynamic line-speed recognition as well as dynamic terminal-type recognition (as part of the original TTY support in CP/67, I had expanded the existing dynamic terminal type recognition to TTY ... however 2702 had a difficiency that while the line-scanner could be changed for each line ... the hardware oscillator setting the line speed was hard wired).
random refs:
https://www.garlic.com/~lynn/submain.html#360pcm
Network Working Note Steve Crocker, UCLA RFC-6 10 April 1969 CONVERSATION WITH BOB KAHN I talked with Bob Kahn at BB&N yesterday. We talked about code conversion in the IMP's, IMP-HOST communication, and HOST software. BB&N is prepared to convert 6, 7, 8, or 9 bit character codes into 8-bit ASCII for transmission and convert again upon assembly at the destination IMP. BB&N plans a one for one conversion scheme with tables unique to the HOST. I suggested that places with 6-bit codes may also want case shifting. Bob said this may result in overflow if too many case shifts are necessary. I suggested that this is rare and we could probably live with an overflow indication instead of a guarantee. With respect to HOST-IMP communication, we now have a five bit link field and a bit to indicate conversion. Also possible is a 2-bit conversion indicator, one for converting before sending and one for converting after. This would allow another handle for checking or controlling the system.--
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: line length (was Re: Babble from "JD" <dyson@jdyson.com>) Newsgroups: alt.folklore.computers Date: Tue, 15 May 2001 21:01:00 GMTSteve O'Hara-Smith writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Pre ARPAnet email? Newsgroups: alt.folklore.computers,bit.listserv.ibm-main Date: Tue, 15 May 2001 21:09:49 GMTjcmorris@jmorris-pc.MITRE.ORG (Joe Morris) writes:
random ref:
https://www.garlic.com/~lynn/submain.html#360pcm
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Need explanation of PKI and Kerberos Newsgroups: comp.security.misc Date: Wed, 16 May 2001 13:46:02 GMT"Philip Tanner" writes:
issues about cross-domain operation for either kerberos or PKI come down to business process things like trust. i actually attended some sessions at MIT circa 88/89 discussing cross-domain kerberos ... and the basic problem wasn't so much technical ... but business trust issues.
many people when they think of PKI ... typically think of SSL. A "real" PKI is typically considered to have registration, certification, trusted-third parties, x.509 certificates, certificate management, revokation, etc. Currently operating SSL infrastructure only has a subset of what is considered (upper-case) PKI ... aka missing revokation and other characteristics required of a business infrastructure ... reference recent "Can I create my own SSL key" thread in comp.security.unix ng.
random refs:
https://www.garlic.com/~lynn/2001e.html#43
https://www.garlic.com/~lynn/2001e.html#46
another well known public key infrastructure (i.e. lower-case pki not upper-case) is PGP with support in many mail systems.
part of the issue is that "trust" is a somewhat ephemeral issue (especially cross-domain). For some people the existance of a tangable defined object like a x.509 certificate may provide a degree of added comfort ... not necessarily justified ... as in some of the SSL discussions:
https://www.garlic.com/~lynn/subpubkey.html#sslcerts
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: line length (was Re: Babble from "JD" <dyson@jdyson.com>) Newsgroups: alt.folklore.computers Date: Wed, 16 May 2001 14:02:11 GMTjmfbahciv writes:
circa 70 or so, source update system for cp/67-cms was developed that would put update id/number in cols 64-71 (i.e. tail-end of the comment area) of the source code . Starting with VM/370 official "fixes" were assigned sequential fix-id number .... and the number would be placed in cols 64-71 of the source. I've seen some recent "fix-ids" in the 62,xxx range (some 62,000 fixes over approx. 30 year lifetime).
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Wireless Interference Newsgroups: alt.folklore.computers Date: Wed, 16 May 2001 16:14:02 GMTAlexandre Pechtchanski writes:
https://www.garlic.com/~lynn/2001e.html#53
https://www.garlic.com/~lynn/2001e.html#55
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Design (Was Re: Server found behind drywall) Newsgroups: alt.folklore.computers Date: Wed, 16 May 2001 20:56:41 GMTSteve O'Hara-Smith writes:
random refs:
https://www.garlic.com/~lynn/aadsm5.htm#asrn4
https://www.garlic.com/~lynn/aepay6.htm#erictalk
https://www.garlic.com/~lynn/
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Estimate JCL overhead Newsgroups: bit.listserv.ibm-main Date: Thu, 17 May 2001 03:18:47 GMTjlender@HOTMAIL.COM (jim lender) writes:
then do something similar with REXX execs for a equivalent series of "null" steps.
long ago and far away
https://www.garlic.com/~lynn/2000d.html#50
https://www.garlic.com/~lynn/99.html#81
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Estimate JCL overhead Newsgroups: bit.listserv.ibm-main Date: Thu, 17 May 2001 15:00:36 GMTbdissen@DISSENSOFTWARE.COM (Binyamin Dissen) writes:
if getting the total counts before & after the run prooves too difficult there is a cludge shortcut that i've used a number of times over the years.
say the dummy job stream takes 5-10 minutes (i.e. E=10 minutes) elapsed time to run.
test is similar as before idle (single) processor (real, lpar and/or virtual machine).
create tight-loop compute bound background job that takes E+5 cpu cycles and runs in E+5 elapsed time (aka 5 minutes longer than the test run). start compute-bound in the background (worst priority you can assign) start the dummy job stream as soon as the cpu is pegged.
increase in the elapsed time for the tight-loop compute bound job is the cpu used by the system for processing dummy job stream.
previous post re: above from long ago and far away
https://www.garlic.com/~lynn/2001e.html#60
https://www.garlic.com/~lynn/2000d.html#50
https://www.garlic.com/~lynn/99.html#81
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Modem "mating calls" Newsgroups: alt.folklore.computers Date: Thu, 17 May 2001 17:47:01 GMTLars Poulsen writes:
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Modem "mating calls" Newsgroups: alt.folklore.computers Date: Thu, 17 May 2001 17:54:37 GMTAnne & Lynn Wheeler writes:
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Design (Was Re: Server found behind drywall) Newsgroups: alt.folklore.computers Date: Thu, 17 May 2001 20:57:39 GMTswaim writes:
it also met that i would take a job in the IT support group rather than be in development or RSM ... i.e. it was lot easier to get hands on the real iron when it came time for deploying something new.
i do joke about during one period I would work first shift in bldg 28 at my "official" job supporting the computing center, 2nd shift in bldg 14 supporting disk engineering (for the fun of it), and 3rd shift in bldg 90 doing a special project for STL computing center in support of IMS development ... and periodically take-off to drive up to palo alto to install new operating system at HONE. In spare time I could do email and HSDT.
random refs:
https://www.garlic.com/~lynn/subtopic.html#wsclock
https://www.garlic.com/~lynn/subtopic.html#fairshare
https://www.garlic.com/~lynn/subtopic.html#hacmp
https://www.garlic.com/~lynn/subnetwork.html#hsdt
https://www.garlic.com/~lynn/subtopic.html#disk
https://www.garlic.com/~lynn/subtopic.html#hone
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Stoopidest Hardware Repair Call? Newsgroups: alt.folklore.computers Date: Thu, 17 May 2001 23:15:28 GMTEric Sosman writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: line length (was Re: Babble from "JD" <dyson@jdyson.com>) Newsgroups: alt.folklore.computers Date: Fri, 18 May 2001 14:38:33 GMTjcmorris@jmorris-pc.MITRE.ORG (Joe Morris) writes:
The customer, to build a new kernel would "load" all the binaries into memory and the memory image would then be written to disk. The "loading" process produced a "load map" which consisted of all the associated source filenames as comments plus memory location address of all the symbols for each module. Associated filename comments in the loadmap would include date/time that the specific binary module was created followed by one line for each one of the associated source files (with date/time).
So in the mid-80s, I'm on a business trip to the Madrid Scientific Center. They have a project that is digitizing images of lots of ancient documents that were going to be made available as part of the 1492 anniversery.
While I'm there, I visit a local movie theater. The local movie theater inludes a 20 min. "short" produced at the university. In several scenes in the movie there is a wall of TV screens, all scrolling the same text across the screens at 1200 baud (around 2-6 lines/sec).
Not only do I recognize that the text is a VM/370 loadmap, but the VM/370 Release and PLC based on the names and dates of the change files (which is just barely able to catch at the speed the text is scrolling).
Many of the change files have a eight character filename suffix of the form letter, five digit number, three letters. For most fixes and/ many changes, the suffix had an incrementing number that started at zero and was incremented for each new fix/change. This started nearly 30 years ago, I recently noted that the new number fields were in the range of 62k. I'm not sure what they plan on doing when the roll-over six digits.
The same suffix also appears in the comment field of each source line
for that change file
https://www.garlic.com/~lynn/2001e.html#57
random refs:
https://www.garlic.com/~lynn/99.html#9
https://www.garlic.com/~lynn/2000g.html#36
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: line length (was Re: Babble from "JD" <dyson@jdyson.com>) Newsgroups: alt.folklore.computers Date: Fri, 18 May 2001 14:46:32 GMTAnne & Lynn Wheeler writes:
of the form: letter, five digit number, two letters ... not three.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Estimate JCL overhead Newsgroups: bit.listserv.ibm-main Date: Fri, 18 May 2001 15:03:23 GMTbrad@TOSCINTL.COM (Brad Taylor) writes:
Elapsed time can be decreased by eliminating serialization in each step involved in putting/retrieving intermediate/temp data to/from disk. Elapsed time may be further decreased if there is sufficient spare resources that get consumed by having larger number of operations running concurrently.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: line length (was Re: Babble from "JD" <dyson@jdyson.com>) Newsgroups: alt.folklore.computers Date: Fri, 18 May 2001 15:45:27 GMTjcmorris@jmorris-pc.MITRE.ORG (Joe Morris) writes:
the original implementation was done crica 1970 all in "script" (aka EXEC) processes using basic CMS components originally developed in 67/68 time-frame. Even when the additional features provided by the EXEC processes were later merged as features into the standard command components there wasn't any substantive functional improvements (possibly one of the characteristics of legacy system; if it ain't broke, don't fix it).
misc. refs at Melinda's web page
https://www.leeandmelindavarian.com/Melinda/
https://www.leeandmelindavarian.com/Melinda#VMHist
VM and the VM Community: Past, Present, and Future (includes early stuff on time-sharing, CTSS, multics, etc)
Development of 360/360 Architecture: A Plain Man's view
What Mother Never Told You About VM Service (a much more detailed description of the VM process).
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Modem "mating calls" Newsgroups: alt.folklore.computers Date: Sat, 19 May 2001 00:18:27 GMTjata@aepiax.net (Julian Thomas) writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: line length (was Re: Babble from "JD" <dyson@jdyson.com>) Newsgroups: alt.folklore.computers Date: Sat, 19 May 2001 16:03:22 GMTglass2 writes:
the "original" (cp/67) script/EXEC implementation had a process to merge parallel work/updates (done by MIT co-op student) which seemed to work pretty well. That feature got dropped in translation to VM/370.
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Stoopidest Hardware Repair Call? Newsgroups: alt.folklore.computers Date: Mon, 21 May 2001 23:39:40 GMTcbh@ieya.co.REMOVE_THIS.uk (Chris Hedley) writes:
Before they were installed it was predicted the major problem was large packet loss during heavy rain and/or snow, which never really materialized. There were a few packets lost during a blinding, white-out snow storm ... during which people were unable to get into work, but the rest of the time things ran very smoothly (once things were worked out to compensate for uneven thermal expansion of the buildings). However, nobody had predicted the sun-induced building leaning problem.
ranndom ref:
https://www.garlic.com/~lynn/94.html#23
https://www.garlic.com/~lynn/2000c.html#65
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: CS instruction, when introducted ? Newsgroups: bit.listserv.ibm-main Date: Tue, 22 May 2001 13:33:58 GMT"GerardS" writes:
Trick was getting it adopted by 370 architecture in POK. Requirement given CSC & C.A.S. for inclusion into 370 architecture was coming up with a uniprocessor application ... which spawned the programming notes for using the instruction for managing data in multi-threaded (but not necessarily multi-processor) operation. In the process, a word & double word version were generated ... changing the mnemonics to CS & CSD.
Now, hard part ... I use to have the 370 POP where it first appeared ... but possibly '73 (but it has been long time, i vaguely remember some of the architecture meetings in POK and of course the CSC work, 158mp & 168mp were announced 3/73). I don't remember any PRPQ version ... it went directly into the 370 architecture once the multi-threaded scenerio was invented. The precursor on the 360/67/65 multiprocessors was test & set ... TS.
random refs:
https://www.garlic.com/~lynn/93.html#14 S/360 addressing
https://www.garlic.com/~lynn/94.html#02 Register to Memory Swap
https://www.garlic.com/~lynn/94.html#28 370 ECPS VM microcode assist
https://www.garlic.com/~lynn/94.html#45 SMP, Spin Locks and Serialized Access
https://www.garlic.com/~lynn/97.html#19 Why Mainframes?
https://www.garlic.com/~lynn/98.html#8 Old Vintage Operating Systems
https://www.garlic.com/~lynn/98.html#16 S/360 operating systems geneaology
https://www.garlic.com/~lynn/99.html#88 FIne-grained locking
https://www.garlic.com/~lynn/99.html#89 FIne-grained locking
https://www.garlic.com/~lynn/99.html#176 S/360 history
https://www.garlic.com/~lynn/99.html#203 Non-blocking synch
https://www.garlic.com/~lynn/2000e.html#25 Test and Set: Which architectures have indivisible instructions?
https://www.garlic.com/~lynn/2000g.html#16 360/370 instruction cycle time
https://www.garlic.com/~lynn/2001b.html#33 John Mashey's greatest hits
https://www.garlic.com/~lynn/2001b.html#35 John Mashey's greatest hits
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: CS instruction, when introducted ? Newsgroups: bit.listserv.ibm-main Date: Tue, 22 May 2001 14:45:17 GMTAnne & Lynn Wheeler writes:
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Apology to Cloakware (open letter) Newsgroups: sci.crypt Date: Tue, 22 May 2001 15:36:38 GMT"Douglas A. Gwyn" writes:
after graduation, i took a job on the east coast. there were ties you could stick your finger into. people complained that sections they remember as having train speed limits of 60-80 mph were down to 15. there was one section that was called the box-car grave yard where the freight train speed limit was 5 mph (and there were still regular derailments). It had been 20 years or more since the tracks had any PM.
i seem to remember reading an article a year or so ago in ?? (possibly SJMN) about how the california PUCC was doing a tremendous job for the consumer by preventing the electronic companies from signing any long-term power supply contracts; that the PUCC had forced the california companies into only signing short-term contracts (in effect forcing them into the spot market). This worked well when there was a large surplus on the spot-market.
One problem was that it (at least) eliminated incentive for power produces to build new power production facilities (in part, much easier to get construction loans &/or float bonds for major power plant contruction projects if you have long term contracts in your hand that demonstrate demand for the new facilities).
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Stoopidest Hardware Repair Call? Newsgroups: alt.folklore.computers Date: Tue, 22 May 2001 18:18:38 GMTTerry Kennedy writes:
nsfnet-I backbone contract was merit, ibm, mci. They used ibm PC/RTs as routers with special 440kbit/sec link adapter boards ... going into IDNX switch that aggregated three 440kbit/sec links into a single T1 (1.544) out thru MCI trunks. Most/much of MCI backbone was terrestrial microwave (c-band) which is prone to some rain fade (but not nearly as bad as Ku or Ka bands). The MCI relay stations were on the order of tens of miles (not hundreds of feet in the case of infrared modem between two buildings with highway between).
as a happen chance the buildings using the infrared modem were not all that far from one of the NSFNET-I backbone sites at NCAR. The backbone room had walls of shelves supporting the PC/RTs in psuedo "rack-mount".
For the infrared T1 modem application we had multiplexor that devoted most of the T1 to data but had split off a 56kbit side channel that could be dedicated to a pair of Fireberd bit-error-testers that could be run constantly to monitor & record signal quality (bit error rate). I connected the Fireberd rs232 printer output port to RS232 port on ibm/pc and had written turbo pascal application to log the fireberd output as well as generate various summary reports.
I don't know if it affects packet-loss ... but there is a "campus" T3 collins digital radio system in south san jose. One of the links has a relay tower on the hill above bldg. 90 that sights to roof of bldg. 12. I've noticed that a number of people get "hits" on their radar detectors when crossing close to the path of the signal on the elevated section of 85 (just north of the 85/101 intersection).
random ref:
https://www.garlic.com/~lynn/2000e.html#10
https://www.garlic.com/~lynn/internet.htm
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Apology to Cloakware (open letter) Newsgroups: sci.crypt Date: Wed, 23 May 2001 00:31:26 GMTjgfunj@vgrknf.arg (wtshaw) writes:
random ref ... The thread between risk management and information security
https://www.garlic.com/~lynn/aepay3.htm#riskm
https://www.garlic.com/~lynn/aepay3.htm#riskaads
from above, the power thing still pales in comparison to the S&L.
""To date the last reported dollars I have seen for each one of us to
perform our refunding of the banks and S&L's exceeds 100K per
person. Whether you like it or not, in a rather benign interest rate
environment you will pay over 100K in your lifetime of taxpayer
dollars to pay for this bailout. The dollars are so high that they
are carried as an off balance sheet number so as not to capsize the US
budget or cause attention. At one point they exceeded $ 1
trillion. This is what I mean when I say that ALL of the moneys gained
by individuals in the asset appreciation (real estate) of the 70' &
the 80's went in one pocket and the pay-out of the costs for the S&L
industry came out of the other. The result - a zero, if not negative,
sum game. The horrifying part of all of this was that it happened over
a very benign interest rate cycle. Institutions were toast overnight
because of a short term rate spike. Today prevention and anticipation
are the order of the day and the keys to good regulations.""
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: digital signature and certificates in xml Newsgroups: comp.security.misc Date: Wed, 23 May 2001 15:19:37 GMTAndreas Krügel writes:
http://www.ietf.org/html.charters/xmldsig-charter.html
https://web.archive.org/web/20020202131149/http://www.ietf.org/html.charters/xmldsig-charter.html
http://www.w3.org/Signature/
somewhat related
http://www.w3.org/TR/NOTE-SDML/
http://www.w3.org/DSig/Overview.html
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: digital signature and certificates in xml Newsgroups: comp.security.misc Date: Wed, 23 May 2001 15:23:40 GMTAnne & Lynn Wheeler writes:
https://www.garlic.com/~lynn/8583flow.htm
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: The Mind of War: John Boyd and American Security Newsgroups: alt.folklore.military Date: Wed, 23 May 2001 19:56:35 GMTJohn Boyd's biography is out this month (some people have been waiting at least 20 years for this).
https://www.amazon.com/exec/obidos/ASIN/1560989416/qid%3D982672335/sr%3D1-2/ref%3Dsc%5Fb%5F2/107-1178249-9432548
http://search.borders.com/fcgi-bin/db2www/search/search.d2w/Details?&mediaType=Book&prodID=51998530
http://shop.barnesandnoble.com/booksearch/isbnInquiry.asp?userid=48AIUOE4N9&mscssid=HGJJJPL1NBL29GLAKTN2XNMDKHK59JM6&isbn=1560989416
some reviews:
http://www.belisarius.com/reviews_of_the_mind_of_war.htm
https://web.archive.org/web/20010606221622/http://www.belisarius.com/reviews_of_the_mind_of_war.htm
some of the above:
As a founder of the Military Reform caucus in Congress, I know John
Boyd to be the true father of military reform in America. More than a
biography, and a superb one, this book is a well deserved tribute to
an extraordinary patriot who combined intellectual rigor, courage and
moral purpose in remarkable degrees. Only in an age of self-promotion
would this exceptionally strong, but quiet, man be so little
known. Instead he deserves to be honored as a genuine hero. For that
is what he was.
Former Senator Gary Hart (D, CO)
John Boyd was one of the greatest military and strategic thinkers of
our time. His story and brilliance are superbly captured in Grant
Hammond's excellent book. This is a must read for all those that want
to understand how to think about war and to learn about a true
American patriot.
Gen Anthony Zinni (USMC, Ret.)
Former CINC, USCENTCOM
random refs:
https://www.garlic.com/~lynn/subboyd.html#boyd
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: Passwords Newsgroups: bit.listserv.vmesa-l Date: Wed, 23 May 2001 14:18:39 -0600At 01:14 PM 5/23/2001 -0700, you wrote:
some background
https://www.garlic.com/~lynn/2001d.html#61
https://www.garlic.com/~lynn/99.html#52
and a somewhat different solution to the authentication issue
https://www.garlic.com/~lynn/subpubkey.html#radius
https://www.garlic.com/~lynn/
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Mind of War: John Boyd and American Security Newsgroups: alt.folklore.military Date: Thu, 24 May 2001 03:38:02 GMTvelovich@aol.com.CanDo (V-Man) writes:
http://radio-weblogs.com/0107127/stories/2002/12/23/genghisJohnChuckSpinneysBioOfJohnBoyd.html
The Air Force, being the Air Force, tried to court-martial Boyd for
stealing the computer time but it could not come up with the evidence;
in the end, investigators found only four hours of stolen time. When
confronted, the Mad Major blew cigar smoke in the chief inspector's
face and explained calmly how he had stolen the rest. He then showed
the inspectors a thick file of letters, which documented how his
requests for computer time had been refused repeatedly by the bean
counters at Eglin and the autocrats at Wright Patterson. He suggested
they call Headquarters, Tactical Air Command, and tell the Commanding
General that Boyd was about to be hosed for uncovering better combat
tactics.
with regard to the book's author ... Grant Hammond, Director
Center on Strategy and Technology ...
Grant T. Hammond, Director AU Center for Strategy and Technology Air War College 325 Chennault Circle Maxwell AFB Montgomery, AL 36112 (334) 953-6996 (DSN 493-6996) Email: Grant.Hammond@maxwell.af.mil
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/
From: Anne & Lynn Wheeler <lynn@garlic.com> Subject: Re: The Mind of War: John Boyd and American Security Newsgroups: alt.folklore.military Date: Thu, 24 May 2001 12:58:55 GMTvelovich@aol.com.CanDo (V-Man) writes:
John Boyd was a remarkable patriot whose intense commitments to
learning and teaching the lessons of history changed American military
doctrine and made Desert Storm possible. This study is an invaluable
contribution to a little known part of our military history.
Former Speaker of the House
Newt Gingrich (R, GA)
... i always saw him as trying to do the right thing ... and more than
one would like think getting condemned for it. that he accomplished as
much as he did in his lifetime, is a attribute to not only his
tenacity but the few people that knew what he was doing and supported
him.
he sought no reward for it. i sponsored his talks a number of times and all he wanted was out of pocket expenses in return.
...
I worked with John Boyd, often by phone for 30 years. He was one of
my mentors, and was always generous with his time. He had an enormous
influence on all the services. We talked often before and after
Desert Storm. He always had that fire in his gut and passion in his
voice, even when he knew he was dying of cancer.
I consider him a great American and feel his loss. I often begged him
to publish his briefing on war, but he said the USMC had done it for
him as course notes. I am thrilled someone wrote a book about him; he
deserves it.
A Toast to the Greatest Eagle.
Dr. Paul Berenson,
Former Scientific Advisor to SACEUR and the CG TRADOC
--
Anne & Lynn Wheeler | lynn@garlic.com - https://www.garlic.com/~lynn/