- Test - lists.nanog.org

archive retrieval: list.info
by marilyn-request＠mozart.lib.uchicago.edu 18 Nov '97

18 Nov '97

File: list.info BEGIN------------cut here------------- Welcome to the Marilyn Monroe Mailing List! ADMINISTRIVIA ------------- Please keep this information for later use. The list owner is mozart(a)uchicago.edu (Peggy Wilkins). To post a message to the list, send your message to marilyn(a)mozart.lib.uchicago.edu Please DON'T send subscribe/unsubscribe requests to this address. Also, please DON'T post pictures to the list. Encoded pictures are large and hard for subscribers with disk quotas to handle. Consider posting to a Usenet binaries group instead, and announcing it to the list. To unsubscribe, send a message to marilyn-request(a)mozart.lib.uchicago.edu with Subject: unsubscribe To subscribe, send a message to marilyn-request(a)mozart.lib.uchicago.edu with Subject: subscribe This list is also available in Digest format. Individual messages accumulate in the Digest and are sent out to the digest list once every 1 or more days, depending on message volume. To subscribe to the digest, send mail to marilyn-d-request(a)mozart.lib.uchicago.edu with Subject: subscribe. This server maintains an archive of files (currently only this one!) and messages posted to the list. For information on using the archive server, send mail to marilyn-request(a)mozart.lib.uchicago.edu with Subject: archive help If you need to talk to me, the list maintainer, you can always reach me at mozart(a)uchicago.edu (Peggy Wilkins). You can also send mail to marilyn-request(a)mozart.lib.uchicago.edu as long as your Subject: header starts with Re: (if it says anything else, the server will try to process it automatically). LIST CHARTER ------------ I created this list as a forum for anyone with interest to discuss Marilyn Monroe. Marilyn collectors and fans are especially welcome, and discussion about your collection or your interest in MM is encouraged. If you're new to the list, please post an introduction about yourself. The list is happy to receive any messages about Marilyn. If you find out about movie/documentary broadcasts, new magazines, or whatever, please share it with the list! Chances are we'll all want to see it, too. But again, please no pictures posted to the list, as I mentioned above. Eventually, I'd like to get together a lot of MM information, and perhaps have it available on the web. A bibliography, filmography, maybe some scanned pictures, and anything else of interest. Let me know if you want to help on this. I have an MM page on the web, frequently revised, at: http://mozart.lib.uchicago.edu/Marilyn/ Welcome to the list, and I hope it will be interesting! Peggy Wilkins mozart(a)uchicago.edu List Administrator marilyn-request(a)mozart.lib.uchicago.edu MM fan since 1976 END--------------cut here-------------

1 0

Re: subscribe
by marilyn-request＠mozart.lib.uchicago.edu 18 Nov '97

18 Nov '97

You have added to the subscriber list of: marilyn(a)mozart.lib.uchicago.edu the following mail address: nanog(a)merit.edu By default, copies of your own submissions will be returned. This is an automated subscription mechanism. For your verification, a transcript of the original subscription request is included below. If the wrong address has been subscribed and you seem to be unable to fix it yourself, reply to this message now (quoting it entirely (for diagnostic purposes), and of course adding any comments you see fit). -- >From nanog(a)merit.edu Mon Nov 17 18:30:54 1997 >Received: from www.RVC.CC.IL.US (www.RVC.CC.IL.US [207.142.145.2]) by mozart.lib.uchicago.edu (8.8.5/8.6.4) with SMTP id SAA21563 for <marilyn-request(a)mozart.lib.uchicago.edu>; Mon, 17 Nov 1997 18:30:54 -0600 >Received: from merit.edu (166.72.5.121) by www.RVC.CC.IL.US > (EMWAC SMTPRS 0.81) with SMTP id <B0000000018(a)www.RVC.CC.IL.US>; > Mon, 17 Nov 1997 18:44:02 -0600 >Date: Mon, 17 Nov 1997 18:44:02 -0600 >Message-ID: <B0000000018(a)www.RVC.CC.IL.US> >From: NANOG Mailing List <nanog(a)merit.edu> >Subject: subscribe > >subscribe marilyn >subscribe >

1 0

Mail System Error - Returned Mail
by Mail Administrator 18 Nov '97

18 Nov '97

