- Test - lists.nanog.org

RE: Another reason to not use MAPS
by Mansey, Jon 08 May '02

08 May '02

Moral of this story, if you have or even think you have a great idea, do NOT become an employee (they own you), stay a contractor (you own you). Jm > -----Original Message----- > From: Conrad A. Rockenhaus [mailto:conradr@skyphusion.com] > Sent: Tuesday, May 07, 2002 10:17 PM > To: Andy Dills > Cc: Margie Arbon; nanog(a)merit.edu > Subject: Re: Another reason to not use MAPS > > > > On Tue, 7 May 2002, Andy Dills wrote: > > > <snip> > > > > > Now, MAPS has filed a lawsuit against a former employee. Why? > > > > Because he might interfere with their ability to make money by > > > > giving away something for free that they charge for! > > > > <...> > > > Precisely what other course of action could MAPS take? > > > > You could let him do whatever he wants with it. The premise of you > > charging for access to the various databases was based on a need to > > cover cost, not a desire to profit. Now you act with motivations > > specifically based on a desire to protect profit. > > The premise of charging covered costs to MAPS. It could be > easily inferred that one of thoses costs is the providing of > salaries and T&E to employees of MAPS. > > The DUL was expanded, improved, and worked on by both the > former employee and the other employees at MAPS, thereby > making it a product of MAPS, not solely of Gordon Fecyk any longer. > > While working on the DUL, Gordon was being paid by MAPS, was > provided equipment by MAPS, and was supported by other MAPS > employees, to build the DUL to where it is right now. > Therefore, the DUL is legally property of MAPS. > > Take this for example: You are working on a security product > to deal with script kiddies. Security company A likes the > idea, and brings you on, as a full time employee. You're > paid and provided assistance to develop a and improve this > method for dealing with script kiddies by security company a. > You develop the product, and security > company a provides it as a service. You leave security > company a or your > contract expires with security company a. Do you go out and > sell this service because you developed it? > > No, you legally can not. You legally can not because > security company paid you as a full time employee and > assisted you to develop this product, therefore, it is the > intelluctual property of security company a. > > Gordon had an idea. MAPS hired him, provided him with tools, > provided him with industry contacts, provided him with the > assistance of other employees, and provided him with a > paycheck to improve and build on the DUL. Due to MAPS' > assistance, Gordon, with the help of other MAPS employees, > developed a very excellent service. > > Since MAPS provided all of these items to Gordon, he was > developing a service that MAPS and MAPS only could provide, > in that form anyway. > > If Gordon went out, developed another DUL on his own, > developed his own independant documentation, etc., then MAPS > would be invalid in suing Gordon. > > However, that's not what he did. He took data that MAPS paid > him and others to develop. He took documentation that he > wrote while MAPS was paying him to do it. He took a model > that MAPS paid him to develop. He stole from MAPS, pure and > simple, and stealing is dishonorable, stupid, and WRONG, and > he deserves what he gets. > > > > > In other words, you have no cred on this street corner. You have no > > moral high ground. You're just another microsft or network > solutions > > complaining about how unfair it is, the injustice of the world! > > This is not the case; as I said before, he was being paid by > MAPS to develop his idea, to improve upon it, and other > things. Taking something from a third party, even though you > developed it, and selling it as your own when someone else > paid for it is wrong, period. What he's doing meets the true > definition of "theft." > > Lets take it to another level. Xecunet hires someone, and > that person has this great idea on how to make some > webhosting solution better than everyone elses. Xecunet > develops it, provides it as a "free upgrade" but then > realizes that they need to cover some costs, so you start > charging a little extra. Fine and good, right? > > Well, your employee leaves and goes to some big webhosting > company, and implements the idea. You paid him to develop > the idea, and assisted with the research, how do you feel > about that? Is he entitled to do that, to take something he > developed for your company and implement it somewhere else? > I wouldn't think so, then someone would of taken Windows from > Microsoft a while back, and sold it as "Blinds" or something > like that. > > > > > You used to be the vigilante force patrolling the net, > looking to stop > > spam by any means neccessary. You did so because that was > the what the > > net needed. Then you started to charge for it. Seems > reasonable, and > > while it upset a lot of long-time contributors (you're > making me pay > > for a service I helped build?), it made sense from the > point of view > > that "Hey, we're losing our shirts here, we need money." > > > > So, now, instead of fighting spam for free, you're fighting a spam > > fighter, the legal bills of which are paid for with the revenues > > generated based on you selling the intellectual property > contributed > > by many people! > > > > What other course of action could MAPS take? You could > throw out the > > people making decisions with their over-stuffed pocketbooks and > > re-invent yourself. > > Stealing is wrong, and stealing needs to be stopped, period. > MAPS is not fighting a "spam fighter." MAPS is fighting > someone that was a former employee paid to develop a service > to the level its at right now, so MAPS could provide it. Now > he took the data used to provide that service, and everything > related to it and is now marketing it as "his own" when in > fact, its not. > > > > > > > > > > So, you who subscribe to MAPS: When will you be cancelling your > > > > subscriptions? It's no longer about stopping spam with > them, now > > > > it's about money. FWIW, the other blacklists out there > are just as > > > > good. I particularly like njabl.org. > > > > > > For those wishing to actually *read* the filings before passing > > > judgement: > > > > > > http://mail-abuse.org/dul_info/ > > > > For those wishing to actually *think* about what MAPS is > really doing > > here before passing judgement: > > > > http://www.chickenboner.com/lawsuit/ > > I looked. That still doesn't defend the fact that Gordon was > being paid to improve this service by MAPS, that's pure and simple. > > Just to give you some background on that, read this: > http://www.eff.org/CAF/law/multimedia-handbook And to just clarify what I'm pointing out in this: "Naturally, you don't need a copyright license for material which you create yourself. However, you should be aware that the rules regarding ownership of copyright are complex. You should not assume that you own the copyright if you pay an independent contractor to create the work (or part of it). In fact,generally the copyright in a work is owned by the individual who creates the work, except for full-time employees working within the scope of their employment and copyrights which are assigned in writing." Gordon was a full time employee. His work is property of MAPS. MAPS is on the right, and they are on the right with what they are doing, period. --conradr

3 2

re: Qwest outage In NY
by Drew Linsalata 08 May '02

08 May '02

We saw the same issue on Saturday morning too (eastern time). BGP sessions to Qwest stayed up, but no data was moving across Qwest links. Kind of ugly. Emails to Qwest seeking information on Saturday went unanswered. Drew Linsalata The Gotham Bus Company Internet Server and Carrier Neutral Co-Location http://www.gothambus.com > From: Eric Gauthier <eric(a)roxanne.org> > Date: Wed, 8 May 2002 10:43:57 -0400 > To: nanog(a)merit.edu > Subject: Qwest outage in NY > > > Heya... > > Just found out that Qwest had an outage in one of their NY pops > (jfk?) that disrupted access out of the Boston area for about > 20 minutes. The master ticket (I believe) is 566548. Does anyone > know what happened? > > Thanks, > > Eric :) >

2 1

Re: Another reason to not use MAPS
by George William Herbert 08 May '02

08 May '02

1) This message had no operational content. 2) None of /., your posting here, nor any of the varied messages in newsgroups appear to have had enough research to bother looking at the actual complaints and responses and what actual issues are involved in MAPS v Feyck. MAPS is certainly not without its flaws, but the specific nature of the offense alleged has nothing to do with the rabid frothing. -george william herbert gherbert(a)retro.com

