May 1997 - Test - lists.nanog.org

Peerage versus Peering
by William Allen Simpson 04 May '97

04 May '97

> From: Peter Lothberg <roll(a)Stupi.SE> > Look up ''peer'' in a dictionary, in this context it means something > like ''networks of equal size''. > This silliness comes up every so often, not always from non-native English speakers. Peer actually means several unrelated things. One of which (the first definition in my Webster's) is a member of a body called "the House of Lords" -- noblemen.... This comes from the Latin for "equal", yet is distinctly not equality. Although it seems that there are some who desire to apply that usage, that certainly is not what the rest of us are talking about here! The 5th definition is the one which I understand to apply: any associate. > The internet is moving towards a scenario with a handfull global > players that will be ''peers'' everyone else will become a customer. > As a matter of network engineering, this Internet has not historically established a peerage, a heirarchy of "first among equals". TCP/IP (and PPP and every other protocol I've worked on in this environment) establishes "peer-to-peer" connectivity. A peer is merely any entity with which you have established communication. More prosaically, someone with whom you "look closely". Where this term comes from, to quote the dictionary, is "entymology uncertain". WSimpson(a)UMich.edu Key fingerprint = 17 40 5E 67 15 6F 31 26 DD 0D B9 9B 6A 15 2C 32 BSimpson(a)MorningStar.com Key fingerprint = 2E 07 23 03 C5 62 70 D3 59 B1 4F 5E 1D C2 C1 A2

2 1

Re: UUNET settlement - A call to arms?
by Eric Sobocinski 04 May '97

04 May '97

On Fri, 2 May 1997 at 15:17 PDT, Mike Leber <mleber(a)he.net> wrote: > > On Fri, 2 May 1997, Bownes, Robert M. (EXCH) wrote: > > What I would like to do is to connect to, for example, Sprint *just to > > get to folks who > > buy from Sprint*, not to transit through them to get to a NAP someplace. > > You can already do this. > > Simply buy a T1 from Sprint and filter out all of the non Sprint routes. > Where you might have normally purchased 10 Mbps transit service, you can > now use just a T1 with the appropriate filters. It will become a pain to > load balance and capacity plan all of those little pipes (increased > expense and complexity), but hey, if you don't want to or can't use an > exchange point this is an alternative. Uh, no, but thank you for playing. It's the other direction that is the problem. How does he advertise routes to Sprint so that Sprint customers can reach him but without Sprint advertising his routes at exchange points? That's the other half of what he's asking for, and he can't do it unless Sprint sets up filters to do it for him.

2 1

Re: eDNS - Temporary Freeze
by salo＠msc.edu 04 May '97

04 May '97

> Date: Sun, 4 May 1997 09:21:07 -0700 (PDT) > From: Michael Dillon <michael(a)memra.com> > Subject: Re: eDNS - Temporary Freeze > [...] > Where does NSI get the idea that it can abscond with the database it > developped under contract when the contractor is the U.S. government. > [...] Perhaps, from the Federal Acquisition Regulations (FARs). Perhaps, from West Publishing. (It may be instructive to examine some of the West Publishing issues.) NSI might assert copyright of the .com database, (the database with, for example, the contact information, payment information, etc.). I believe that Federal contractors own the copyright for work done under government contract. The U.S. government probably has fairly broad rights to the .com database developed by NSI under government contract. However, the U.S. government may not have the right to give it to someone else. (I am not a lawyer...) -tjs

1 0

Re: eDNS - Temporary Freeze
by Paul A Vixie 04 May '97

04 May '97

