January 2005 - Test - lists.nanog.org

RE: EPP minutia (was: Re: Gtld transfer process)
by Bruce Tonkin 18 Jan '05

18 Jan '05

Hello Eric, Thanks for your descriptions from an operator and web-hosting company perspective. Essentially different customers have different needs. Some that value price higher than reliability/security are likely to want to easily move names around depending on renewal prices and the prices of other services. Others value reliability/security very highly, and prefer to stay with one reliable provider, and will pay a premium for that provider to put in place strict change management procedures. In terms of the second category many registrars (including Melbourne IT) offer services tailored to the corporate market that incorporate change management processes, often with dedicated staff that are trained in such procedures. The transfers policy therefore needs to be able to support both types of registrant, and in particular allows the registrant to control the choice of processes. In the past some registrars have imposed their own strict processes (for example requiring a judge to approve any changes of registrar) that are not in accordance with the wishes of the registrant. Often these processes for registrar change are not in proportion to the processes for change of delegation etc. Generally a corporate wanting high security/stability will want strict change management across all processes, rather than a registrar accepting a delegation change over the phone without authentication, but requiring a judge to approve a transfer. A registrar wishing to offer a customer a high level of protection must be able to set a flag in the registry that prevents a transfer. This is the Registrar-LOCK function. Now I agree this still requires the registrar to have strict process control on how this flag can be set/cleared. The policy requires that a registrar provide a mechanism for a registrant to unlock a name that is consistent with other processes - e.g delegation for that name/registrant. Regards, Bruce

1 0

Re: The entire mechanism is Wrong!
by Eric Brunner-Williams in Portland Maine 18 Jan '05

18 Jan '05

Gentlemen and Ladies, I concur with the view expressed by Bob Fox (IANA-134), that the "current method only favours Verisign and crooks." The hijacking of panix.com, and the post-hijacking response of VGRS, which could unilaterally act, but choses not to, for its own reasons, and MelburneIT, which could unilaterally act, but choses to not act until 72 hours after being noticed, if then, is a counter-example to any claim that the current method has any rational application to domain names that are "mission critical", that is, used for something other than proping up some shoddy trademark claim by some party that doesn't even use the dns for core operational practice. It doesn't reflect very well on the registries and registrars either. Eric Brunner-Williams CTO Wampumpeag, LLC Operator, USA Webhost, IANA-439, CORE-124

17 18

panix.com hijacked
by Steven M. Bellovin 18 Jan '05

18 Jan '05

panix.com has apparently been hijacked. It's now associated with a different registrar -- melbourneit instead of dotster -- and a different owner. Can anyone suggest appropriate people to contact to try to get this straightened out? --Prof. Steven M. Bellovin, http://www.cs.columbia.edu/~smb

13 16

IXP Panel - NANOG Las Vegas
by Malayter, Christopher 18 Jan '05

18 Jan '05

Hello, As Susan has just mentioned, I will be moderating the IXP Panel at Las Vegas. I am interested in volunteers from IXP's to serve on the panel. Please contact me off-list if you are interested. Thanks! -Chris -----Original Message----- From: Susan Harris [mailto:srh@merit.edu] Sent: Tuesday, January 18, 2005 1:18 PM To: nanog-announce(a)merit.edu Subject: Agenda redux Many thanks to Chris Malayter, who's kindly volunteered to moderate our IXP panel in Las Vegas. The General Session will now run until ~1:00 p.m. Tuesday afternoon, and Chris will be sending a message to the list shortly.

1 0

Agenda redux
by Susan Harris 18 Jan '05

18 Jan '05

Many thanks to Chris Malayter, who's kindly volunteered to moderate our IXP panel in Las Vegas. The General Session will now run until ~1:00 p.m. Tuesday afternoon, and Chris will be sending a message to the list shortly.

1 0

XO Outage in Chicago?
by Joseph Johnson 18 Jan '05

18 Jan '05

Anyone see an outage at XO in Chicago? From Alter.net, Verio, and Level 3 I die at the crossover point to XO at the Chicago Exchange. Thanks! Joe Johnson

2 1

RE: Panix.com should be back.
by Hannigan, Martin 18 Jan '05

18 Jan '05

