- Test - lists.nanog.org

Re: Domain Name NASA.COM
by Matthew James Gering 12 Jul '97

12 Jul '97

There must be somone at InterNIC who thinks like you do. You miss the point entirely. Trademark space is not flat -- it has to be trademarkable (not an generic term), it must be associated with a specific industry, and it must be associated with a particular region (the juridictal boundaries of the particular PTO). For a trademark violation, you must show that it is being used in the same industry in the same region, for damages you must prove that it was intentionally done to misrepresent your organization, and you must prove they profitted and/or you incurred a loss due to the misrepresentation. All the terms you list below, with the possible exception of FCC, are not even trademarkable. The idea that a US government organization could own the english word "house" is absolutely ludicrous. Associating your domain closely to that of another to gain misdirected traffic is unethical, but has nothing to do with trademark. Matt ---------- > From: Bob Izenberg <bei(a)austin.aus.sig.net> > To: Larry Vaden <vaden(a)texoma.net> > Cc: jamie(a)intuition.iagnet.net; nanog(a)merit.edu > Subject: Re: Domain Name NASA.COM > Date: Saturday, July 12, 1997 8:52 AM > > Larry Vaden wrote: > > # www.nasa.com is reachable. > > So what about these: > > Computerized Horizons (FCC2-DOM) > 2490 Black Rock Tpke. #309 > Fairfield, CT 06430-2404 > Domain Name: FCC.COM > > Congressional Communications (CONGRESS-DOM) > 361 Judd Farm Road > Watertown, CT 06795 > Domain Name: CONGRESS.COM > > Voice of the Senate (SENATE2-DOM) > 515 Watertown Ave., Suite 160 > Waterbury, CT 06708 > Domain Name: SENATE.COM > > Foreign Service Review Inc. (HOUSE2-DOM) > Route 1 Box 750-F > Elgin, TX 78621 > Domain Name: HOUSE.COM > > How about these next two? Receiving a letter from the FTC would > be getting off easy. :-) > > Army Corner Cubes (ARMY-DOM) > 3405-B Triana Blvd. #1136 > Huntsville, AL 35805 > Domain Name: ARMY.COM > > The CPS Group (AIRFORCE-DOM) > P.O. Box 619200 > DFW Airport > Dallas, TX 75261-9600 > USA > Domain Name: AIRFORCE.COM > > Bob

4 3

NASA.GOV on Root Server
by Jim Fleming 12 Jul '97

12 Jul '97

The NASA.COM debate is really more of a domain name issue and something that supposedly NANOG members are not concerned about. I would think that the NANOG members would be more concerned about organizations that use one of the legacy Root Name Servers to support their SLD(s). Some day maybe the legacy Root Name Servers will conform to RFC 2010. That is an operational issue that I would assume that some NANOG members would address. Jim Fleming ================================================ National Aeronautics and Space Administration (NASA-DOM) NASA Ames Research Center Mail Stop 233-8 Moffett Field, CA 94035 Domain Name: NASA.GOV Administrative Contact: Paschall, Beth (BP1760) Beth.Paschall(a)MSFC.NASA.GOV (205) 544-2930 (FAX) (205) 544-2554 Technical Contact, Zone Contact: Mughal, Asim (AM3388) asim(a)NSIPO.NASA.GOV (415) 604-5705 (FAX) (415) 604-0063 Record last updated on 27-Jun-97. Record created on 07-Jan-86. Database last updated on 12-Jul-97 04:23:14 EDT. Domain servers in listed order: E.ROOT-SERVERS.NET 192.203.230.10 JPL-MIL.JPL.NASA.GOV 128.149.1.101 NS.GSFC.NASA.GOV 128.183.10.134 MX.NSI.NASA.GOV 128.102.18.31 =================================================

2 1

Re: Domain Name NASA.COM
by Carl Oppedahl 12 Jul '97

12 Jul '97