> You know, all this talk about the Internet and DNS zones and who owns them > has lead me to believe that really, the US government should stay the hell > out of it. I agree. The FCC has reasonable cause to take care of the US domain, but just as international radio frequencies are allocated internationally, so must IP address space and DNS toplevel domains. > Now, 15 years ago, the IANA might have been in the position to delgate > such power, but today... the Internet is radically different, and the > contract between InterNIC & IANA should be void because the IANA doesn't > *OWN* DNS any more. The US government doesn't *OWN* the Internet therefore > control over the root zone shouldn't be relinquished to them. You're confusing IANA with a government entity. IANA is where this stuff comes from because, for 25 years, IANA has been where this stuff comes from. The world has come to trust IANA's judgement in who IANA gets its new TLD's from (which is currently the U.N. and the IETF, and will soon include IAHC's Council of Registrars). For some reason the AlterNIC/eDNS people don't look to IANA like international treaty organizations with strong committments to reflecting public consensus. Your guess as to this reason is probably as good as mine.

1 0

Re: eDNS - Temporary Freeze
by Paul A Vixie 04 May '97

04 May '97

I wrote: > @ Jim Fleming's so called "Root Server Council" is > @ an insult to our intelligence. Someone wrote me and asked: > As a root name server operator, where do you stand > on the following issues ? > > =============== > > 1. What are the confederations common guidelines > on name syntax ? > - One letter TLDs ? > - Two letter TLDs ? > - Dashes ? > - Plurals ? There is no confederation. As a root name server operator I have no position on the above issues. Every zone has an owner, and every zone has some number of operators. The owner of "." is the IANA, and you should direct questions about TLDs (which have to be entered into ".") to the owner of the "." zone, which is the IANA. I believe that the IANA has a reasonable confidence level in the IAHC, and would be likely to simply refer your questions to the Council of Registrars. > 2. How will the confederations be "synced" ? > (i.e. How will they exchange info on which > TLDs they support ?) There is no confederation. As a root name server operator I will publish whatever "." zone the IANA directs me to publish. Synchronization of "." servers is currently accomplished via AXFR (see RFC 1035). > 3. Once a Confederation agrees to recogize a TLD > will all Confederations agree to use the same > TLD Name Server referrral NS Resource Records ? See above. There is no confederation. Then, Karl made the following (intentionally?) misleading public statements: > That Mr. Vixie's server loads from a.root-servers.net, which is controlled > by NSI. This is true. > If NSI makes changes in that zone, Mr. Vixie's server will reflect them. This is true. What Karl neglected to mention is that if pigs had wings they could fly, and that furthermore, pigs don't have wings, so they don't fly. But if they did have wings they would fly REALLY HIGH. NSI has never, ever, ever, ever made a change to any of the domains it publishes for other parties, except where asked to do so my the owner of the domain in question. So for example, whenever the IANA recognizes a new server for a TLD, it sends mail to the current InterNIC contractor asking that the "." zone be changed to reflect this. And when NIC.MIL changes an SLD delegation under _its_ domain, it sends the current InterNIC contractor mail asking that this change be made. And when Vixie Enterprises wants to change a second level delegation under COM (adding or deleting a name server at VIX.COM for example), we send mail to the current InterNIC contractor asking that this be done. The current InterNIC contractor gets _so_many_ such requests that it even has e-mailable templates which are robotically processed. The previous NIC contractor (SRI) used to accept change requests in postal mail, facsimile, or even (gasp!) by telephone.

6 7

peers, peer-nots, judges/politicians, and you
by Paul A Vixie 04 May '97

04 May '97

Here's something with cobwebs on it that bears on the current UUNET discussion. To: xxx Subject: text i removed from my recent message to nanog -- xxx Date: Fri, 10 May 1996 21:17:03 -0700 From: Paul A Vixie <vixie(a)wisdom.home.vix.com> But what's interesting to me about this being your reason for not coming to CIX is that your policy is being shaped by other policies that you don't like. You have the option of configuring a CIX-connected router to avoid CIX for paths which have AS xxxx in them. Ultimately the battle lines will be drawn, and there will be three distinct camps of folks (see below). In the mean while, the fact that the lines aren't clear is letting a lot of folks play "chicken" with each other's customers, and that's too bad. When the battle lines form up, you'll see the peers, the peer-nots, and the lawyers/judges/politicians. My personal and oft-stated goal is to make the set of "peers" so large and so well interconnected that the "peer-nots" will get complaints from their own customers if they can't reach all the "peers". Choosing not to join CIX, or any interconnect you can afford to join, for the reason you gave, works against the full connectivity of the "peers" in the above black-and-white picture, and this in turn will make it easier for the "peer-nots" to divide you all and conquer you, one at a time, since at no time will they feel enough pressure from their own customer bases.

3 2

Re: UUNET and peering
by Hank Nussbacher 04 May '97

04 May '97

WCOM (stock ticker) which owns Uunet, has had its stock go up from 22 to 25 1/4 from Wed April 30 till the end of Friday May 2. Perhaps the market sees UUnet's move as a wise financial decision? Hank

3 2

NANOG mail loop
by Alex.Bligh 04 May '97

04 May '97

Delightful though this all is, do we have to read it twice? There appears to be a mail loop here... Alex Bligh Xara Networks Received: from merit.edu (merit.edu [198.108.1.42]) by diamond.xara.net (8.7.4/8.7.1) with ESMTP id MAA09379 for <nanog(a)xara.net>; Sun, 4 May 1997 12:32:11 +0100 (BST) Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id HAA08319; Sun, 4 May 1997 07:22:32 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sun, 4 May 1997 07:19:35 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id HAA08265 for nanog-outgoing; Sun, 4 May 1997 07:19:35 -0400 (EDT) Received: from tsb.inet-images.com (tsb.inet-images.com [204.91.224.2]) by merit.edu (8.8.5/8.8.5) with ESMTP id HAA08261 for <nanog(a)merit.edu>; Sun, 4 May 1997 07:19:30 -0400 (EDT) Received: (from apu@localhost) by tsb.inet-images.com (8.8.5/8.7.3) id HAA05476 for sp fld(a)erols.com; Sun, 4 May 1997 07:24:23 -0400 Received: from merit.edu (merit.edu [198.108.1.42]) by tsb.inet-images.com (8.8.5/8.7. 3) with ESMTP id HAA05471 for <apu(a)spfld.com>; Sun, 4 May 1997 07:24:20 -0400 Received: from localhost (daemon@localhost) by merit.edu (8.8.5/8.8.5) with SMTP id HAA08138; Sun, 4 May 1997 07:00:58 -0400 (EDT) Received: by merit.edu (bulk_mailer v1.5); Sun, 4 May 1997 06:59:32 -0400 Received: (from majordom@localhost) by merit.edu (8.8.5/8.8.5) id GAA08122 for nanog-outgoing; Sun, 4 May 1997 06:59:31 -0400 (EDT) Received: from songbird.com (kent(a)songbird.com [206.14.4.2]) by merit.edu (8.8.5/8.8.5) with ESMTP id GAA08118 for <nanog(a)merit.edu>; Sun, 4 May 1997 06:59:28 -0400 (EDT) Received: (from kent@localhost) by songbird.com (8.8.4/8.8.4) id CAA07110; Sun, 4 May 1997 02:58:43 -0700 X-Envelope: <apu(a)spfld.com> Message-ID: <19970504025843.42873(a)bywater.songbird.com> Date: Sun, 4 May 1997 02:58:43 -0700 From: Kent Crispin <kent(a)songbird.com> To: nanog(a)merit.edu Subject: Re: UUNET and peering References: <2.2.16.19970504072926.706f4576(a)rex.ibm.net.il> Mime-Version: 1.0 X-Mailer: Mutt 0.66 X-Disclaimer: Things are not as they seem X-PGP-Key: http://songbird.com/kent/pgp_key.html X-Loop: apu(a)inet-images.com Sender: owner-nanog(a)merit.edu Content-Type: text/plain; charset=us-ascii Content-Length: 676

1 0

Re: UUNET Pulling Peering Agreements & replacing them with charging under non-disclosure?
by Peter Lothberg 04 May '97

04 May '97

> UUNet's customers and MSN etc if a company like ConXion no longer had UUNET > peering? Look up ''peer'' in a dictionary, in this context it means something like ''networks of equal size''. The internet is moving towards a scenario with a handfull global players that will be ''peers'' everyone else will become a customer. --Peter

6 5

eDNS - Temporary Freeze
by Jim Fleming 03 May '97

03 May '97

Because of the enormous amount of interest in eDNS and the rapid growth of Registration Authorities (RAs) and TLD Registries under the eDNS plan, a temporary Freeze has been placed on the eDNS Root Zone [1]. This Freeze should allow all of the major Root Name Server Confederations to come to a round table consensus with "dot" clearly in the center of the table, out of reach of everyone's arms, military or otherwise. The major Root Name Server Confederations at this point in time are: AlterNIC - ?? Servers eDNS - 5 Servers (FROZEN) InterNIC - 9 Legacy Servers name.space - 12 Servers NSI/ISI - 4 Servers Everyone, especially ISPs and NANOG members, should encourage the owner/operators of the Root Name Servers in the above Confederations to represent them at these historic round table discussions which will be largely held in the open environment of the Internet and in traditional Internet forums. Think global and act local... =============== The consensus needed covers... 1. What are the confederations common guidelines on name syntax ? - One letter TLDs ? - Two letter TLDs ? - Dashes ? - Plurals ? 2. How will the confederations be "synced" ? (i.e. How will they exchange info on which TLDs they support ?) 3. Once a Confederation agrees to recogize a TLD will all Confederations agree to use the same TLD Name Server referrral NS Resource Records ? =============== I think that we should also add that there are CURRENTLY five parties at the Confederation Round Table. (AlterNIC, eDNS, InterNIC, name.space, NSI/ISI) There are clearly more Confederations coming. Consensus on the above basic issues is needed before the Root Name Server Confederation round table grows larger. [1] =========================================== ---------- From: edns-root@MCS.Net[SMTP:edns-root@MCS.Net] Sent: Saturday, May 03, 1997 11:14 AM To: edns-operators(a)MCS.Net Cc: edns-discuss(a)MCS.Net; newdom(a)ar.com Subject: Violations of Charter Over the last couple of weeks, eDNS has been grappling with apparent unfair practices with regards to TLD allocation and Registration Authority (RA) supervision. In an attempt to fairly address these issues, a Root Server Council (RSC) was formed for the sole purpose of interpreting the existing eDNS Charter. On Wednesday, the RSC issued a list of RAs and TLDs that appeared to be deficient in adhering to the letter and spirit of the Charter. Since that time, one RA has challanged the basis for this summary. Since these are difficult decisions and it is often hard to decide where to draw the line, the RSC felt that it would be better to decide these issues using a substantial public comment process from all Internet stakeholders, not just the RSC or other parties involved in eDNS. For these reasons, the RSC today has decided the following: - As of today, the RSC will place a temporary moratorium on the issuance of any new TLDs, RAs, or Registries. The only activity that will be approved are owner submitted Deletes, and Modifies required for system integretity. - The difficult questions facing the RSC will be brought before the entire Internet community for public review. Upon consensus, the questionable RAs and TLDs will either be deleted, modified, or accepted. - This process is to begin with Indusrty stakeholders at the upcoming Interop Conference in Las Vegas. The RSC also plans to request a meeting with the U.S. Government on this topic, as well as seek input from Internet and International organizations and Governments. Additional comments will be released before the upcoming Interop BOF (Birds of a Feather) Meeting schedule for Tuesday, May 6th at 8:00 p.m. The entire Internet community is invited to participate in this public comment process to help shape the future direction of eDNS. RSC. Regards, Jay Fenello President, Iperdome, Inc. 404-250-3242 http://www.iperdome.com ===============================================

3 3