September 1997 - Test - lists.nanog.org

[Fwd: Fwd: Ellison Quick On Feet As NC Demo Crashes And Burns 09/24/97]
by leong＠inversenet.com 25 Sep '97

25 Sep '97

This is off topic but the attached is so hilarious (probably not to the poor soul responsible for setting up the demo!) ..... Regards, John Leong ------

1 0

FBI Encryption bill defeated
by Rodney Joffe 25 Sep '97

25 Sep '97

Operational interest to all ISPs: Rodney Joffe Chief Technology Officer Genuity Inc., a Bechtel company http://www.genuity.net Forwarded::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :::::::::::::::::::::: From: Alan Davidson To: crypto(a)spa.org Subject: [1 Crypto] Update: Oxley/Manton defeated 35-16 Date: Wednesday, September 24, 1997 9:06PM [Now available on CDT's Web site...] The House Commerce Committee has approved a modified version of SAFE this evening, rejecting the FBI-backed Oxley-Manton "Big Brother" amendment on a vote of 35-16. The export relief provisions of the original SAFE bill were passed intact. The Committee also approved an amendment offered by Reps. Markey (D-MA) and White (R-WA). The amendment create a National Electronic Technologies Center (NET Center) which would assist law enforcement in research and would provide assistance to federal, state, and local law enforcement agencies in coping with encryption encountered in the course of investigations. The amendment also would direct the National Telecommunications and Information Administration (NTIA) to conduct a study of the implications of mandatory key recovery, and increases the criminal penalties under SAFE for the use of encryption in the furtherance of a federal felony. The amendment passed 40-11. The Committee then approved SAFE, with the Markey-White amendment, on a vote of 44-6. Today's vote is an significant defeat for efforts to impose domestic controls on encryption. In the face of tremendous pressure from the FBI, the Commerce Committee chose not to require all Americans to use encryption that guarantees law enforcement "immediate access" to their private online communications. The bill now must be reconciled with versions approved by four other committees before moving to the House floor. Rules Committee Chairman Gerald Solomon (R-NY) stated today that he will not bring SAFE up for consideration unless it contained the Oxley-Manton amendment. As a result, it appears unlikely that the bill will be voted on by the House any time soon. More information, along with the text of the amendments, will be posted soon at http://www.cdt.org/crypto. [Note: The unofficial text of the Markey-White Amendment -- as it was originally intended to be introduced today before some modifications due to procedural manuevers -- is now available on CDT's web site. We hope to have the official text available tomorrow.]

1 0

Re: Traffic locality and other questions
by Sean M. Doran 25 Sep '97

25 Sep '97

Sean Donelan <SEAN(a)SDG.DRA.COM> writes: > I have some questions whether it is better to aggregate traffic into > a single huge flow, or if it is better to have lots of > smaller paths. Ah, good question. What seems to scale better is aggregating things into large buckets which are switched together rather than merely filtering lots of small individually-switched buckets of data through single pieces of equipment. There are some assumptions driving this. Firstly, it is easier to move large numbers of symbols per second than it is to make large numbers of switching decisions. Secondly, it is possible to build a hierarchical routing scheme that can take advantage of aggregation opportunities to put similar traffic into big buckets along particular path segments. Thirdly, there are economies of scale which can be exploited when one uses large data pipes that reduce the cost of moving traffic intelligently. If all of these assumptions prove to be invalid, and in particular if it is cheaper to build equipment which are better at switching very small amounts of data across many diverse physical paths, if a routing scheme that can fully exploit this can be developed, and if it is more economical to use many small pipes than a few large pipes, then obviously one would be better off not aggregating traffic, and perhaps even deaggregating it and its complementary reachability information. > BGP isn't very good at showing 'other' transit paths to > networks. BGP is a distance vector protocol and not a map-exchanging protocol. You cannot build a completely accurate map of the Internet from a subset of BGP distance vectors. BGP routers will also only announce their paths of choice to their neighbours, and therefore any other paths they may know will be hidden. > What I find interesting is the rankings of traffic flows I see don't > match with what the pundits rank as the largest network providers. I > don't know what that means though. I suppose it depends on what people describe when they say "largest". Sean.

2 1

OFFTOPIC - encryption
by Jared Mauch 25 Sep '97

25 Sep '97

Please ignore this message, but if you're interested, read on. From: http://customnews.cnn.com/cnews/pna.show_story?p_art_id=342333 --- cut here -- WASHINGTON (Reuter) -- The House Commerce Committee Wednesday rejected a far-reaching proposal requiring all data scrambling products to include a backdoor allowing government access to otherwise secure computer files and communications. On a vote of 35-16, members of the panel voted against an amendment from Mike Oxley, Republican of Ohio, to impose such controls. --- cut here -- -- ----------------- jared(a)puck.nether.net - Nether Network ------------------ CICNet/IAGNet/NetherNet - finger jared(a)puck.nether.net for pgp key