At 09:57 AM 07/12/97 -0500, Larry Vaden wrote: >At 03:36 AM 7/12/97 -0400, Jamie Rishaw wrote: >>Today, without notice, the InterNIC turned "off" the domain name NASA.COM, >>a domain which had been registered now for over two years. >current status as of 97/07/12 09:56 am: > >mail# whois nasa.com >The Epicenter Network (NASA2-DOM) > 1344 Broadway, Suite 211 > Hewlett, New York 11557 > US > > Domain Name: NASA.COM > Domain Status: On Hold > > Record last updated on 11-Jul-97. > Record created on 22-Jun-95. > Database last updated on 12-Jul-97 04:23:14 EDT. > > Domain servers in listed order: > > NS1.HOST.NET 209.4.122.20 > NS2.HOST.NET 209.4.122.30 > >www.nasa.com is reachable. If it is reachable for you, this would only be because of a DNS cache that has not expired yet. You can plug 209.4.122.102 into your netscape and see the former www.nasa.com .

2 1

Re: Domain Name NASA.COM
by Bill Woodcock 12 Jul '97

12 Jul '97

Um, yeah, certainly nobody's going to mistake _that_ for anything put up by the National Air and Space Administration. :-) I'm curious why they picked the letters "nasa" though, if not to attract accidental hits, which _would_ violate the spirit of the law? I was expecting it to be something like the National Association of Something Arbitrary, where there would be clear reason for use of the name, and clearly no conflict. -Bill Woodcock ______________________________________________________________________________ bill woodcock woody(a)zocalo.net woody(a)nowhere.loopback.edu user(a)host.domain.com

2 1

Re: weird BGP cisco-ism? [problem resolved]
by Chris Garner 12 Jul '97

12 Jul '97

> > >> >> The problem with tagging everything a BGP customer passes to >> you with the "export it" tag is that customers have been known to export >> routes they shouldn't. The ACL provides a sanity check without costing >> much (if you've already got the database/distribution tools built). > >that's why you build customer ingress filters based on IRR info, as i've >mentioned several times now.... > >-danny > > > Dawn breaks....I missed that, but rereading your earlier messages I get it. So we agree that everyone should have an ACL somewhere between the customer and any exterior connection. You are saying that building egress ACLs that include the routes from all the ingress filters doesn't scale. If you've got them built off a database of some sort (internal, IRR, whatever) building and keeping them consistent should be straightforward. So any scaling problems are related to CPU/memory/BGP slowdown due to the size of the lists or to propagation delay of changes (waiting for database updates to propagate out). Does anyone know how large an ACL can be before it causes performance problems? My egress filters are in the hundreds of lines - does anyone run ciscos with 1000 line distribute-lists in BGP? 10K lines? Without the egress ACLs you still aren't protected if you forget to add an ingress ACL or have some bogus route you've generated internally. And I've seen both of those happen to NSPs. If you've got ingress and egress filters you do have better protection. I guess I'm just paranoid about routing information, so I filter at every access point. -- -Chris (cgarner(a)sni.net)

1 0

Re: weird BGP cisco-ism? [problem resolved]
by Robert Gutierrez 12 Jul '97

12 Jul '97

> What was happening is that, about a week ago, another provider got a > request from a customer to route them a single /24 from the middle of > our (non-portable) block. Because there was no IGP route for that customer, > but a network line was in place, the other provider was, every 5-20 minutes, > announcing the route for about 30 seconds, and then withdrawing it. > but a network line was in place, the other provider was, every 5-20 minutes, > announcing the route for about 30 seconds, and then withdrawing it. > > We peer with that provider directly, and can also see them via our transit > provider The assumption here is that the advertisement from the BGP peer in question was being rec'd by you and installed in the routing table, ie: you accepted a BGP advertisement in your own address space from another (untrusted) peer? I hate to state the obvious, but don't you filter your own blocks from your other BGP peers? Inbound, I mean. Very simple: router bgp 1 neighbor 10.1.1.1 remote-as 2 neighbor 10.1.1.1 filter-list 99 in as-path access-list 99 deny ^$ as-path access-list 99 deny ^1_ [etc -- however you want to set it up] Isn't this akin to wearing a condom nowadays in the 'net BGP routing warz. Before I left my last job, I was on my way to installing anal as-path access lists for our own customers who did BGP to prevent the above and also prevent another Florida fiasco. The idea was that we would only accept explicit addresses from those BGP peers. All that was need was to add a list for each peer: neighbor 10.1.1.1 distribute-list 10 in access-list 10 permit 172.16.0.0 or even worse, enforce CIDR/prevent subnets by only accpeting the specific block advertisement: distribute-list 101 permit 172.16.0.0 0.0.0.0 255.255.0.0 0.0.0.0 Just good practice to me :) Hopefully everybody else is doing the same??? Rob Gutierrez / 3Com - GIS Internet Security