4 3

Re: ratios
by PETER JANSEN 08 May '02

08 May '02

Scott: Ratios are normally applied to either direction, since it is not totally understood who benefits from what traffic direction. Who benefits: the eyball or the content provider??? But keep in mind traffic ratios are only one parameter to establish a mutially equal beneit. Peter Jansen C&W Date: Tue, 07 May 2002 15:49 -0400 (EDT) From: Scott Granados <scott(a)graphidelix.net> To: PETER JANSEN <peter.jansen(a)cw.net> CC: nanog(a)merit.edu Sender: owner-nanog(a)merit.edu Delivered-to: nanog-outgoing(a)trapdoor.merit.edu Delivered-to: nanog(a)trapdoor.merit.edu Delivered-to: nanog(a)merit.edu Subject: Re: ratios I read the cw and uu examples. In the case of 1.5 to 1 which seems really close but I'm assuming this means I can send you 1.5 to every one received. Does this also apply in the inverse ie uunet sends back to me only 1.5 to my 1 or is this less critical? On Tue, 7 May 2002, PETER JANSEN wrote: > > Scott: > > Traffic ratios are one of the many parameters that ensure equality and > a mutual benefit between networks in a settlement free peering relationship. > > Have a look at our peering policy at www.cw.com/peering. It will > provide you with some information on peering with large networks. > > Regards > > Peter Jansen > Global Peering > Cable & Wireless > > > > > > Date: Tue, 07 May 2002 13:30 -0400 (EDT) > From: Scott Granados <scott(a)graphidelix.net> > To: nanog(a)merit.edu > Sender: owner-nanog(a)merit.edu > Delivered-to: nanog-outgoing(a)trapdoor.merit.edu > Delivered-to: nanog(a)trapdoor.merit.edu > Delivered-to: nanog(a)merit.edu > Subject: ratios > > > I'm not overly familiar with this but I wondered if someone could detail > for me the basics of using ratios to determine elegibility to peer? I > have heard that some carrers especially the largest require a specific > ratio is this in fact true and is the logic as simple as just insuring > equal use of the peer? > > Thanks > > Scott > >

11 18

Qwest outage in NY
by Eric Gauthier 08 May '02

08 May '02

