- cypherpunks-legacy - lists.cpunks.org

Re: Burning papers (fwd)
by Jim Choate 17 Dec '03

17 Dec '03

Forwarded message: > Date: Mon, 26 Jan 1998 19:05:54 +0100 (MET) > Subject: Re: Burning papers (fwd) > From: nobody(a)REPLAY.COM (Anonymous) > As usual Jim, your posting is prolific but your science is lacking. Ad hominims, opinions, and no proof... > bind to whatever it comes in contact with (usually oxygen). The only way > cyanide could escape in gaseous form is as HCN, however this cannot happen > because the hydrogen has a lower activation energy for combining with > oxygen, and thus the reaction is starved of free hydrogen by the time the > carbon begins to burn. Various other nitrogen compounds are produced, > such as NOx, but this is true of all combustion and not limited to plastic. I have forwarded to the list a single safety standard for plastics and fires. It *specificaly* mentions HCN, so apparently it not only can happen but does often enough they want to test for it on a national level. There are many more out there and as I said before, if you contact your local fire dept. they can provide you with documentation as well. > A more likely (and deadly) result, which you did not mention, is sulfur > dioxide. Most plastics don't contain sulfur, but rubber products may. Sulfur dioxide is present and does pose a threat, fortunately it's a rather short termed threat and treatable. Sulfur dioxide turns into sulphuric acid in the water of the body. Not to mention it burns up the oxygen in formation. The biggest threat with the acids that are produced in a fire is to your possessions. They soak this stuff up and then when the firemen put the fire out they use water which creates acids. These acids effect the components of your possessions over an extended time. > Sulfur dioxide combines with water to produce H2SO3 and H2SO4 (sulfuric > acid) which is quite toxic if inhaled. Depends on the molarity. It is nowhere near as toxic as cyanide on a per part basis. > Most smoke inhalation deaths result for particles clogging the lungs rather > than gases. Cats have a tendency to hide when they feel threatened or > injured, an instinct which often imperils them in a burning building. Actualy most smoke inhalation deaths occur because of lack of oxygen and the elevated temperatures. The actual clogging process would take much longer than the 2-3 minutes most smoke deaths take to occur. As to cats hiding, they tend to hind *under* furniture which is actualy the *safest* place to be, the clearest air is next to the floor. It was also where my cats were found, in the living room under the couch where the smoke very clearly never got below about shoulder height - it stains the walls quite well. The fire didn't even make it into that part of the house, it stopped in the next room. The fire itself burned for less than 20 minutes total because the neighbor saw it about 5 minutes after the person who accidently set it off had left. The fire station was on the next block. It was very quick. The firemen were very careful to explain to me exactly why the cats died, gases from the plastics (HCN was specificaly mentioned) and the temperature of the air (they estimate over 350F). While not enough to cause spontaneous combustion it is more than enough to cook the lungs. The air was hot enough that several plastic bags holding wargame materials within 1 ft of the floor were melted but the paper materials were not even scorched. This would further indicate that the damage was done by the temperature of the gas and not direct flame or smoke. > Also remember that computers have materials in them other than plastic, for > example lead and other heavy metals. Batteries and electrolytic capacitors > are also sources of many toxic materials. The leads on most components are an aluminum compound (my background is EE) and they typicaly don't start to burn until well over 800F, aluminum itself burns at 600. Since typical tip temperatures in soldering (lead eutecticts only - not indium composites) are in the 600 to 700 it is clear that pure aluminum would not be desirable. So they mix tin and other compounds with it. As to electrolytics, the liquid plastics that make up the dielectrics are very toxic and most certainly give off xCN compounds when burned. Just for the record, Lead (the element) is not generaly used in modern electronics except in a eutectic solder mix for connections. I have several computers that were burned in the fire and the majority of the solder on the pcb's was *not* evaporated. In most cases it wasn't even melted even though the case was completely gone (2 A1000's that work fine though the cases were completely destroyed by the temperature of the air, not fire). > In short, it's not the plastic that's toxic, it's all the other crap (ink, > dye, glue, solder, batteries, dielectric, etc) Malarky. ____________________________________________________________________ | | | The most powerful passion in life is not love or hate, | | but the desire to edit somebody elses words. | | | | Sign in Ed Barsis' office | | | | _____ The Armadillo Group | | ,::////;::-. Austin, Tx. USA | | /:'///// ``::>/|/ http://www.ssz.com/ | | .', |||| `/( e\ | | -====~~mm-'`-```-mm --'- Jim Choate | | ravage(a)ssz.com | | 512-451-7087 | |____________________________________________________________________|

1 0

Latest Clinton dodge?
by Declan McCullagh 17 Dec '03

17 Dec '03

Clinton said this morning: >>>> I want you to listen to me. I'm going to say this again. I did not have sexual relations with that woman, Miss Lewinsky. I never told anybody to lie, not a single time -- never. These allegations are false. <<<< The question then becomes, of course, what does "sexual relations" mean? Is it oral sex? -Declan

8 13

Re: 25 Crays a Year to Break STT
by Bill Stewart 17 Dec '03

17 Dec '03

> Microsoft said its Secure Transaction Technology (STT), was > designed to provide a much higher level of security for > credit card transactions on the Internet. Netscape's > general purpose encryption system uses a 40 or 128-bit > electronic "key", while STT will use 2,000-bit keys. Sigh. Apples and oranges, and they know it. .... > Although no encryption system was totally secure, Mr Dent > estimated it would take "25 Cray supercomputers a year" to > break the STT codes. So how much work can 25 Crays do in a year? Crack single-DES? Maybe RC4/64? #--- # Bill Stewart, Freelance Information Architect, stewarts(a)ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---

1 0

FSTC - What is it...
by todd＠lgt.com 17 Dec '03

17 Dec '03

In answer to your question: I am not the official spokesperson for the organization. In fact I serve on a working group in an advisory and design review capacity. However I can tell you that: The Financial Services Technology Consortium (FSTC) is a consortium of financial services providers, national laboratories, universities, and government agencies who sponsor and participate in non-competitive collaborative research and development on interbank technical projects. The home page is located at http://www.llnl.gov/fstc and although still under construction offers pointers to a number of our projects like e-check and electronic-payment-handler as well as fraud-prevention tools and technologies. As to the actual posting of the wqebsite I just finished this yesterday so it will be listed pretty much in all the "cool places". a good point of contact for FSTC is: Dan.Schutzer(a)citicorp.com (Dan, please forgive me for giving the world your name!) I personally see FSTC as the strongest player in the secure e-commerce effort and would advise any banking and other financial services players (including the bond and stock houses) to get onto their bandwagon, yesterday... This leads me to believe that because of their Federal Involvement/Sponsership, that they will indeed become *the* defacto standards organization. As to the meetings planned they are scheduled for the ----------------------------------------------------- 10-Oct-95 E-Payment Working Group - Security Services, Cambridge Mass. 11-Oct-95 W3C meeting , Cambridge Mass. 26-Oct-95 E-Payment Working Group , General Meeting, Teaneck, NJ. Hope this answers your questions... Sincereley, Todd Glassey E-Payment Working Group Chief Technologist Looking Glass Technologies todd(a)lgt.com >This reached me via a couple of lists, so I hope I'm replying to the >right person: > > >>FYI- the FSTC E-payment Working Group meeting is happening at the W3 meeting >>on the day before the meeting itself. The meeting is being held at the OSF >>facilities. > >Did you send this note? Can you tell me a bit more about this -- >what's FSTC? > >Thanks! > >--Michael Smith > smithmi(a)dev.prodigy.com > > Support the Zimmerman legal defense! http://www.netresponse.com/zldf

1 0

Re: Timothy C. May: Mini-mailbombs and Warning Letters
by Travis Corcoran 17 Dec '03

17 Dec '03

-----BEGIN PGP SIGNED MESSAGE----- Message-Signature-Date: Thu Sep 28 14:13:09 1995 > To: cypherpunks(a)toad.com > From: tcmay(a)got.net (Timothy C. May) > > At 6:33 PM 9/27/95, Travis Corcoran wrote: > > What I call a robo-warning was this: > > " P.S. This mail was composed by my mailreading sftwr, which > automatically scans incoming mail, looking for failed keyserver > requests, and prompts me whether it should automatically send this msg > on my behalf. If there is a bug w this sftwr (for example, you never > PGP sign your msgs, so this entire msg makes no sense), or if you're > interested in the software itself (mail-secure.el: a package in lisp > for emacs; this is just one of the many crypto/privacy related things > it does) please mail the author of this package ( tjic(a)openmarket.com) > for details. Well, I still don't understand why you call a message that says 1) "I tried too verify a signature" 2) "please mail me your key" 3) "if there's a bug, please mail the author" a "warning". I guess we're just using the word "warning" differently... > As to whether I needed to respond to your robo-warning about how > your automatic scan of incoming mail produced some kind of > Signature Failure Condition Red at your end, I just ignored your > message. I never stated or implied that anyone "needed to" respond to query-mail. To the contrary, I said in all seriousness that ignoring query-mail was "a fine anarchistic solution to the problem". > As others will attest, when people ask me for my key in a > non-automated way, I usually send it to them. Well, I still don't understand your objection to labor-saving software any more than I understand the lifestyles of the Amish, but that's my problem, not anyone else's. > My _overall_ point was not to attack Travis C., who I don't think I > even mentioned by name, but to point out that great care must be > taken in running automated mail-response programs I did not take your comments on mail-secure.el as an attack on myself, but I did want to defend both the use of labor-saving software and parts of my particular implementation. Specifically, I defended the package against incorrect accusations on your part: 1) the query-mail was not a warning 2) the query-mail was not in response to the content of a post 3) the query-mail was not the first method used, but a last-ditch attempt 4) a human is in the loop 5) the keyserver used is not based on some trivial "preference" However, I do agree whole-heartedly with your above assertion that "great care must be taken in running automated mail-response programs". For this reason I have responded to your and other posts by adding features to the package to make it even less likely to bother people who don't want to be bothered. > Finally, since Travis is making a fairly big deal over my citing of > his post (though anonymously, as I recall), I'd like to see the > post he claims I signed. To the very best of my knowledge *I* did not send you a piece of mail requesting your key...I've had your key in my keyring for over a year. Further, I am not asserting that I saw a signed message from you any time recently. > >If anyone has a constructive suggestion as to how this mail could be > >changed to convey more information or to be less "threatening", please > >mail me. > > Simple, don't bother to ask in the first place. Or ask informally, in > ordinary English. Skip the "This mail was composed by my mailreading sftwr, > which automatically scans incoming mail, looking for failed keyserver > requests..." nonsense. Nonsense? It seems to me that the information is useful, for two reasons: (1) it alerts the recipient to the semi-automated nature of the mail, which allows the recipient to prioritize his response (if any) to it. (2) it alerts the recipient that incorrect receipt of a key-request could be caused by a software bug (as opposed to some attempt to forge email). (3) it notes the existance of the package, which the recipient might be interested in (in the same way many cryptography-aware programs add a comment line to a PGP-signature). By the way, I have had several people ask for a copy of mail-secure.el after receiving a key-request from the package, which translates into several more people encrypting their email and verifying the messages they receive. > I don't need some fraction of them running their own "key etiquette > agents" inspecting my posts for conformance to their preferences. Once again you're [ willfully ? ] missing the point: etiquette and preferences have nothing to do with it, and your repeated assertions to the contrary trivialize the desire of some people to authenticate messages they receive (which I and others consider to be a reasonable goal). - - -- TJIC (Travis J.I. Corcoran) http://www.openmarket.com/personal/tjic/ Member EFF, GOAL, NRA. opinions (TJIC) != opinions (employer (TJIC)) "Buy a rifle, encrypt your data, and wait for the Revolution!" PGP encrypted mail preferred. Ask me about gnuslive.el for emacs. -----BEGIN PGP SIGNATURE----- Version: 2.6 Comment: Auto-signed by mail-secure.el 1.002 using mailcrypt Comment: Processed by Mailcrypt 3.3, an Emacs/PGP interface iQCVAwUBMGrlu4JYfGX+MQb5AQGiSwP+MMgoog/vmsxKU5Zo17L5ZE3KVlYWsbQ7 9kcVb8d2CLPyAyaU4iNmF5dLwdYyy0reft9jhzQAaZ/1Nm0+9KXGAhT7DdO2nDFT hGc9KiQ/IYEkkhkRJIRRNkVNGeWclbf9J/ffQUUNBBTBbJkjjwoLFns+GA6D2Qx/ xs8QFel7kvQ= =6Gyn -----END PGP SIGNATURE-----

