June 2008 - Test - lists.nanog.org

Inventory and workflow management systems
by vijay gill 26 May '13

26 May '13

What software solution do people use for inventory management for things like riser/conduit drawdown, fiber inventory, physical topology store, CLR/DLR, x-connect, contracts, port inventory, etc. Any experiences in integrating workflow into those packages for work orders, modeling, drawdown levels, etc. /vijay

10 13

Re: cooling door
by Brian Dickson 29 Aug '08

29 Aug '08

Paul Vixie wrote: > if you find me 300Ksqft along the caltrain fiber corridor in the peninsula > where i can get 10mW of power and have enough land around it for 10mW worth > of genset, and the price per sqft is low enough that i can charge by the > watt and floor space be damned and still come out even or ahead, then please > do send me the address. Well, there are alternatives to the 10mW power and 10mW genset... 10-20mW (or more) of nuclear power/gensets. Get off the grid, sell back some power to the grid, reduce your costs for power, especially peak rate power, and be able to brag about having your own nuke plant. This may give you more flexibility in finding the space along the fibre corridor... BTW, I did some quick googling and found a few interesting links related to smaller nuclear generator systems: http://peswiki.com/index.php/Directory:Toshiba's_Micro_Nuclear_Reactor http://www.eia.doe.gov/cneaf/nuclear/page/analysis/nucenviss2.html http://www.eoearth.org/article/Small_nuclear_power_reactors http://www.uic.com.au/nip60.htm And if you have access to a deep harbor: http://atomic.msco.ru/cgi-bin/common.cgi?lang=eng&skin=menu1&fn=projects :-) Brian

6 9

XO contact
by Zaid Ali 24 Jul '08

24 Jul '08

Can someone from XO who handles this neighbor 65.46.253.157 help me out with a BGP session going down? This is the second time within a week where a misconfiguration of an ACL on XO end is bringing down my BGP session with you and its frustrating to go through the normal tech support chain. Zaid

4 3

ICANN opens up Pandora's Box of new TLDs
by Jim Popovitch 05 Jul '08

05 Jul '08

Two years ago I posed the question here about the need for TLDs (http://www.mcabee.org/lists/nanog/May-06/msg00110.html) I summerizsed that companies IP (Intellectual Property) guidelines would never allow domain.org to exist if they owned domain.com (ibm.org vrs ibm.com) I felt that TLDs really represented a monetary harvesting scheme as every new TLD forced companies to "pay for yet another domain name" (slowly milking businesses). At that time several knowledgeable folks commented that TLDs were necessary in the beginning due to the need to distribute queries. Now it seems, ICANN has decided to add a new paradigm :-) How will a TLD like .ibm be handled now, and how is this different than what I proposed in 2006? -Jim P.

48 114

Possible explanations for a large hop in latency
by Frank Bulk 02 Jul '08

02 Jul '08

Our upstream provider has a connection to AT&T (12.88.71.13) where I relatively consistently measure with a RTT of 15 msec, but the next hop (12.122.112.22) comes in with a RTT of 85 msec. Unless AT&T is sending that traffic over a cable modem or to Europe and back, I can't see a reason why there is a consistent ~70 msec jump in RTT. Hops farther along the route are just a few msec more each hop, so it doesn't appear that 12.122.112.22 has some kind of ICMP rate-limiting. Is this a real performance issue, or is there some logical explanation? Frank

12 17

what problem are we solving? (was Re: ICANN opens up Pandora's Box of new TLDs)
by Scott Francis 01 Jul '08

01 Jul '08

On Thu, Jun 26, 2008 at 9:01 PM, Jean-François Mezei <jfmezei(a)vaxination.ca> wrote: [snip conflict examples] > Finally, will there be any performance impact on DNS servers around the > world (thinking of caching issues) ? more to the point ... what problem is ICANN trying to solve with this proposal? What about the current system that's broken, does this new system fix? It looks like a lot of thought went into the process (thanks for the PDF link, DRC), and most of the issues raised here are addressed (conflicts, abuse/phishing grabs, etc.) - I'm just still unclear what the motivation for this new system was in the first place. I'm not opposed to it if it solves a legitimate technical/operational issue that's germaine to either the operators of the Internet or the users of the Internet, but so far I can't see that this serves either of those communities. In fact, it could very well be argued that a slew of new TLDs (whether a few dozen or a few hundred) will only serve to increase complexity and add additional confusion to a system that the standard user has just now come to grips with ("www.company.com will get me Company's official, legitimate page"). perhaps somebody with more insight can explain the rationale to me (DRC?) - is there a purpose served here aside from corporate/legal interests? thanks, -- darkuncle(a){gmail.com,darkuncle.net} || 0x5537F527 http://darkuncle.net/pubkey.asc for public key

33 79

Re: ICANN opens up Pandora's Box of new TLDs
by Roger Marquis 01 Jul '08

01 Jul '08

Stephane Bortzmeyer bortzmeyer(a)nic.fr wrote: > I am very curious of what tests a "security-aware programmer" can do, > based on the domain name, which will not be possible tomorrow, should > ICANN allow a few more TLDs. The difference between '[a-z0-9\-\.]*\.[a-z]{2-5}' and '[a-z0-9\-\.]*\.[a-z\-]*' is substantial from a security perspective. Aside from the IP issues it effectively precludes anyone from defining a hostname that cannot also be someone else's domain name. It's not too hard to see the problems with that. An analogous network scenario would be IP addresses of varying length and without a netmask. > If you test that the TLD exists... it will still work. Only if A) you are always online with B) reliable access to the tld's nameserver/s, and C) can deal with the latency. In practice this is often not the case. > If you test that the name matches (com|net|org|[a-z]{2}), then you are > not what I would call a "security-aware programmer". Will you still think that when someone buys the right to the .nic tld and starts harvesting your queries and query related traffic? Not that that doesn't happen now, to a far lesser degree. But it's the extent to which this presents new opportunities for black hats that should have given ICANN pause. Odds are that RBLs will be among the first targets. Bottom line is the decision was made for it's _monetization_ value, not security, and customer service was just a pretense. Roger Marquis