This Message was undeliverable due to the following reason: Your message was not delivered because the destination computer was not found. Carefully check that it was spelled correctly and try sending it again if there were any mistakes. It is also possible that a network problem caused this situation, so if you are sure the address is correct you might want to try to send it again. If the problem continues, contact your friendly system administrator. Host roadrunner.gateway2000.com not found The following recipients did not receive this message: <listserv(a)roadrunner.gateway2000.com> Please reply to Postmaster(a)newman.gateway2000.com if you feel this message to be in error.

1 0

Talking about spam and stuff..
by Adrian Chadd 17 Nov '97

17 Nov '97

Hmmsies.. $ cat /tmp/nanoglist | wc -l 2883 $ Ever since I subscribed to the list, I started to get spam. Which is strange, this email accounts gets (a) staff email, (b) nanog email. So a bit of snooping showed me that anyone can send the "who nanog" (or "which nanog", I cant remember which one, I just sent both :-) command to nanog(a)merit.edu and lo and behold, the subscriber list came back. So I'm asking the list admins to please disable the command, so spammers can't just grab a user list.. and also, for people who run large email lists, to consider doing the same. Adrian

5 4

Re: Geographic v. topological address allocation
by Sean Donelan 17 Nov '97

17 Nov '97

>You are confusing transport address (describing a location >in a topology) with an object name (a book, a computer, a >process running on a computer). > >An object name like an ISBN does not need to be >hierarchical because they do not describe discrete >locations. Introducing hierarchy improves managability >and efficiency of databasing. Many hierarchies can be >imposed on object names. If there isn't, there should be a theory in computer science with enough levels of indirection you can solve any problem, i.e. ISBN->Call Number->Shelf Location. Trick question: Does a LC Call number describe a location in a topology or an object name? Many hierarchies can also be imposed on an object's location, especially when that location is connected by a rich topological mesh. >Remember: at each level of naming there can be different >and completely disjoint hierarchies. There are >scalability implications in all of them, most notably when >the names used have size limits or are distributed >non-hierarchically (like ethernet addresses or the COM >domain). However, the important thing is that when a name >is used as a LOCATOR in a topology, in order to be >scalable that name must be related to that topology and in >large networks must lend itself to aggregation in order to >reduce the amount of information needed to have that >locator be used throughout the network. Another axis of the problem is the stability of the names used as locators. Otherwise you have just moved the problem up a level, translating the object name to its instantaneous location. Love that indirection. Propagating the change in object name->locator name when a route flaps, or every corporate merger or acquisition, doesn't scale well any better than the current system. Who is going to tell Bert or Bernie that all those MCI customers need to renumber when they merge their respective networks? Geographic addressing only has the advantages in that continental drift moves at a much slower pace than the changes in most network topologies. How you get to Cleveland might change, but Cleveland tends to remain in the same relative position. However, strict hierarchies have the disadvantage you can wipe out a subtree by simply targeting a higher level node. Being able to wipe out Cleveland by disrupting the Cleveland NAP is not a desirable feature of geographic hierarchical addressing. So you need some redundancy between the subtrees (i.e. a mesh), which means you have to keep track of that redundant information. Since that redundant information is likely based on the providers' facilities in and out of Cleveland, it looks like topological addressing. So do you name objects based on how you get to Cleveland, or based on their presence in Cleveland? But I think everyone has heard this argument before. Trade-offs, trade-offs. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

Re: Has spam factory dakotacom.net moved from ACSI to Alternet ?
by Steve Carter 17 Nov '97

17 Nov '97