1 0

Re: Using sound cards to accelerate RSA?
by Phil Karn 17 Dec '03

17 Dec '03

>Somebody mentioned the possibility of using the a/d stage of a sound card >as a source of random bits, and that brought a thought back to mind: >given that a lot of sound cards are now shipping with DSP chips on board, >has anyone written any code that uses the cards DSP to accelerate RSA >processing? But most sound cards still don't have DSP chips. And modern general purpose CPUs are beginning to give them such a good run for their money that I wonder whether DSPs will ever become widespread. I'd stick with running RSA on the main CPU for now. Phil

1 0

Anon Http web Proxy V2.1
by Laurent Demailly 17 Dec '03

17 Dec '03

I fixed the IOs, it now works a lot faster, play with it on http://hplyot.obspm.fr:6661/ (no abuse plz) and get the source package on ftp://hplyot.obspm.fr/tcl/www/tclhttpdsh-0.4beta.tgz dl -- Laurent Demailly * http://hplyot.obspm.fr/~dl/ * Linux|PGP|Gnu|Tcl|... Freedom Prime#1: cent cinq mille cent cinq milliards cent cinq mille cent soixante sept smuggle FSF terrorist $400 million in gold nuclear Serbian Clinton

1 1

Q&A on the RSA/Cylink legal dispute
by baldwin 17 Dec '03