3 2

Re: Mae-WEST
by Alex Rubenstein 12 Jul '97

12 Jul '97

According to nitrous.digex.net for its mae-west router: card inlet hotpoint exhaust RSP(4) 26C/78F 38C/100F 44C/111F Seems a little toasty to me. >Ironically, our temperature device is now broken in our Cisco. Has anyone >else had similar problems with them? We now have a number of 7000 series >routers which report off-the-wall readings. > >-Golan > > > --- "Don't go with a spineless ISP; we have more backbone." Alex Rubenstein -- alex(a)nac.net -- KC2BUO -- www.nac.net net @ccess corporation, 201-983-0725 -- 201-983-0725

3 2

Re: Mae-WEST
by Eric Kozowski 12 Jul '97

12 Jul '97

>Or, lets say, an automatic network monitor (ALA SNMP) that tells them >when UPS power is about to run down (before the lights go out) so they >can roll their generator into place. Shades of the massive AT&T failure of a few years ago. Lose external power, go to battery -- batteries run flat, cause nobody is paying attention. -- Eric Kozowski VP Internet Services eric(a)structured.net Structured Network Systems, Inc. (800)390-5945 Support A Verio Affiliate (800)881-0962 Sales/Info http://www.structured.net/ PGP Key fingerprint = 0A E4 91 B8 BD CB 3E 95 42 12 04 4E 14 DF 86 76 'They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety.' -- Benjamin Franklin 1759

4 4

Re: weird BGP cisco-ism? [problem resolved]
by Danny McPherson 12 Jul '97

12 Jul '97

> You can build your customer BGP filters off data in the IRR. Make > it a requirement that BGP customers must keep that information up to date > (or do it for them). OK. So I apply an ingress filter (ideally built from the IRRs) to a customer peer. Then I have to add the cusomter's AS(s) prefixes to every eBGP peer's egress ACL (including customer peers) so that the networks will be permitted. The customer begins advertising a newly allocated netblock. Now virtually *every* BGP peers ACL has to be modified & deployed and the source AS will need to either flap the route or reset the session. If I had tagged the customer's prefixes with a BGP community when I picked up the routes ..and have filters in place that deny/permit predefined communities to all eBGP peers, all I would need to be concerned with is the customer's ingress ACL. IMO, ACLs alone won't scale. -danny

2 1

Re: weird BGP cisco-ism? [problem resolved]
by Barry A. Dykes 12 Jul '97

12 Jul '97

Why don't you just tag your exportable routes and let them through, while blocking everything else? You could then build a route-map that places that tag on all of your inbound BGP customers. This would allow you to export everything that they send you (allowing them to send the more specific as Dorian stated) and use a static tag for your aggregate routes. Then all the more specific routes on your backbone would be filtered, unless it originated from a BGP customer - who would need to send the more specific advertisements to each of it's providers and allow routing to work correctly. I know, that's what we do! If you don't have the right tag, you don't get off! And I don't have to mess with any filters after they are set up. Barry > > > >You can remove the specifics at the edges of your network either via community > >based filtering or prefix based filtering. The former is much more flexible > >and is the one I'd recommend. > > > >-dorian > > > > I'd think prefix based filters would be more likely to be correct. > Since you have to explicitly list what you think you should be announcing > you protect against having routes you don't expect in your tables and > against having interactions that cause unexpected routes to get tagged as > announceable. > > -- > > -Chris (cgarner(a)sni.net) >

1 0