November 1997 - Test - lists.nanog.org

archive retrieval: posting.guidelines
by marilyn-request＠mozart.lib.uchicago.edu 17 Nov '97

17 Nov '97

File: posting.guidelines BEGIN------------cut here------------- Marilyn Monroe Mailing List Posting Guidelines ============================================== NOTE: Failure to read and abide by the guidelines contained in this document can and will result in changes to your subscription status. The Marilyn Monroe Mailing List can be a very high traffic mailing list. In addition, many members of the list use commercial services or pay long-distance charges. As a result, toleration of wasteful and inconsiderate posting will be slightly lower than the usual mailing list, and *MUCH* lower than Usenet. This document outlines your responsibilities as a subscriber. Abiding by them will enhance everyone's enjoyment of the list. The list is a powerful tool for you as a Marilyn fan and/or collector. Be conscientious, and you'll learn everything you've ever wanted to know about Marilyn, and make some friends too. Failure to abide by these rules will result in the following: 1. A warning. If I'm really irritated I'll quote your message and cut and paste the offended rule. If I'm short on time, I may just email a copy of the Charter and this file. In either case, email me if you have a question. The goal of a warning is just to remind you or give a practical example of a rule. 2. Suspension. If you break the same rule twice, break two in quick succession, or do something otherwise idiotic, you may be suspended from the list for 1-4 weeks. 3. Rejected. If you still haven't gotten the point, you will be unsubbed and added to the list's reject file. However, even this is not permanent, as I purge the reject list every 6 months or so. DISCLAIMER: I reserve the right to delete you, suspend you without warning, or otherwise manipulate your subscription (except for undesired subscription) for any reason whatsoever. Meta-Rule: When in dount, send it in PRIVATE e-mail. Below are the rules listed in the list Charter, commentary on their function, and strategies to avoid breaking them: 1. Obey standard Internet rules of etiquette The best way to do this is just THINK before you post. What and how you post is the only impression people will get of you. Most importantly your post should be well constructed, relevant, and interesting. Reasonable .sig length This is usually between 4-6 lines. If you want to show off your 80 line logo made of *'s, post an announcement and let people request it. Don't post people's email without permission Clear enough. Violating this will earn you a quick #3. Don't mailbomb the list Ditto. Don't post anything illegal Ditto. If you don't know what's illegal, you don't belong on this list. Don't quote more than text than is needed. As a rule of thumb, the text you quote should NOT be more than what you write. You can and should assume that we've all read it. New subs who may have missed something can access an archive of the last thirty messages. If you intend to quote text just to make a wry comment about, well, then you're just out of line. Therefore, quote only what is absolutely necessary (if any at all) for your reply. "Me too" messages really, really bite. If you respond to a question and you think it's of interest to all, post it to the whole list. If you see a question asked that you think may not be answered publicly, email the enquirer and ask them to please forward any responses to you. If they get enough requests, they may summarize to the list. It's quick, it's easy, and it's very considerate. 2. NO BINARIES OR DISCUSSION ABOUT BINARIES! That means no jpeg/gif posts. It is copyright violation and the messages become too large for practical distribution. 3. DO NOT SEND UNSUBS TO THE LIST! Send a message to marilyn-request if you need help. Many people pay for their email by the msg. Be courteous. The is really really irritating. Since being unsubbed from the list is the goal, and not a deterrent, this will simply earn you a goodly amount of much deserved flame-mail. Use marilyn-request(a)mozart.lib.uchicago.edu. 3a. DO NOT "TEST" THE LIST. See 3. Post an intro about yourself. If you don't get it back, email mozart(a)uchicago.edu and I'll look into the problem. 4. Do not post ANYTHING unrelated to the topic of the list. This is true of any Internet mailing list. The topic is Marilyn Monroe. No one wants Internet junkmail (See 3). You'd think this would be easy to understand, but you'd be surprised how many people think discussing viruses, Clipper Chips, or Making Money Fast is relevant to Marilyn. OTOH, the people on the list and their lives ARE relevant to the list. If a long time listmember has a b-day, gets married, or otherwise has an exciting life event, we want to hear about. This list is not only about Marilyn, but the people who love Marilyn. 5. You agree to abide by these rules. If at any time you need this document, acess the list archives or contact me. This includes updates to these documents, which will be announced to the list. 6. Anything else a majority of people on the list complain about. :) I have to admit this is slightly misleading. It's more accurate to state that if enough regular and consistently contributive members complain about something, I will back them up. That's it. You may want to keep a copy of this as a reference, or make sure you know to how get it if you need it. And if you have any questions, send me email (mozart(a)uchicago.edu) Peggy Wilkins <mozart(a)uchicago.edu> Administrator, Marilyn Monroe Mailing List END--------------cut here-------------

1 0

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

17 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 17 Nov '97

17 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