17 Dec '03

Here is RSA's Question & Answer sheet on the arbitration. It is available on our web site, www.rsa.com. --Bob ______________________________ Forward Header __________________________________ [RSALogo] --------------------------------------------------------------- Q&A ON THE RSA/CYLINK LEGAL DISPUTE This page contains general questions that have been brought up to us regarding the legal dispute between RSA and Cylink. We are providing these answers in hopes that you may better understand the issues. ---------------------------------------------------------------------------- September 25, 1995 Q. How did RSA's legal disputes with Cylink begin? A. It began in April of 1994 when Cylink filed an Arbitration Demand seeking to have a panel rule that Cylink was entitled to a retroactive patent license to RSA, also called the MIT patent. That was the extent of their Arbitration Demand at that time. The dispute was precipitated by RSA's discovery that Cylink had entered into a secret deal to provide products incorporating the patented MIT technology - even though Cylink knew it did not have a license. ------------------ Q. Why didn't PKP/RSA just sell them one? Isn't that their business? A. We offered them one several times. They wanted to pay essentially nothing for it. Although Cylink denied it, the fact that we offered them a license was confirmed by the Arbitrators in their ruling. ------------------ Q. Patents are routinely licensed and royalties routinely paid; why did Cylink go to the extraordinary length of suing RSA Data Security to obtain a license? A. We learned that in April of 1994 Cylink had won, over other bidders, a very substantial business deal with SWIFT (an international banking consortium) to provide X.25 encryption units for use by SWIFT on a worldwide basis. SWIFT had insisted that these products use the RSA patented technology for key management and authentication. Cylink had represented to SWIFT in their April 1994 contract that Cylink had a license to provide RSA technology. But they didn't. Cylink chose to sue us to win a retroactive license rather than simply admit what they had done and pay for a license. Cylink never informed us of their use of RSA or the representation to SWIFT. They never paid a penny to PKP or RSA for their unlicensed use of the RSA technology. They never even put any royalties aside. None of these facts are in dispute and are all a matter of public record. ------------------ Q. How did the litigation go beyond a limited Arbitration over a license? A. We didn't understand it at the time, but it's obvious now. While more claims and counterclaims were added to the Arbitration demand, Cylink knew of their SWIFT problem and other similar problems; we didn't. We believe that they were desperately trying to cover their unlicensed use of RSA by trying to litigate us into submission before it was discovered. It didn't work. ------------------ Q. What were the additional claims by each side? A. Charges were made by each RSA and Cylink that the other had breached the exclusive licensing authority of PKP among other wrongful acts. This brought a second set of issues for the Arbitrators. Finally, both parties asked to have PKP dissolved as we obviously could not continue as business partners; this was the third issue to be decided. It's quite clear in the Arbitration Panel's ruling that there were only three issues to be decided: (a) is Cylink entitled to a retroactive license to use RSA; (b) did either party breach the Partnership Agreement; and (c) should PKP be dissolved. The answers were no, no, and yes. ------------------ Q. If that's true, then how does Cylink claim that the Panel's ruling determined that RSA software customers are infringing the Stanford patents? A. The Arbitration Panel did not determine that the use of RSA software by RSA licensees or that the practice of RSA infringes the Stanford patents. It is most certainly true that the ruling was very limited; the Ruling itself starts out by stating the questions. The Panel did not, under any interpretation, rule on patent validity or determine that anyone was infringing. Cylink's claims to the contrary, along with their claims that somehow Cylink can rely on the Ruling to prove infringement is simply not true and ignores many other facts. ------------------ Q. What other facts? A. The Panel's ruling was very specific. Everything it said about third parties, including RSA customers who use software, refers to their need for patent licenses. If you bought software from RSA and RSA itself had the rights to make that software and license it to you, you don't need a separate patent license; rights to the patents came with the product. The Ruling also states, "RSA has a right to license its software." ------------------ Q. Under what circumstances would you need a separate patent license? A. If you want to make your own product -as opposed to buying one, such as RSA's software- you need a patent license. If you bought a software product but didn't use it, meaning you wrote your own, or re-wrote it, then you may need a separate patent license to do that. We believe the Panel was simply making it clear that just because you bought software from RSA, that fact alone doesn't mean you are free from the need for a separate patent license if you're not using the RSA software and making your own. You didn't get an explicit patent license with the software, you got rights under the patents as necessary to use the software. If you're using RSA's software -you didn't write your own- you don't need a separate patent license under either the MIT or Stanford patents. ------------------ Q. Are there other relevant facts that Cylink has ignored? A. Perhaps the most important fact that Cylink is carefully ignoring is that Cylink knows RSA did indeed have rights to make products under the MIT and Stanford patents. Cylink, for over five years, knowing full well what RSA sold and how, has not only referred customers to us, but in some cases where the customer was being cautious, Cylink confirmed to them in writing at their request that no separate patent licenses were necessary if they licensed RSA software. In other words, prospects of RSA's went to Cylink and said, "We're going to license this software from RSA. Do we need separate patent licenses from Cylink or PKP?" Cylink confirmed the answer - no. (And those companies then did in fact license our software. Cylink didn't turn around and sue them.) This alone should deter Cylink from bringing infringement suits against RSA customers. Nothing in the Panel's ruling changes any part of these facts. In fact, Cylink acknowledgment that RSA had such rights came out in the Arbitration proceeding itself. It's a matter of record. Cylink would also not like anyone to be aware that a suit was filed in Federal Court in 1994 to invalidate the Stanford patents, and that a ruling is due in December. ------------------ Q. How is RSA protecting its customers from action by Cylink? A. We have filed a Declaratory Relief Action in Federal Court. In that action, we have essentially said that Cylink is estopped -prevented- from taking action against anyone for infringing the Stanford patents for several reasons. The main reason is that companies who licensed software from RSA Data Security rather than "build their own" software do not need separate licenses to the MIT or Stanford patents. Since Cylink has confirmed this many times since 1990, they should not sue anyone for infringement. Another reason is that the Stanford patents are unenforceable and/or invalid. This action by RSA means that any suit brought by Cylink against anyone for infringement of the Stanford patents should be stopped until the resolution of the Declaratory Relief action, and Cylink will have to prevail on all the points above before they can assert any infringement. We have also indemnified our customers against claims such as those implicitly threatened by Cylink. RSA intends to stand behind these indemnity agreements fully. Anyone can bring a lawsuit for just about any reason. If Cylink tries to sue an RSA customer, RSA has both the determination and the resources to defend any such action. Read the Cylink press release carefully. Cylink huffs and puffs a lot, but is not directly threatening to sue anyone -that would mean they would be forced to fight the virtually impossible battle of prevailing on every point in our Declaratory Relief action- but instead are saying that buying a license can eliminate any risk. ------------------ Q. Has anyone else challenged the Stanford patents? A. A suit was filed in Federal Court last year by Roger Schlafly to invalidate the Stanford patents. A ruling is due in December. From what we've seen, Schlafly's claims raise disturbing questions about the Stanford patents. This whole business of the Stanford patents may be moot in a few months. There may be no risk - and no need to try to get any money back from Cylink. ------------------ Q. What will be the significance of PKP being dissolved? A. The most important change we see is that licenses to the MIT patent will be available for the first time in over five years without Cylink interference. * There is a tremendous amount of pent-up demand, and we are very busy filling it. Many of the largest companies in Europe, Asia, and the US are purchasing licenses to bring RSA-based products to market, including many low-cost chips and smart cards. We have already licensed a number of large and small companies that are bringing RSA-based electronic commerce, access control, and Internet security systems to market; we expect many, many more. ------------------ Q. Why can't RSA and Cylink simply settle their differences? A. That's a good question. The fact is that RSA recognizes this litigation is not beneficial to anyone and has offered to settle the dispute by granting Cylink a license to the MIT patent. Cylink has consistently overestimated the strength of its legal position and has refused all reasonable offers. Cylink now finds itself in the unenviable position of trying to sell its security products without RSA technology - which is the de facto industry standard. No amount of "spin doctoring" in press releases by Cylink changes that fact. ------------------ * During its existence from April of 1990 until September of this year, PKP could not grant any license without the approval of both partners. As a result of PKP's dissolution, the rights to the Stanford patents were returned to Cylink, and the exclusive right to license the MIT patent (RSA) was returned to RSA Data Security, Inc. Cylink currently has no rights to sell any products incorporating the MIT patented technology. ---------------------------------------------------------------------------- (C) 1995 RSA Data Security, Inc. All rights reserved. Permission granted for unlimited reproduction and distribution unmodified.