-----BEGIN PGP SIGNED MESSAGE----- Content-Type: text/plain; charset=us-ascii > who's announcing 207.201.204.0/255.255.252.0 ? ACSI? Alternet? Both? Here's my traceroute.....It shows dakotacom.net connected by ALTER.net. - -Steve. <snip>#trace dakotacom.net Translating "dakotacom.net"...domain server (<snip>) [OK] Type escape sequence to abort. Tracing the route to dakotacom.net (207.201.204.21) <snip> 3 h1.peer1.wdc1.genuity.net (207.240.1.246) 72 msec 72 msec 68 msec 4 br1.tco1.alter.net (192.41.177.248) 68 msec 72 msec 72 msec 5 111.ATM2-0-0.XR1.TCO1.ALTER.NET (146.188.160.66) [AS 702] 76 msec 80 msec 76 msec 6 193.ATM3-0-0.XR1.DCA1.ALTER.NET (146.188.160.101) [AS 702] 76 msec 72 msec 88 msec 7 100.ATM2-0-0.TR1.DCA1.ALTER.NET (137.39.64.161) [AS 701] 76 msec 72 msec 76 msec 8 101.ATM4-0-0.TR1.EWR1.ALTER.NET (137.39.104.109) [AS 701] 84 msec 108 msec 84 msec 9 100.ATM8-0-0.XR1.EWR1.ALTER.NET (146.188.176.73) [AS 702] 284 msec * * 10 193.ATM11-0-0.GW1.EWR1.ALTER.NET (146.188.176.41) [AS 702] 92 msec 76 msec 84 msec 11 medic-net-gw.customer.ALTER.NET (157.130.97.154) [AS 701] 156 msec 148 msec 156 msec 12 dakotacom.net (207.201.204.21) [AS 8105] 160 msec * 160 msec - -- +-------------------------------------------------------+ | Steve Carter >><< scarter(a)genuity.net | | Network Operations <<>> Phone: (602) 308 2386 | | Genuity Inc. >><< Pager: (800) 394 4957 | | 'An Englishman Abroad' <<>> http://www.genuity,net | +-------------------------------------------------------+ -----BEGIN PGP SIGNATURE----- Version: 2.6.3a Charset: noconv iQB1AwUBNHC7lK+UEmo+hvE9AQF9JwL+JlIWryEIA6kLI09nLQMwg/xj09btM2Yu 4rQqnu1XOzEsc9OAQQbujayS8f1XMvYr4b1pmFmWOTNzGADlFXYyUSUV0OYfbvsP Lkhvnfzh+R49XXlx9DLUlrGU0oVxkyIZ =OTE6 -----END PGP SIGNATURE-----

1 0

Re: Has spam factory dakotacom.net moved from ACSI to Alternet ?
by dlr＠bungi.com 17 Nov '97

17 Nov '97

[In the message entitled "Has spam factory dakotacom.net moved from ACSI to Alternet ?" on Nov 17, 16:21, John R Levine writes:] > I've been receiving buckets of spam from dakotacom.net, as many as 90 per > day. They've been connected to ACSI for many months. > > ACSI has a new anti-spam AUP that went into effect today. Today I see that > traceroutes to Dakotacom go through Alternet and > medic-net-gw.customer.ALTER.NET. But the route looks odd, maybe a leak > rather than a new real route. > > I don't speak BGP (my multi-homed ISP does that for me), so can anyone see > who's announcing 207.201.204.0/255.255.252.0 ? ACSI? Alternet? Both? You have to look at the bigger picture. Dakotacom, who I suspect is not quite as innocent as they seem, is trying to distance themselves from gtwinc.com - the source of the spam (207.101.213.0/24). gtwinc.com seems to be off the air at this time. 1 bungi-tlg-gw.sf.tlg.net (140.174.166.37) [AS 3915] 24 msec 16 msec 8 msec 2 bordercore1-hssi0-0.SanFrancisco.mci.net (166.48.13.249) [AS 3563] 16 msec 1 2 msec 12 msec 3 core7.SanFrancisco.mci.net (204.70.4.93) [AS 3561] 264 msec 20 msec 12 msec 4 mae-west3-nap.SanFrancisco.mci.net (204.70.10.246) [AS 3561] 360 msec 52 mse c 56 msec 5 mae-west.acsi.net (198.32.136.79) 44 msec 36 msec 60 msec 6 tucson-az-1-a12-0.acsi.net (206.222.97.8) [AS 6467] 292 msec 320 msec 272 ms ec 7 dakotacom.net.tucson-az-1.acsi.net (206.222.101.238) [AS 6467] 288 msec 44 m sec 48 msec 8 * * * but they do still seem to use dakotacom's gateway. I poked dakota a couple of times, to see if they were still planning on disconnecting them. Hard to say. Dakota is now advertising their space through AS701, and AS8105. * 207.201.192.0/18 192.41.177.108 0 0 6467 i *> 192.41.177.108 0 0 6467 i * 157.130.33.113 50026 0 701 6467 i * i207.201.193.0 157.130.192.97 51123 100 0 701 7079 i *> 157.130.33.113 50032 0 701 7079 i * i207.201.194.0 157.130.192.97 51123 100 0 701 7079 i *> 157.130.33.113 50032 0 701 7079 i * i207.201.200.0/23 198.32.136.79 105 100 0 6467 6983 i * 192.41.177.108 0 6467 6983 i *> 192.41.177.108 0 6467 6983 i * 157.130.33.113 50026 0 701 6467 6983 i * i207.201.204.0/22 157.130.192.97 51119 100 0 701 8105 i *> 157.130.33.113 50021 0 701 8105 i * i207.201.208.0/22 157.130.192.97 51119 100 0 701 8105 i *> 157.130.33.113 50021 0 701 8105 i * i207.201.212.0 157.130.192.97 51119 100 0 701 8105 i *> 157.130.33.113 50021 0 701 8105 i *>i207.201.213.0 207.126.96.3 105 1000 0 7777 i * That's the state of the moment... -- Dave Rand dlr(a)bungi.com http://www.bungi.com