Heya... Just found out that Qwest had an outage in one of their NY pops (jfk?) that disrupted access out of the Boston area for about 20 minutes. The master ticket (I believe) is 566548. Does anyone know what happened? Thanks, Eric :)

2 2

Another reason to not use MAPS
by Andy Dills 08 May '02

08 May '02

For a long time, I liked MAPS. They were doing good things for free. Then they started charging for access to their data, under the excuse that it costs so much, they just need to start covering their expenses. No big deal, right? They can't bleed money. I understand. Now, MAPS has filed a lawsuit against a former employee. Why? Because he might interfere with their ability to make money by giving away something for free that they charge for! Read about it on slashdot, I don't feel like pasting URLs. But the bottom line is that Nick Nicholas, who was Executive Director of MAPS for a bit a couple of years back, has this to say: "Last year I decided to write a book about the history of MAPS. My intent was to focus on the companies that sued MAPS and abused the legal system in order to prevent MAPS from exercising its legitimate free speech rights. I wanted to portray Paul and Dave Rand as beleaguered but slightly flawed heroes. However, my opinion of MAPS was forever changed this past April when it decided to sue DUL founder, Gordon Fecyk, after Gordon attempted to exercise a December 1998 contract he entered into with Paul Vixie in his capacity as MAPS CEO. ... It seems that MAPS has learned a great deal from the lawsuits brought against it by Harris Interactive and others, and has adopted the same slimy tactics. In particular, the affidavits filed by Margie Arbon and Anne Mitchell are full of factual errors and material misrepresentations. I will add my commentary on these affidavits at a later date." So, you who subscribe to MAPS: When will you be cancelling your subscriptions? It's no longer about stopping spam with them, now it's about money. FWIW, the other blacklists out there are just as good. I particularly like njabl.org. Andy xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Andy Dills 301-682-9972 Xecunet, LLC www.xecu.net xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Dialup * Webhosting * E-Commerce * High-Speed Access

4 5

Re: Effective ways to deal with DDoS attacks?
by vern＠ee.lbl.gov 07 May '02

07 May '02

> 1) rate-limits aren't going to solve anything. Um, you *could* try reading the paper. > 2) I'm pretty sure most providers aren't going to let customers determine > traffic engineering methods on their networks See the above. This is not something done by the customers (well they could, but that's not the main idea). > 3) if this is NOT done in a secure manner I bet I can make > www.whitehouse.com disappear... :) Could be we thought of that too! Vern

2 1

Re: Effective ways to deal with DDoS attacks?
by vern＠ee.lbl.gov 07 May '02

07 May '02

> It seems to me that the real issue in defending against an attack of this > type of differentiating between legitimate traffic and zombie traffic. Exactly. And while with today's DDoS attacks this is often not so hard, tomorrow's floods will be more carefully crafted so that there are no telltales that can be cheaply used to filter them out. Steve Bellovin and colleagues (me being one of them) have been working on a scheme called "Pushback", in which routers detect traffic aggregates that are burdening one of their links, and send pushback messages upstream to their peers responsible for the bulk of the traffic, asking them to rate-limit the aggregates. The key idea is that the upstream peers then monitor which of *their* upstream peers are responsible for the bulk of the traffic they're now rate-limiting, and send them pushback messages in turn, too. In this fashion, the pushback propagates out to the edge of the network (or the ISP's cloud, if that's the limit of pushback deployment). While there is still collateral damage in terms of any legitimate traffic that happens to enter from the same edge as the attack traffic will be subject to the same rate-limiting, *other* legit traffic that comes from other locations will escape the effects of the rate-limiting; so collateral damage is a lot less than if you just blindly rate-limit the aggregate. There are a number of issues concerning identifying aggregates, timing out the rate-limiting, etc. It's also not clear to what degree Pushback will work in the face of an extremely diffuse attack (see my next message). But it's at least a start on a solution that doesn't require uniform filtering of visibly distinct traffic. Pushback is described at: http://www.icir.org/pushback/ - Vern

3 2

Fiber cut on East Coast
by Miller, Steve 07 May '02

07 May '02

Anyone know of a fiber cut on the east coast? Possibly in the Miami area....XO is having problems but won't confirm anything. Steve

2 1

Re: Effective ways to deal with DDoS attacks?
by vern＠ee.lbl.gov 07 May '02

07 May '02

> > We most frequently are the zombie/reflector participants > > in an attack that originates outside our network, to a > > target outside our network. As many as 8,000 hosts on > > our network are reflecting SYN floods in the current > > attacks. > > I finally found a paper on this type of attack. You might also try: "An Analysis of Using Reflectors for Distributed Denial-of-Service Attacks," V. Paxson, Computer Communication Review 31(3), July 2001. http://www.icir.org/vern/papers/reflectors.CCR.01/index.html http://www.icir.org/vern/papers/reflectors.CCR.01.ps.gz http://www.icir.org/vern/papers/reflectors.CCR.01.pdf - Vern

1 0