- NANOG - lists.nanog.org

RE: Statements against new.net?
by Roeland Meyer 13 Mar '01

13 Mar '01

> From: Valdis.Kletnieks(a)vt.edu [mailto:Valdis.Kletnieks@vt.edu] > Sent: Tuesday, March 13, 2001 1:14 PM > On Tue, 13 Mar 2001 12:54:42 PST, Roeland Meyer said: > > By the sheer fact that they included a non-technical value-judgment. > > OK.. I'm going to cite chapter and verse: You might want to calm down a bit. I'm out of the game now anyway (at least, this round). BTW, I read the original when it was first published. There is zero technical content, in the original. to whit; > Summary > > To remain a global network, the Internet requires the > existence of a > globally unique public name space. The DNS name space is a > hierarchical name space derived from a single, globally > unique root. > This is a technical constraint inherent in the design of the DNS. False. It is not a constraint, it results from a restricted implementation. > Therefore it is not technically feasible for there to be more than > one root in the public DNS. Improper conclusion based on a false premise. SRS has shown that root-root synchronization can happen. Probably easier than TLD-TLD syncs, because the rate of change is much lower. That's a real-world-and-already-widely-implemented example for you. It gets better, SRS was already widely deployed BEFORE the IAB published their comment. They just had trouble connecting the dots. >That one root must be > supported by a set > of coordinated root servers administered by a unique naming > authority. This statement is a pure non-technical value-judgement, supporting the legacy implementation, and is entirely self-serving. Of course, this statement, itself, is also a value-judgement. However, note that the defeat of the false premise, and it's direct improper conclusion, make this statement a pure political phrase. > Put simply, deploying multiple public DNS roots would raise a very > strong possibility that users of different ISPs who click > on the same > link on a web page could end up at different destinations, against > the will of the web page designers. This entire paragraph is a NOP. Webpage designers would never link to external resources under such condition as stated here. Those that do, deserve to get appendages whacked. > This does not preclude private networks from operating their own > private name spaces, but if they wish to make use of names uniquely > defined for the global Internet, they have to fetch that > information > from the global DNS naming hierarchy, and in particular from the > coordinated root servers of the global DNS naming hierarchy. > > OK? Read that. Read it again. Read it a third time. *ALL* that > says is "If you want to agree what the DNS tree looks like, you have > to share a root. If you want your own view, use your own root. > That's the way DNS is. You're stuck with the fact that DNS works > that way. You have to make your own choice which root to use". You really should calm down. I use external programs to build db.root.zone files, from external sources. All of the ORSC agrees to the core TLDs, which includes the legacy roots, and there are dispute proceedures for handeling collisions. > RFC2826 SAYS YOU HAVE TO CHOOSE FOR YOURSELF. Which is more important > to *YOU*? 100% consistency with the rest of the world, or access to > your private name space? *YOU* evaluate, *YOU* choose, and RFC2826 is > nice enough to point out the problems you'll encounter. It is not at all an either/or situation. There *is* the path of "accommodation". > Now, what non-technical value judgment did you say that RFC2826 was > making for you? It's not a "value judgment" that using multiple roots > with DNS results in inconsistencies, it's *the way DNS works*. see above. > I suppose the *next* thing we'll see is people complaining that the > concept of CIDR is an evil value judgement, because you need > to decide what > aggregation to do in order to keep the routing table a > manageable size. I already have my complaints about CIDR. It is NOT the same and let's not go there right now. > Now - I'll *readily* agree that "ICANN versus new.net" is political, > and probably worth discussing. However, I'm going to have to start > putting Bozo Flags on people who *still* claim that RFC2826 > is political > just because it points out that Things Will Provably Break if you have > conflicting roots. It doesn't say what you think. Do a logical analysis of the docuemnt after removing all pre-judgements. The document is not self-standing. This is the first clue that it is a political document. Granted, some of the issues are that of word-smithing, but that is even more clue that it shouldn't be taken as "gospel". If you look at is from the perspective of a system designer/architect, you will see the holes readily. If you perform a permutations analysis, you will see that they've walled-off many branches for no good reason (possibly, convenience). A good design includes all the permutations of all parts of the requirements matrix. Including, implied requirements that aren't stated. A robust design doesn't include arbitrary limitations.