1 0

Re: WorldCom/MCI Merger - Backbone Monopoly?
by Colin "evey" Eve 17 Nov '97

17 Nov '97

I just hope that now they are confirmed to be merging the servers in atlanta and washington which are dropping packets for my connection to icigames.com can be sorted out. Colin. UIN;938778 colineve(a)lodge-house.demon.co.uk http://www.geocities.com/TimesSquare/7985/

1 0

Re: Legal Issues on Blackholeing
by Curtis Brown 17 Nov '97

17 Nov '97

On Nov 17, 10:11am, Paul Flores apparently wrote: > To sum it up: > part of the CDA indicates that "No provider or user of an interactive > computer service shall be treated as the publisher or speaker of any > information provided by another information content provider" > > This woulds seem to indicate that an ISP can not be LEGALLY > held accountable for the content published by a customer. (although > in the case of UBE, I think the means, more so than the message, is > the issue.) I don't think the issue of filtering comes into this at > all. I think (read 'hope') that you are reading too much into this. Going back to non-specific cases regarding the operation and liabilities of running a BBS I shall cite what I feel has been done in the past and seems as if it may remain appropriate: Cases against BBS operators for distributing illegal or offensive material seem to be split, based solely on the level of participation which the operator displays. For those operators that have shown a 'hands off' operational approach, there has been little liability for content. For those operators that take part in creating/managing their content, liability is usually complete. In other words, the way I see this as applicable to ISPs follows: *service* providers which supply TCP/IP access to the internet are liable only to ensure their customers are aware of netiquette. *content* providers (i.e. AOL, MSN...) are fully liable for all content which they manage/distribute. Feedback? cbrown(a)bbnplanet.com Server Administration, GTE Internetworking.

2 1

Re: NAP Solutions
by Sean M. Doran 17 Nov '97

17 Nov '97

Tony Li <tli(a)juniper.net> writes: > A SONET MPLS switch makes for a very interesting > exchange. Yes, for all the reasons you outlined, and because we've been talking about it for a couple years, this what I would deploy in the short run if I were interested in getting large-provider business. Having a circuit per peer has some advantages with respect to failure modes, but is expensive. Assuming that there is still a per bit per second per kilometre cost even for inhouse applications, if a reliable alternative existed, I expect that would be used, particularly as the growth curve of inter-provider traffic necessitates expansion of the private peering circuits. I would hope that people at Sprint, UUWHO (and ANS and MCI) and the various other places using private peering points are thinking about migrating from a "you buy one circuit i will buy one circuit" model to a more general "we will run an exchange point here, you bring circuits to us; you run an exchange point there, we will bring circuits to you, they will be running an exchange point there we will both bring circuits to that" one, although actually making a decision to do this would be dependent on costs and the reliability of new big fast routers and MPLS implementations and interoperability. One fat physical circuit that buys you N peers is probably going to be cheaper than N not-so-fat physical circuits at one peer each, in line costs, manageability and capital expenses (router ports etc.) Of course, the key downside to using a SONET MPLS switch/router is back to scaling. A question for you Tony. What does one do when one has an N port MPLS switch/router and has filled all N ports with traffic? Consider that each of the N ports will become fuller and that there will probably be a desire or requirement for N+1 ports with more to come. The lesson of the Gigaswitches and the ATM counterparts is that scaling beyond a single switch is hard. I don't have an answer, given what I know and can imagine about near-term technology (as opposed to stuff I want you and Crashco to build :) ) > the forseeable future. How long is that these days anyway? Anyway, other than the "what do you do other than give up on port density when you have more traffic or connections than one MPLS switch can handle" concern, I am in complete agreement with you, surprise surprise. Sean.

3 2