And to think I went to college. Even. Folks, 'Blackberry Gone Wild'. Usually a great device, but tremendously beat and now showing it. That should simply read 'Thanks Farid'. The thing went wild storing keystrokes like it was hung, autocompleting, and sending everywhere. Twice here and to many people on in the addr book privately. Mea Culpa. -- Martin Hannigan (c) 617-388-2663 VeriSign, Inc. (w) 703-948-7018 Network Engineer IV Operations & Infrastructure hannigan(a)verisign.com > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > Hannigan, Martin > Sent: Sunday, January 16, 2005 11:01 PM > To: MajidFarid(a)TelecomOttawa.com; nanog(a)merit.edu > Subject: Re: Panix.com should be back. > > > > > > Thanks Fared for your assistance. Ypu are great among a bun > --- > Martin Hannigan > hannigan(a)verisign.com > Verisign, Inc. > > > -----Original Message----- > From: owner-nanog(a)merit.edu <owner-nanog(a)merit.edu> > To: nanog list <nanog(a)merit.edu> > Sent: Sun Jan 16 19:57:54 2005 > Subject: Panix.com should be back. > > > I see that DNS changes has been reverted > http://www.dnsreport.com/tools/dnsreport.ch?domain=panix.com > > I have also contacted our Customer owner of ns1.ukdnsservers.co.uk > [panix.com] (142.46.200.67) they have assured me they will remove the > DNS config as well. > > > Sorry for the last response I was away for weekend. > > -- > Majid Farid > Telecom Ottawa Limited. > > > -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu] On > Behalf Of > Gadi Evron > Sent: Sunday, January 16, 2005 7:24 PM > To: nanog list > Subject: domain hijacking - what do you do to prepared? > > > Until today, I considered this to be a real and relevant threat, > although rather low in my matrix. > > As someone I know said today, now that kiddies saw how much > "fun" this > is, I am sure they will attempt this again. > > The question that comes to mind is - what do you do to be prepared? > > I suppose that other than setting registrar lock in place, there is > another thing one can do. > > Study! > > Whether it's checking the expiration date for your domain, > establishing > contact with your up-in-line authority - registrar, tld, etc. > depending > on who you are. > Having the relevant contact information at hand, establishing a set > policy on how to handle such an incident and who to contact, bugging > your next-in-chain about setting a policy on this with you, > as well as > setting such a policy for those who are slaves to you. > > That said, all that is left now is to see how this happened > (so that it > won't happen again - just killing a fire doesn't mean it won't be > re-ignited) and perhaps think a bit on how we do things - which I am > sure many will now do. > > Maybe this can be another discussion issue for the next NANOG > get-together as well? > > Gadi. >

1 0

RE: netblazer Was: baiting
by Hannigan, Martin 18 Jan '05

18 Jan '05