2 1

Apple security contact?
by David Lesher 13 Mar '01

13 Mar '01

Sorry to interupt the rancher vs cattleman range war.... Can anyone point me to a contact person at Apple to answer a network/security query? Thank you; you may resume shooting. -- A host is a host from coast to coast.................wb8foz(a)nrk.com & no one will talk to a host that's close........[v].(301) 56-LINUX Unless the host (that isn't close).........................pob 1433 is busy, hung or dead....................................20915-1433

1 0

RE: Statements against new.net?
by Roeland Meyer 13 Mar '01

13 Mar '01

> From: Valdis.Kletnieks(a)vt.edu [mailto:Valdis.Kletnieks@vt.edu] > Sent: Tuesday, March 13, 2001 12:26 PM > I have to ask if any of these people who advocate the new.net approach > have been in the business long enough to have diagnosed > problems caused > by "I've got the Sep 1 hosts.txt, but you've go the July 15 > and they've > got the Sep 22" version. > > I *thought* we learned our lesson. Apparently not. We did, that's why we use DNS. As long as we practice collision avoidance, we won't have any problems. However, those that intentionally collide must be made to pay for it. ICANN, by flat-out ignoring the existing RSCs, basically told the rest of the world that it is okay for everyone else to ignore each other too. Had ICANN even tried to include the existing RSCs, we would now have new, non-colliding, TLDs.(IMHO) Personally, from my vantage point, the Internet co-opetition model is collapsing. Co-operation is a tit-for-tat game and no one is going to play without some "quid pro quo". ICANN wants it all one-way and that isn't going to happen anytime soon. In fact, such policy stance encourages polarization and fragmentation of the market/community. This is what gave rise to the opportunity that new.net is trying to exploit. Inclusive co-opetition would not have prevented the rise of new.net, but it would have given them strong encouragement to NOT have colliding TLDs. BTW: Co-opetition ::= cooperative competetion.(coined elsewhere)

1 0

Re: UUNet / ATT peering meltdown?
by Sean Donelan 13 Mar '01

13 Mar '01

On Tue, 13 March 2001, Travis Pugh wrote: > Not to open up any potential disputes, but has anyone heard what is going > on between UUNet and AT&T on the east coast? We've been seeing this kind > of performance for a week ... standard UUNet NOC response was "it's ATT's > problem, call them" which doesn't do me a whole lot of good since we're > not an ATT customer. AT&T had a fiber cut in Atlanta last week. They may still be operating on alternate facilities.

1 0

RE: UUNet / ATT peering meltdown?
by Travis Pugh 13 Mar '01

13 Mar '01

That may be a little extreme ... I generally get good support from all of my upstreams. However, there's a certain amount of static to be expected when you start raising inter-provider issues, especially when all the latency seems be caused by the provider you aren't a customer of. -travis On Tue, 13 Mar 2001, Tom Thomas wrote: > Bad attitudes to a customer are a clear indication you should take your > money elsewhere. > > Personally I like NetRail, they are courteous and responsive. > > > > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > Travis Pugh > Sent: Tuesday, March 13, 2001 1:13 PM > To: nanog(a)merit.edu > Subject: UUNet / ATT peering meltdown? > > > > > Not to open up any potential disputes, but has anyone heard what is going > on between UUNet and AT&T on the east coast? We've been seeing this kind > of performance for a week ... standard UUNet NOC response was "it's ATT's > problem, call them" which doesn't do me a whole lot of good since we're > not an ATT customer. > > UUNet --> ATT > > 6 POS6-0.BR3.NYC9.ALTER.NET (152.63.24.97) 9.212 ms 9.633 ms 10.363 > ms > 7 137.39.52.74 (137.39.52.74) 9.642 ms 12.967 ms 12.137 ms > 8 gbr3-p50.n54ny.ip.att.net (12.123.1.122) 418.555 ms 416.419 ms > 419.819 ms > > ATT --> UUNet > > 8 ggr1-p370.attga.ip.att.net (12.123.20.253) [AS 7018] 20 msec 24 msec > 20 msec > 9 att-gw.atl.uu.net (192.205.32.130) [AS 7018] 396 msec 396 msec 392 > msec > 10 179.at-6-0-0.XR1.ATL5.ALTER.NET (152.63.82.190) [AS 701] 388 msec 388 > msec 388 msec > > Thanks. > > -travis > > > >