14 24

Re: ICANN opens up Pandora's Box of new TLDs
by Roger Marquis 01 Jul '08

01 Jul '08

Phil Regnauld wrote: > As business models go, it's a fine example of how to build demand > without really servicing the community. Of all the ways new tlds could have been implemented this has to be the most poorly thought out. Security-aware programmers will now be unable to apply even cursory tests for domain name validity. Phishers and spammers will have a field day with the inevitable namespace collisions. It is, however, unfortunately consistent with ICANN's inability to address other security issues such as fast flush DNS, domain tasting (botnets), and requiring valid domain contacts. The core problem seems to be financial, as this is likely the most revenue generating plan (both over and under the table) ICANN bean-counters could have dreamed up. It certainly was not the foreseen outcome when non-profit status was mandated. I have to conclude that ICANN has failed, simply failed, and should be returned to the US government. Perhaps the DHL would at least solicit for RFCs from the security community. Roger Marquis

9 18

Re: Mail Server best practices - was: Pandora's Box of new TLDs
by Roger Marquis 01 Jul '08

01 Jul '08

Rich Kulawiec wrote: > notification is essential in order to provide a heads-up about > problems (and that once problems are noticed, cooperation is > essential in order to fix them). But mail should never be > discarded without notice In practice we've found that (notification) is the core issue. Reject v discard is a non-issue by comparison. The format of those notifications does not have to be a spam folder, as many seem to assume. A summary report serves the purpose far better than tagging and delivery with far less overhead. Quoting <http://www.postconf.com/docs/spamrep/> : The only reliable way to avoid false-positives is by monitoring the email server or gateway logs and allowing end-users to receive a daily report of email sent to their account that was identified as spam and filtered. This is more or less identical to the issue ISP's like Comcast face when implementing QOS or other filtering, when they fail to notify end-users. Backscatter / NDNs are another issue. In practice they are no longer feasible without assurance that the sender is both valid and legitimate. Bounces without these validations are usually spam and will get your server blacklisted. Roger Marquis

3 2

Contacts at Indom (aka, indomco)
by David Ulevitch 30 Jun '08

30 Jun '08

NANOG, I'm having a heck of a time reaching anyone at Indom, a large French DNS provider. If anyone has a real human contact there (not simply technique at indom dot com) that'd be of great help. Thanks, David Ulevitch

1 0