- Test - lists.nanog.org

Fw: New Federal Law (COPPA)
by Moe Allen 22 Apr '00

22 Apr '00

>From the information that CNN is reporting that is coming directly from the FTC. It appears that this is not only information that is obtained through a "CGI" format, but also via E-mail. The FTC also indicates that they have the ability to scan 100's of sites per day, and will. If a violation is detected, it can cost the site $ 11,000.00 per incident. This has far reaching consequences. I can see the "Unix Gods" spending many hours writing filters for this, just to "CYA".. This could be a good "Sting" Operation to setup on the Internet. I would agree that you might have some concern with this New Law. With any "Sting Operations", some good people get trapped with the crooks, just being in the wrong place at the wrong time. Having some "law" background, I believe this is one of those issues that could end up before the "Supreme Court", at the Federal Level. I understand their intent, but as with many laws of this type, the founders intent has a tendency to lost somewhere as it gets to the people that handle the enforcement side of things. I want to protect our young children, more than anyone. But I believe some "Law Biding Sites" could get caught on this one, if what is being reported from the FTC is correct. My attorney summed it up. It look like to me, they (the Feds) are going to try to force us (again) into becoming "Internet Police" as well as experts in the interpretation of the U.S. Constitution. Morris Allen VidcomNet, Inc. ----- Original Message ----- From: "Andrew Brown" <twofsonet(a)graffiti.com> To: "Robert Cannon" <rmcannon(a)mail.com> Cc: <nanog(a)merit.edu> Sent: Friday, April 21, 2000 3:26 PM Subject: Re: New Federal Law (COPPA) > > >If you operate a commercial Web site or an online service directed to > >children under 13 that collects personal information from children or > >if you operate a general audience Web site and have actual knowledge > >that it collects personal information from children, you must comply > >with the Children's Online Privacy Protection Act. > > i have a website that might be collecting information from children, > even though that's not the "target" audience. can i ask the person > how old they are, or is that a violation of the law? > > it seems to me that i must break the law in order to comply. > > or am i just being pedantic? > > -- > |-----< "CODE WARRIOR" >-----| > codewarrior(a)daemon.org * "ah! i see you have the internet > twofsonet(a)graffiti.com (Andrew Brown) that goes *ping*!" > andrew(a)crossbar.com * "information is power -- share the wealth." >

1 0

Re: The Cidr Report
by brandon＠rd.bbc.co.uk 21 Apr '00

21 Apr '00

> over 2500 routes could be removed from the routing table or make room for 2500 of those long prefixes nobody wants to accept > this is pretty embarrassing for the operator community. Only when size of table is used as an excuse to not let longer prefixes be used, instead causing more address space to be used to get by those filters. regards brandon

1 0

New Federal Law
by Moe Allen 21 Apr '00

21 Apr '00

The Federal Government just announced a new Law that goes into effect today. It has to do with collecting information for children under the age of 13. You must now have, on file, a parents written consent. The Federal Trade Commission has posted their site already. If you would like to find out more here is the link. http://www.ftc.gov/bcp/conline/edcams/kidzprivacy/kidz.htm More info can be found on the www.cnn.com site. Morris Allen VidcomNet, Inc.

1 0

The Cidr Report
by Tony Bates 21 Apr '00

21 Apr '00