1 0

BGP listserv
by Berger, Gary 13 Mar '01

13 Mar '01

Is there a list that purely discusses BGP? Gary Berger Internal Consultant, Principal Dow Jones & Company Enterprise Network Services Voice: 609.520.7323

3 2

News Feed
by Morris Allen 13 Mar '01

13 Mar '01

Off topic Question. Does any body have any information on News Server Feeds. I have lost my, and need to locate another that doesn't want an arm and a leg for a small ISP. Thanks Morris Allen VidcomNet, Inc. P.S. Please reply private to: mallen(a)vidnet.net

2 1

RE: Filtering email messages for canned ham
by Smith, Rick 13 Mar '01

13 Mar '01

I forgot to mention I'm already using rblsmtpd to work with blackhole lists. R -----Original Message----- From: Smith, Rick [mailto:rsmith@atsworld.com] Sent: Tuesday, March 13, 2001 9:17 AM To: 'nanog(a)merit.edu' Subject: Filtering email messages for canned ham Evidently, Nanog(a)merit.edu doesn't accept emails with the four letter word interpretation of my subject line. I have a machine which is the primary MX for my network, a linux box running Qmail (1.03) which scans every inbound mail to my domain for viruses before being passed on to the secondary MX, an Exchange Server. That works well, so I'd like to break the whole thing by adding to it some means of filtering out UCE / <Canned Ham> ;) Anyone used or know of tools that are written for Qmail's interaction ? Thanks, Rick Smith Director of Technical Services Applied Tactical Systems (A division of Vertex Interactive, Inc.) <http://www.atsworld.com> --- <http://www.vertexinteractive.com> (973) 808 - 1750 x382

1 0

Filtering email messages for canned ham
by Smith, Rick 13 Mar '01

13 Mar '01

Evidently, Nanog(a)merit.edu doesn't accept emails with the four letter word interpretation of my subject line. I have a machine which is the primary MX for my network, a linux box running Qmail (1.03) which scans every inbound mail to my domain for viruses before being passed on to the secondary MX, an Exchange Server. That works well, so I'd like to break the whole thing by adding to it some means of filtering out UCE / <Canned Ham> ;) Anyone used or know of tools that are written for Qmail's interaction ? Thanks, Rick Smith Director of Technical Services Applied Tactical Systems (A division of Vertex Interactive, Inc.) <http://www.atsworld.com> --- <http://www.vertexinteractive.com> (973) 808 - 1750 x382

1 0

Prefix length filtering at the ISP-ISP edge
by Alexandre.Gibouin＠sita.int 13 Mar '01

13 Mar '01

Nothing new in this mail but I need some clarification ... - To my understanding, the common practice is, at least, to accept any address block larger or equal to /19 and to filter any block smaller than /24 (except eventually at the customer-ISP edge). ARIN and RIPE have changed for a while their minimum allocation size to /20 so I guess there is no risk of routing blackhole with /20 blocks, right? - What about PI-blocks between 21 and 24 bits? If a end-user network annouces such an address block, what is the risk of routing blackholes throughout the Internet? - Each ISP seems to apply its own filtering policy. Nevertheless, what are the most common filtering practices for the ISP-ISP edge? - Is it common to have different filtering policies depending on the address ranges? I will be grateful for any link to official or non-official documentation. Thanks for your help Alex

1 0