> -----Original Message----- > From: Robert E.Seastrom [mailto:rs@seastrom.com] > Sent: Tuesday, January 18, 2005 11:11 AM > To: Eric Brunner-Williams in Portland Maine > Cc: Hannigan, Martin; wsimpson(a)greendragon.com; nanog(a)merit.edu > Subject: Re: netblazer Was: baiting > > > > Eric Brunner-Williams in Portland Maine <brunner(a)nic-naa.net> writes: > > > In this period of time, the White Knights built the InterOp > shownets and > > we had comparative access to quite a lot of vendor product, > and know that > > the red buttons on Wellfleets were correctly positioned on > the front, for > > easy access. We used NetBlazers for dial-up outbound (we > were topologically > > quite diverse by '91, our last show in the San Jose > facility) and I don't > > recall anything ... resembling the behavior that I could > characterize as > > POS like function. > > My recollection of that show was "T-1 to BARRnet", not > bonded-Netblazer-dialout, but I didn't "work the show" until the > following spring, so my recollection could be at fault. > > I wouldn't characterize Netblazers as being particularly cruddy > compared to other options available at the time. Remember that this > was the era of the Cisco ASM, the Encore/Xylogics Annex (Wellfleet > hadn't changed their name to Bay yet, much less bought the Annex > product line), some nasty 3com terminal server of which my memory has > thankfully purged most details and the gone but not lamented Cisco > TRouter. The Netblazers worked pretty darned well when plugged into > Telebit modems. Third party modems, well, there were a lot of knobs > you could twist, and not the best in the way of documentation on what > to do with 'em. > > Based on my experience with them, I'm quite sure they were fabulous > devices capable of being configured in the field to do just about > anything, if you had the level of familiarity with their internals > that someone who worked QA for them would have had. There really wasn't any good modem, IMHO, back then. They were all painful to configure and make work reliably. Once the "net" revolution started it still took years to get modems working reliably. In '98 I know that the Max TNT was only getting about 85% call completion across_the_board. Call completion only takes into account the completed handshake. Then you dealt with code issues after you got them to at least connect. -M<

1 0

IETF Administrative Director Job Announcement
by Kurt Erik Lindqvist 18 Jan '05

18 Jan '05

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Internet Engineering Task Force (IETF) is responsible for developing and defining the standards and protocols that make up the Internet. The IETF was established in 1986, and has since then been the center of development for the technologies that make up what we think of as the Internet. Until now, administration of the IETF has been carried out by helper organizations; the IETF has had no direct staff that was working only for the IETF and its interests. The community that makes up the IETF has as part of a long-term administrative restructuring, decided to create an Administrative Support Activity, the Internet Administrative Support Activity (IASA). The IASA will formally be structured as a function of the Internet Society (ISOC). To run this activity, the IASA Transition Team is now seeking a highly capable individual to serve as IASA Administrative Director (IAD). The IAD will lead the work of supporting the organization that defines and develops the future Internet and associated technologies. As IAD, you will be reporting to the IETF Administrative Oversight Committee (IAOC) and be accountable to the IETF community. This is a highly visible and very demanding job; you will be expected to work daily with some of the leading Internet technologists of the world. You will be expected to: o Document the administrative requirements of the IETF, IESG, IAB and IRTF, and manage the work to fulfill them. o Establish the IASA annual budget, oversee financial administration, and report on IASA work to the IETF. o Work with ISOC and various service providers to establish appropriate agreed budgets and related financial and performance reporting. o Negotiate contracts with service providers and establish procedures for measuring and reporting the performance of these providers. o Serve as the day-to-day responsible person for administrative operations that support the IETF process, managing a number of contractors and working with a number of volunteers. o Serve as the primary staff resource for the IASA. o Work with your contractors and members of the IETF community to provide adequate support and planning for 3 IETF meetings annually, and for frequent meetings and teleconferences of the IAB, IESG, and other bodies that support the IETF. The following characteristics are necessary for this job: o This job is public service. You should be able to work successfully with large numbers of people from numerous countries. This requires a large work capacity, the ability to handle many simultaneous tasks, and the ability to listen carefully. o This is an operations job. IETF meetings are large and complex, and the day-to-day activities of the standards-making process is demanding. You should be adept at getting real results and helping large groups work together towards common goals and deadlines. o This is a public job. You will be required to present the results and achievements of the IASA in front of the community as well as dealing with questions from individual members of the community. One goal of IASA is to achieve as much transparency and accountability as possible, so good communication skills and previous similar experiences are valued. o This job requires a financially astute individual. The IETF is a $2-$3 million per year operation. IETF funds are tight and we expect you to take leadership in establishing our budgetary procedures, our procurement standards, and understanding our revenue sources. In-depth familiarity with the IETF prior to assuming this position is not required, but you must be able to get up to speed quickly and learn the unique culture and requirements of the organization. Likewise, long-term technical experience is not required, but you must be a quick learner and adept at using the Internet effectively. The person hired will be an employee of the Internet Society (ISOC). The Internet Society is based in Reston, Virginia and in Geneva, Switzerland, and the job will require a high level of travel for IETF meetings and preparation and related meetings. You may work out of a home office as a telecommuter or use the Internet Society facilities. In either case, you should be prepared to travel frequently to Virginia, IETF meetings, and the locations where the IETF has contractors. Salary levels commensurate with experience and qualifications. You must be fluent in spoken and written English. Applications should have a covering letter and include a CV. They can either be sent to iad2005(a)isoc.org, or an applicant can fill in the application form at https://www.isoc.org/isoc/general/career/jobapplication.php. For any questions, please contact iad2005(a)isoc.org. Applications will be evaluated starting February 18th, and continuously thereafter. Applications will be evaluated, and the IAD will be selected and appointed, by the IASA transition team. The list of applicants will not be posted publicly, but will be reviewed in confidence by members of the evaluation committee, the IAB, and the IESG. -----BEGIN PGP SIGNATURE----- Version: PGP 8.1 iQA/AwUBQe0026arNKXTPFCVEQKKoQCgrlm/kg2tbiC4kwWas3Y6U2cTNUgAn2EZ KnA5b45M7WiC8pp7JH2vTY4N =pJQ6 -----END PGP SIGNATURE-----

1 0

Draft agenda for Las Vegas
by Susan Harris 18 Jan '05

18 Jan '05

This is *really* late notice, but we are looking for someone who might be willing to moderate an IXP panel, which would be held Tuesday, Feb. 1. If you're interested, please contact nanog-support(a)nanog.org, and see you all soon! --------------------------------------------------------------------------- NANOG 33 Draft Agenda January 30 - February 1, 2005 Las Vegas, Nevada Sunday Tutorials --------------- 1:30 - 3:00 p.m. BGP Multihoming Techniques Level: Introductory Philip Smith, Cisco 1:30 . 3:00 p.m. Build for Success - How to Use Network Design Principles to Differentiate the Good, the Bad, and the Ugly Level: Introductory/Intermediate Barry Greene and Dave Meyer, Cisco 3:00 - 3:30 p.m. BREAK 3:30 - 5:00 p.m. BGP Multihoming Techniques (cont'd.) 3:30 - 5:00 p.m. Understanding MPLS OAM Capabilities for Troubleshooting MPLS Networks Level: Intermediate Moiz Moizuddin and Mukhtiar Shaikh, Cisco 5:00 - 7:30 p.m. Dinner Break 7:30 - 9:30 p.m. Coordinating NANOG: Input From the Community Betty Burke, Merit Steve Feldman, CNET Martin Hannigan, VeriSign Paul Vixie, ISC Monday, January 31 - General Session ------------------------------------ 9:00 a.m. Welcome, Introductions Susan Harris, Merit; Rodney Joffe, UltraDNS 9:15 a.m. A Day in the Security Life of a Service Provider - Qwest Don Smith, Qwest 9:45 a.m. Team Cymru Bogon Route Servers Dave Deitrich, Team Cymru 10:15 a.m. BREAK 10:45 a.m. Open Source IDS Acceleration by Flow Reduction Paul Tatarsky, UCSC 11:15 a.m. Panel: BGP Security Requirements.An Overview of Current Work in the IETF Russ White, Cisco, moderator; Danny McPherson, Arbor Alvero Retana, Cisco; Blaine Christian, MCI 12:00 p.m. LUNCH (on your own) 1:30 p.m. Looking Glasses - What's In It for You? Steve Gibbard, Packet Clearing House 2:00 p.m. IP Fast Reroute: Overview and Things We Are Struggling to Solve Dave Ward, Cisco 2:30 p.m. IP Fast-Reroute: An Analysis of Applicability to a Core Network Alia Atlas, Avici; Gagan Choudhury, AT&T 3:15 p.m. BREAK 3:45 p.m. Implementation of Modern L2 VPNs Scott Gross, MCI 4:15 - Panel: Network-based Layer 2/3 VPN Deployment Considerations 5:15 p.m. Danny McPherson, Arbor, moderator; Ted Seely, Sprint Shane Amante, Level(3); Shankar Rao, Qwest 5:30 - 7:30 p.m. Beer 'n Gear! Monday Evening BOFs & Key Signing --------------------------------- 7:30 - 9:00 p.m. ISP Security and NSP-SEC BOF VII Danny McPherson, Arbor, moderator 9:00 p.m. PGP Key Signing Party Majdi Abbas, Lattice Networks, host 9:00 - 10:30 p.m. Peering BOF VIII William B. Norton, Equinix, moderator Tuesday, October 19 - General Session ------------------------------------- 9:00 a.m. IGP Tuning in an MPLS Network Martin Horneffer, Deutsche Telekom 9:30 a.m. Experience With In-bailiwick Nameservers Masato Minda, JPRS 10:00 a.m. IETF Update Leslie Daigle, VeriSign; Alex Zinin, Alcatel 10:30 a.m. BREAK 11:00 a.m. A Look at the IP Multimedia Subsystem Dave Meyer, Cisco 11:30 a.m. Adjourn

1 0