3 2

VISA and Microsoft STT Specs available
by hallam＠w3.org 17 Dec '03

17 Dec '03

Hi, The specs for STT are now available. Due to various circumstances too complex to explain these are currently being served via the W3C web server at :- http://www.w3.org/hypertext/WWW/Payments/STT.html This does not constitute an endorsement of these specifications by W3C nor any representation of the fitness thereof. Note that these documents may well move in the future. For more payments related info see:- http://www.w3.org/hypertext/WWW/Payments/ The roadmap has been updated appropriately. Phill Hallam-Baker

1 0

RE: More on "Entropy"
by David Van Wie 17 Dec '03

17 Dec '03

Tom Weinstein wrote: >We used this formulation of entropy in Statistical Mechanics. It's >especially useful in Quantum Thermo where you can actually enumerate all >of the states instead of relying on probabilistic arguments. Sure, this formulation can be used. As a pedagogic tool for explaining what a theory is all about, many formulations are discussed as if they have application in real world situations. Of course (for pedagogic reasons), these discussions focus on systems in which there is a definition, and typically a well-behaved mathematical model, for all of the significant states. Some instructors believe this will assist students in appreciating the concepts of statistical mechanics and quantum thermodynamics. To build a working apparatus (or software systems, as we are discussing here), the designer is typically faced with the breakdown of well-behaved mathematical models. Everything from degenerate states to the "baked in" uncertainty of certain states tends to undermine the mathematical foundations of a theorist's constructions. Of course the theoretical models are absolutely critical, but the designer must always caution themselves against drawing inferences without measurements and clearly stated rationales that speak to these physical realities that lead to mathematical weaknesses. Ultimately, the probabilistic nature of such systems may be "moved around," but not removed from the model! Since the real world of actual measurements interferes with essentially everything we claim to "know" about quantities such as entropy, the real danger is assigning an independent "meaning" to these constructs. Why? Because these quantities do not exist independently, they only exist with respect to our predictive models of a system's behavior. So these models do not really "enumerate" anything about states, but rather restate the probability assumptions of the model in the form of a "working equation." In addition, drawing inferences as to the behavior of systems based on common mathematical form is simply inviting trouble, even at the theoretical level. Mathematical models are not the real world, and the superficial mathematical consistency between say, the functional form of a resonance in a quantum well and a marble in a bowl, does not mean that the marble gives any special insight into the nature of the quantum well. In fact, beyond the curiosity of similar equations, the most important information is in the distinctions and clarifications (emanating from theory) between the systems from a practical, apparatus building, real world perspective (as contrasted with the "everything is just a special case of X" perspective). This danger is also present in designs for sources of entropy to seed RNGs for random data or to create uniformly distributed keys. Well designed models will avoid rephrasing assumptions as conclusions, and will explicitly address the mathematical weaknesses upon which the theoretical arguments in support of the model are ultimately based. dvw

1 0