This is an auto-generated mail on Fri Apr 21 12:00:01 PDT 2000 It is not checked before it leaves my workstation. However, hopefully you will find this report interesting and will take the time to look through this to see if you can improve the amount of aggregation you perform. The report is split into sections: 0) General Status List the route table history for the last week, list any possibly bogus routes seen and give some status on ASes. 1) Gains by aggregating at the origin AS level This lists the "Top 30" players who if they decided to aggregate their announced classful prefixes at the origin AS level could make a significant difference in the reduction of the current size of the Internet routing table. This calculation does not take into account the inclusion of holes when forming an aggregate so it is possible even larger reduction should be possible. 2) Weekly Delta A summary of the last weeks changes in terms of withdrawn and added routes. Please note that this is only a snapshot but does give some indication of ASes participating in CIDR. Clearly, it is generally a good thing to see a large amont of withdrawls. 3) Interesting aggregates Interesting here means not an aggregate made as a set of classful routes. Thanks to xara.net for giving me access to their routing tables once a day. Please send any comments about this report directly to me. Check http://www.employees.org/~tbates/cidr-report.html for a daily update of this report. ------------------------------------------------------------------------------ CIDR REPORT for 21Apr00 0) General Status Table History ------------- Date Prefixes 060400 74813 070400 75152 080400 75151 090400 75137 100400 75215 110400 75403 120400 75730 130400 75919 Check http://www.employees.org/~tbates/cidr.plot.html for a plot of the table history. Possible Bogus Routes --------------------- AS Summary ---------- Number of ASes in routing system: 4983 Number of ASes announcing only one prefix: 1838 (0 cidr, 1838 classful) Largest number of cidr routes: 0 announced by Largest number of classful routes: 1043 announced by AS701 1) Gains by aggregating at the origin AS level --- 21Apr00 --- ASnum NetsNow NetsCIDR NetGain % Gain Description AS271 351 131 220 62.7% BCnet Backbone AS7046 474 322 152 32.1% COQUI-NET PRTC Internet AS9269 163 26 137 84.0% Hong Kong CTI AS9706 153 30 123 80.4% Pusan Metropolitan City Office of AS1221 468 357 111 23.7% TELSTRA-AS AS2609 124 17 107 86.3% EUnet-TN AS7657 268 170 98 36.6% The Internet Group Limited AS7545 160 65 95 59.4% TPG Internet Pty Ltd AS705 309 214 95 30.7% ALTERNET-AS AS4293 305 215 90 29.5% Internal ASN for C&W AS174 558 470 88 15.8% Performance Systems International AS7496 126 39 87 69.0% Power Up AS6429 205 121 84 41.0% RDC-INTERNET AS7029 153 72 81 52.9% ALLTELNET AS9304 105 29 76 72.4% Hutchcity AS577 250 174 76 30.4% Bell Backbone AS209 458 385 73 15.9% Qwest Communications AS9557 80 15 65 81.2% Pakistan Telecommunication Compan AS1727 144 80 64 44.4% MRMS-WEST AS724 205 143 62 30.2% DLA-ASNBLOCK-AS AS3602 309 247 62 20.1% Sprint Canada Inc. AS7260 109 49 60 55.0% NORLIGHT AS701 1043 983 60 5.8% Alternet AS7018 518 459 59 11.4% AT&T WorldNet Service Backbone AS3749 114 56 58 50.9% TECNET AS816 333 277 56 16.8% UUNET Canada (ASN-UUNETCA-AS4) AS4740 337 281 56 16.6% Ozemail Pty Ltd (ASN-OZEMAIL) AS6595 101 48 53 52.5% DODDSEUR AS7568 68 18 50 73.5% C.S. Communications Co., Ltd. AS2563 125 76 49 39.2% KoRean Education Network For the rest of the previous weeks gain information please see http://www.employees.org:80/~tbates/cidr-report.html 2) Weekly Delta Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report 3) Interesting aggregates Please see http://www.employees.org:80/~tbates/cidr-report.html for this part of the report

2 1

Re: more anti-networksolutions propaganda
by Rodney L Caston 21 Apr '00

21 Apr '00

I wouldn't put the blame 'directly' on NA for this one, many groups have taken it upon themsleves to mine the whois database of NS. I won't name names cause at certain times a few major ISPs have done it as well. Regardless, spam is spam, and there isn't a good way to prevent people from mining the NS database. other then to ditch contact info on the records, which would be... silly. Rodney Caston SBC Internet Services On Fri, 21 Apr 2000, deeann mikula wrote: > > > this is more of a questions for the domain-masters out there, but has > anyone noticed a proliferation of spam to their contact addresses for > their domains hosted at NS? > > we have an address used *specifically* for admin and tech contacts for > all domains hosted by us. it is NOT a personal email addy. it > couldnt have been picked up from newsgroups, online forms, etc., but > ONLY appears in our domain records. > > i've been the recipient of that address for about 1.5 years, yet i've > only seen spam come into this address in the past 2 months or so. > i'm talking about like 10/day! > > did i miss something about network solutions selling off their > database of email addresses? > > deeann m.m. mikula > > telerama public access internet > director of operations > http://www.telerama.com > > >

2 1

Re: more anti-networksolutions propaganda
by Alex Rubenstein 21 Apr '00

21 Apr '00

On Fri, 21 Apr 2000, deeann mikula wrote: > this is more of a questions for the domain-masters out there, but has > anyone noticed a proliferation of spam to their contact addresses for > their domains hosted at NS? Yes, over the last 7 to 14 days, it has been horrendous. I'm contemplating blocking email from them, except for domain reg's. On a related note, has anyone else had extremely long delays with responses from ARIN? I've got one registration going on for 21 days now, and 20 of that is me waiting for them...

1 0

None
by Howard Smith 21 Apr '00

21 Apr '00