2 1

"REMINDER" NANOG MEETING
by Pam Ciesla 25 Sep '97

25 Sep '97

The room block on the Radisson Resort ends Friday, 9/26 at midnight. The hotel WILL NOT honor the price of $155 per night after the deadline. Information on the hotel is available on the NANOG web page http://www.nanog.org. Thanks xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx Pam Ciesla 313-936-0172 - phone Merit Network, Inc. 313-647-3185 - fax University of Michigan 4251 Plymouth Road Bldg. I, Suite C Ann Arbor, MI 48105-2785 xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

1 0

AAARRRGGGHHHHH!!!!!
by Jay R. Ashworth 24 Sep '97

24 Sep '97

Apologies to all; I hit the send key before noticing that using 'g'roup reply to address my comments to Sean had put a carbon on it to the list. Hadn't meant to inundate you all. Cheers, -- jra -- Jay R. Ashworth jra(a)baylink.com Member of the Technical Staff Unsolicited Commercial Emailers Sued The Suncoast Freenet "People propose, science studies, technology Tampa Bay, Florida conforms." -- Dr. Don Norman +1 813 790 7592

1 0

Responsible Network Management Guidelines
by Sean Donelan 24 Sep '97

24 Sep '97

I've been reminded I was going to update my draft of Responsible Network Management Guidelines. The latest version is available at http://dranet.dra.com/draft-donelan-rnmg-latest.txt. In addition to any substantive comments, now is the time to correct the grammer and spelling nits. I plan on throwing this into the Informational RFC process before the next IETF meeting. -- Sean Donelan, Data Research Associates, Inc, St. Louis, MO Affiliation given for identification not representation

2 1

Re: Filter on postoffice.reston.mci.net
by Danny McPherson 24 Sep '97

24 Sep '97

Hmmm.. postmaster(a)mci.net? -danny > Okay, I give up. Apparently MCI has an SMTP filter either > on the domain netins.net or on something in the 167.142.0.0/16 > network on postoffice.reston.mci.net. > > [167.142.225.4]$ telnet postoffice.reston.mci.net 25 > Trying 204.70.128.20... > Connected to postoffice.reston.mci.net. > Escape character is '^]'. > 220 postoffice.Reston.mci.net ESMTP Sendmail 8.8.5/8.8.5; Wed, 24 Sep 1997 11:2) > HELO netins.net > 250 postoffice.Reston.mci.net Hello kevin(a)worf.netins.net [167.142.225.4], > pleased.. > MAIL FROM:<kevin(a)netins.net> > 550 Access denied > QUIT > > I've called the iNOC, they sent me to a 'systems group'. The systems > group listened carefully and wrote down the error code '550 Access > denied' before shuffling me off to the Reston office. There, I spoke > to a very nice sales person, who searched a list of voicemail boxes > she might forward me to. > > We pay MCI good money, and find ourselves unable to send mail to > trouble(a)mci.net or other MCI addresses. Now I'm stuck in the MCI > phone maze. If there was an incedent warrenting an SMTP filter, > we'd certainly deal with it if notified. I know if that happened > with one of our downstream customers, we'd actually contact them > before throwing in filters. > > Anyone know who takes care of postoffice.reston.mci.net ? > > Kevin

4 4

Re: Looking for Peerage Contacts
by Avi Freedman 24 Sep '97

24 Sep '97

Welcome, oh Knight of the Packet Table, to the Land of Peerage. > Does anyone have a contact name/number/email address handy for > peering contacts with the following? > > MCI > Sprint > UUNET/Worldcom/ANS/Compuserve . . . (Man is that list getting LONG) > PSI peering(a)network.net usually gets someone appropriate. If not, noc(a)network.net can redirect you appropriately. > We am entering the closing phases of bringing up our NAP > connections, (4 so far), and would appreciate the contact info to > help facilitate the peering process. > > Paul Flores > Williams Communications Group > (918) 588-5172 Avi

1 0

Re: Looking for Peerage Contacts
by bmanning＠ISI.EDU 24 Sep '97

24 Sep '97

> > Does anyone have a contact name/number/email address handy for > peering contacts with the following? > > MCI > Sprint > UUNET/Worldcom/ANS/Compuserve . . . (Man is that list getting LONG) > PSI > > We am entering the closing phases of bringing up our NAP > connections, (4 so far), and would appreciate the contact info to > help facilitate the peering process. > > Paul Flores > Williams Communications Group > (918) 588-5172 Hi Paul, Generally, you'll be introduced to the NAP community and given the basic tools to contact other parties at the given NAP. Broad area announcements to lists like this may get you what you want, but most exchanges have local lists for technical coordination. -- --bill

1 0