Actually: > 3) The best way to manage this situation is to use > the Class of Service per-VC queuing feature. This > will create a separate queue for each PVC, and will > insure that offending PVCs don't affect other PVCs > on the same interface. What it will also do is link > Layer 2 traffic engineering (ATM traffic shaping) to > Layer 3 flow control by using WRED to throttle TCP > flows on PVCs which are exceeding their ATM PVC > limits. As the TCP windows close, the packet flows > will be reduced until they fit within the shaped > PVC's limits. Only one VC queue on the OC12 ATM interfaces on the GSR series. So, is it queuing delay or cell loss slowing it down? end __________________________________________________ Do You Yahoo!? Send online invitations with Yahoo! Invites. http://invites.yahoo.com

1 0

Re: Anyone encountered Cisco ATM PVC large delay bug?
by Ron Buchalski 21 Apr '00

21 Apr '00

What type of service are you using? UBR? VBR? Some things to know... 1) Setting parameters such as PCR, SCR, MBS on the ATM interface will insure that you are shaping your traffic properly for the ATM cloud. What it _doesn't_ do is shape your IP traffic to go into this shaped ATM PVC. If your IP traffic exceeds your SCR occasionally, the SAR txpools can handle the bursts. However, if you exceed your SCR by a significant amount, the SAR txpools will fill, and you will encounter high queuing delays (as you've seen). 2) By default, one SAR txpool is created, and all PVCs share the pool. If you have one PVC which exceeds it's SCR, it will "hog" the SAR txpool and starve the other PVCs which are operating within SCR limits. So, one offending PVC will affect all other PVCs sharing the SAR pool. To fix this, you can create additional SAR pools and assign PVCs to different pools. You can create a maximum of four SAR pools. 3) The best way to manage this situation is to use the Class of Service per-VC queuing feature. This will create a separate queue for each PVC, and will insure that offending PVCs don't affect other PVCs on the same interface. What it will also do is link Layer 2 traffic engineering (ATM traffic shaping) to Layer 3 flow control by using WRED to throttle TCP flows on PVCs which are exceeding their ATM PVC limits. As the TCP windows close, the packet flows will be reduced until they fit within the shaped PVC's limits. When you enable the CoS per-vc queuing feature, you no longer need to configure SAR txpools, since it will be under software control. This feature is available in 12.0S code for both GSRs and 7x00 routers. Distributed CEF mus be enabled on the 7500 to use this feature. Hope this helps. -rb >From: "Yu Ning" <yuning(a)cndata.com> >To: "nanog-post" <nanog(a)merit.edu> >Subject: Anyone encountered Cisco ATM PVC large delay bug? >Date: Fri, 21 Apr 2000 07:28:21 +0800 > >Hi nanog, > >I'm not sure how many percentage of global NSP/ISP use ATM PVC to >provide links between their Cisco routers. It seems there is some >large delay bugs in Cisco ATM interface, esp on GSR level routers. > >In more detail, our situation is: if we get a high bandwidth PVC, >say 51M(or 80M), and if the bandwidth utilization reaches 80% >percent, the ATM link will encounter a 1500~2000 ms delay - just >point to point ping across the link. We have found this situation >is associated with "sar txpool" setting in Cisco GSR, and a manipulation of >the "sar txpool" together with bandwidth increasing has solved the problem >now. > >But I still wonder if any of you ever encounter this situation(bug), >and how did you overcome it? If you are still puzzled by this bug, >I'd like share our temp solution with you. ________________________________________________________________________ Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com

1 0

Re: Buy tier 1 peering for only $15 million
by Sean Donelan 21 Apr '00

21 Apr '00

I violently agree you should conduct due diligence when purchasing any company to make you get what you thought you were getting. Much like when Anheuser-Busch bought SeaWorld and forgot to check the contract to see if it included Shamu. Or BBN actually counting the routers in BARRNET to see if they matched the ones on the books. I've been told the ISPs' auditors are doing due diligence of the peering agreements in this case. On the other hand, of all the peering battles I've heard about, I've never heard of a peering agreement being terminated as a result of a change of ownership of the ISP. Even in Verio's case, when Verio was both a customer and a peer of different providers as it bought various providers (most companies have strict policies against peering with customers), from my outside (without NDA information) place, I didn't notice peering sessions suddenly going away. On Thu, 20 April 2000, Randy Bush wrote: > >> ...such relationships are not always 'transferrable,' > >> and one should evaluate any existing contractual > >> agreements regarding said relationships before making > >> such assumptions. > > > > So even though Jeff's statement is technically true, I don't think > > it is very practical. > > it is extremely practical. and when purchasing an asset, review > of contracts is exceedingly prudent. and the confidentiality of > those contracts is not an issue as the contract review is under > nda.

1 0

Technology Staff Hierarchy
by Hermann Wecke 20 Apr '00

20 Apr '00

Does anybody have references to info on technology staff hierarchy/roles models in Telcos/ISPs? TIA...

1 0