March 2001 - Test - lists.nanog.org

RE: Statements against new.net?
by Mathew Butler 14 Mar '01

14 Mar '01

The problem is, of course, that it's NOT human-to-human communication. It's machine-to-machine communication, and human-to-machine communication, and DNS was designed to create a mnemonic representation of a way to reach a machine. "Hey, tiger's down!" "Hey, one nine two dot one six eight dot one oh three dot two five three's down!" (Even if you take an example with 192.168 being where ALL the addresses in the network come from: "Hey, one oh three dot two five three's down!") In order for the machine to be able to determine what to do, it must be programmed by the humans that created it. In order for the machine to be able to determine what to do in a situation that has more than one possibly-correct resolution, it must be given a set of rules in order to determine what needs to be done. I will admit that it is possible (not plausible, but possible) for even an email system to be programmed with enough intelligence to be able to deal with the conflict. However, the key word is 'system' -- defined as "all pieces in a computing environment that contribute to a given piece of data being processed the way the humans that are using it desire it to be processed." Which includes all mail servers (speaking SMTP), as well as all mail clients (speaking SMTP, POP3, IMAP, whatever else), and name resolution (DNS, /etc/hosts, NIS, whatever else), and even the underlying virtual circuit technology (TCP/IPv[46]). The entire system must be programmed in a way that is consistent with how the user wants it to work... and getting even two sites to upgrade to a newer version of sendmail at the same time is difficult at best. Much less to get two sites to change their DNS configuration at the same time. The point is: In order to do our jobs, we have to simplify these complex systems we're responsible for as much as possible. At least with a globally-shared root zone, we're removing THAT piece of complexity from the equation so we can determine what needs to be done at a higher level. (Am I lazy? Perhaps. But I'd rather be lazy than crazy.) -Mat Butler Speaking for himself, not for his company. -----Original Message----- From: Vadim Antonov [mailto:avg@kotovnik.com] Sent: Tuesday, March 13, 2001 9:06 PM To: Geoff Huston Cc: nanog(a)merit.edu Subject: Re: Statements against new.net? Of course, one may choose to treat RFC as a gospel, but to me (and i hope to anyone interested in how cognition works to the point of actually getting acquainted with the relevant research) the attached passage sounds quite like a bunch of random noise :) Mostly because it assumes that human-to-human communication is a reasoned process, concerned with consistent intepretation. In fact, most of what makes, for example, art interesting is that it does not have a singular, well defined interpretation. --vadim PS This one, i guess, is brought to you by the Society Against De-Humanization Of Internet Users <tongue firmly in cheek> PPS Yes, I think any form which _restricts_ potential models of communication is bad. Such as forcing communications to be moderated by a singular hierarchical structure. This whole thread won't be there in the first place if the scheme actually worked well in the real world. Hierarchies do not scale and cannot adequately tolerate internalized adversity. On Wed, 14 Mar 2001, Geoff Huston wrote: > At 3/14/01 07:56 AM, Vadim Antonov wrote: > > > >That is based on the assumption that consistency is necessary > >or desireable :) Of course, it is dear to an engineer's mind, > >but the case from the sociological point of view is far from > >clear-cut. In fact, way too many woes of human societies can > >be (at least indirectly) attributed to the misguided attempts > >to enforce consistency. > > This assumption is explicitly addressed in the RFC - I quote: > > ------ > 1.1. Maintenance of a Common Symbol Set > > Effective communications between two parties requires two essential > preconditions: > > - The existence of a common symbol set, and > > - The existence of a common semantic interpretation of these symbols. > Failure to meet the first condition implies a failure to communicate at > all, while failure to meet the second implies that the meaning of the > communication is lost. > > In the case of a public communications system this condition of a common > symbol set with a common semantic interpretation must be further > strengthened to that of a unique symbol set with a unique semantic > interpretation. This condition of uniqueness allows any party to initiate a > communication that can be received and understood by any other party. Such > a condition rules out the ability to define a symbol within some bounded > context. In such a case, once the communication moves out of the context of > interpretation in which it was defined, the meaning of the symbol becomes > lost.

2 1

FW: FW: DECNet over IP?
by Timothy R. McKee 14 Mar '01

14 Mar '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -----Original Message----- From: Rick Irving [mailto:rirving@onecall.net] Sent: Wednesday, March 14, 2001 14:08 To: Timothy R. McKee Subject: Re: FW: DECNet over IP? Cisco bought it. It works! I have been running it for over 5 years, so far. "Timothy R. McKee" wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > - -----Original Message----- > From: Timothy R. McKee [mailto:trm3@nuvox.net] > Sent: Wednesday, March 14, 2001 12:12 > To: Simon Lockhart > Subject: RE: DECNet over IP? > > - -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Back a few years ago the Multinet stack for VMS supported DECNet/TCP > interworking... Don't know who has the product now... If it is truly VAX > and not alpha, the old CMU implementation had a DECNet driver. > > Tim > > - - -----Original Message----- > From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of > Simon Lockhart > Sent: Wednesday, March 14, 2001 11:30 > To: Stillman, Kevin > Cc: 'nanog(a)merit.edu' > Subject: Re: DECNet over IP? > > >Has anyone had any experience successfully getting native DECNet packets > >encapsulated in an IP packet and transmitted over an IP network? The > >solution I am trying to create will allow VAXes to continue to talk DECNet > >on their LANs and have the ability to communicate with DECNet areas on a > WAN > >via IP. Essentially we are try to remove the DECNet protocol from our > >intranet while not disrupting location's DECNet configurations. > > I've not tried it, but my gut reaction would be to use GRE tunnels. Have > you looked on cisco.com for sample configs? > > Simon > - - -- > Simon Lockhart | Tel: +44 (0)1737 839676 > Internet Engineering Manager | Fax: +44 (0)1737 839516 > BBC Internet Services | Email: Simon.Lockhart(a)bbc.co.uk > Kingswood Warren,Tadworth,Surrey,UK | URL: http://support.bbc.co.uk/ > > - -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com> > > iQA/AwUBOq+mWhRIXzEQLahvEQK+6ACgqYZoc23CJoKBBTnOhwYhS8cdczIAoKR5 > euFqSHT+jko90sZNE8Q5Bk2W > =Ncri > - -----END PGP SIGNATURE----- > > -----BEGIN PGP SIGNATURE----- > Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com> > > iQA/AwUBOq+uWBRIXzEQLahvEQIyMwCcCJmFrXtcln3VrXumw+wzDUSzrC4An0Oh > GN6mImDsbwExEqfzqqJDrgSW > =O+xu > -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com> iQA/AwUBOq/UkBRIXzEQLahvEQLfHACeNXh2w/IzGQ0Ont04kmoKL2nY58MAoPUF SBEuEAZwvzpqosBACbqCMbEF =6f44 -----END PGP SIGNATURE-----

1 0

Single DNS Root (was Re: Statements against new.net?)
by Simon Higgs 14 Mar '01

14 Mar '01

At 10:21 PM 3/13/01 -0500, you wrote: >but I've been saying ever since this whole >topic came up that the worst possible outcome was more than one root. >Nothing that has happened in the interim has changed my mind about that. Yes, but you haven't been part of the solution either. That makes you part of the problem. Shouting "oh my, how terrible" in All Caps doesn't help solve the situation or stop the problem from occurring again. There is no technical need for more than one root. Every alt.root worth talking to will admit that. There are multiple roots because of the **multiple failures** to introduce competition to the NSI registry. Draft Postel was canned in favor of the gTLD-MOU which was canned in favor of the Green/White paper that founded ICANN - who has now disenfranchised almost everybody who was once willing to give it a chance (if not $50,000). With the growth of alt.roots, you are seeing the Internet route around a single point of failure - specifically competition within the US Government root zone. The IAB's fabulously entitled "Unique DNS Root" is seen as major damage to the health of the Internet, and the Internet community is routing around it with alt.roots. Is there a pattern here? Yes. Can it be called a consensus? Yes. The alt.roots are doing DNS coordination on their own without an ICANN expense account or a "big 4" accounting firm. The two roots which are doing the least coordination are the ones that have tried to take ICANN/IANA head-on and lost (PGP Media/Name.Space and .TV/IdeaLab/New.net). Is there a pattern here? Yes. Can it be called a consensus? Yes. What I'm getting at here is that the alt.root community would probably rather go away and become registries under RFC1591 (even Postel admitted to me RFC1591 isn't just for the ccTLDs) than have to endure a minority share of Internet users. Because the access to the US Government root is completely tied up by Verisign and ICANN playing kissy-kissy (I won't go into the current agreement farce), the Internet community is voting away from the US Government root on a daily basis. The longer the ICANN/DoC doors are closed to the "Unique DNS Root", the more alt.roots will spring up. And the more that spring up, the more of the Internet will support them. Is there a pattern here? Yes. Can it be called a consensus? Yes. The solution is simple. Open up the US Government root to all parties on an equitable basis (RFC1591). Or accept the consequences of a fractured root. All I'm trying to do is some damage control until either one happens. I told the IAHC back in 1996 this would happen and it's happened. Could multiple roots have been avoided? Damn right they could have. Crying over it now doesn't solve the problem or make them "magically" go away. Are you going to stick your head back in the sand and say "oh, how terrible" over and over, or are you going to help the alt.root community come to a unified single-root consensus? Best Regards, Simon -- "First they ignore you, then they laugh at you, then they fight you, and then you win. And once you have won, they join you." - Mahatma Gandhi

1 0

Re: Statements against new.net?
by Simon Higgs 14 Mar '01

14 Mar '01

At 11:29 AM 3/13/01 -0800, Patrick Greenwell wrote: >The fact that there currently exists several different operations root >server networks(ORSC, Pacific Root, Name.Space) to name a few. In fact, >if you ask ICANN board member Karl Auerbach, he'll tell you he uses the ORSC >root servers. I'll raise you a TLD. Karl Auerbach has put the .EWE TLD into the ORSC root. ***We Have An ICANN Board Member With A TLD In An ALT.ROOT*** Y'all should let that sink in for a while. Best Regards, Simon -- "You can't vote on facts" - Brian Carpenter

1 0

RE: DECNet over IP?
by Stillman, Kevin 14 Mar '01

14 Mar '01

Thank you all for your advise. Unfortunately I am working with a Bay/NortelNetwork environment. Nortel's implementation of GRE tunneling does not support DECNet Phase IV. The kludge of a solution that has been proposed to me by Nortel is transitioning the native DECNet phase IV communication to DECNet phase V, which works in OSI, then tunnel the OSI using GRE. I'm going to try it in a lab, but I have serious doubts about how well it will work. It is a scary proposition. If anyone has actually seen this work I love to hear from you. The solution that I need to create is one that will not require the DEC administrators on LANs using our WAN for DECNet interconnectivity to make any changes on their VAXes, printers... etc. That means Compaq or third party software on the VAX cannot be part of the solution. Basically it needs to be transparent to the LAN. If Cisco is capable of tunneling DECNet phase IV right out of the box, then I think I may have my solution. This would mean the router would run DECNet on the ethernet and run a GRE tunnel over the IP network on the sync port(s). Does this sound like the right idea? Thanks again! Kevin

1 0

Re: Statements against new.net?
by Simon Higgs 14 Mar '01

14 Mar '01

At 01:23 PM 3/13/01 -0500, you wrote: >To be >precise, what is your response to this, the second paragraph of the >document? > > 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. Here it is, a proposed supplement to RFC2826: http://www.ietf.org/internet-drafts/draft-higgs-root-defs-00.txt It's called "cat herding". :-) The short answer is that there's a far better chance of coordinating the alt.roots into a single unified root, than suffering the consequences of a permanent and very real root fragmentation by ignoring them. Best Regards, Simon -- DNS is not a sacred cow that cannot be replaced by something better.

1 0

Re: Statements against new.net?
by Simon Higgs 14 Mar '01

14 Mar '01

Hank, We tell them to use the ORSC root as it is the most comprehensive one out there. Once the collisions from New.net have been ironed out, the non-colliding new TLDs will be put in the ORSC root if they are not already there. FYI, there's an IETF draft on the guidelines for avoiding multiple-root collisions here: http://www.ietf.org/internet-drafts/draft-higgs-root-defs-00.txt Feedback welcome. >Do any ISPs or web hosting companies have publically available statements >on their web sites stating that they will not support the new new.net >domains and why they won't? I am getting more requests from users to >change our DNS root servers to support this and wanted to see what others >tell their users. Any IETF/ICANN statement available? > >Thanks, >Hank Best Regards, Simon -- DNS is not a sacred cow that cannot be replaced by something better.

1 0

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

14 Mar '01

> From: Valdis.Kletnieks(a)vt.edu [mailto:Valdis.Kletnieks@vt.edu] > Sent: Tuesday, March 13, 2001 12:03 PM > I fail to see how RFC2826 is in any way "political". Upon > careful re-reading > it boils down to: > > If you use one root, everybody agrees what things look like. > > If you use multiple roots, what people will see depends on > which root they ask. > > How is this political? By the sheer fact that they included a non-technical value-judgment.

8 10

RE: Statements against new.net?
by Mathew Butler 14 Mar '01

14 Mar '01

Y'know, I upon reading this again, I have to point something out: The current set of root servers is not administered by a unique naming authority. The root zone itself is administered by the unique naming authority. The zone needs to have a Single Point of Contact. The root servers themselves need to have a unique PoC for each, and it is much more desirable to the Internet at large to each root server administered by a separate entity -- be it vix.com, isi.edu, APNIC, whatever and whoever has the bandwidth, knowledge, expertise, and money to support it. But the zone itself needs to have an entity who is ultimately responsible for what goes into the zone and what doesn't. Now, I'm going to say something here (and these are my own opinions): In the context of Certifying Authorities for SSL certificates, we have multiple, unique roots. Lots of them. In Internet Explorer alone, there are more than 80 that are embedded upon installation, and my set of CA roots is different from your set of CA roots [this is a fact, since I run a CA internal to my company]. This is roughly akin to the idea of including a root.zone on each client, that makes it almost impossible to determine which roots each client trusts. [PLEASE do not say anything about 'barrier to entry' or 'a trusted root can't sign an intermediate root' -- the first is high indeed, and the second is patently false. I'm only bringing this up to explain a concept.] Now, in the case a website has a CA that doesn't match anything that's in the browser, there's an interactive dialog to determine which action to take -- whether to accept it anyway, or to cancel the connection. In the event of multiple, conflicting TLDs, though, there's no way for that interactive exchange with the user to occur. Say I have an email address of 'winged(a)wolf.animal-lover', and someone doesn't like the way the 'animal-lover.' TLD is being run, so they set another root up with the 'animal-lover.' TLD and assign it to someone else. And one of my friends is on an ISP that uses this alternate root. And my friend tries to send me an email. So, where will mail to my mail address 'winged(a)wolf.animal-lover' go to? The client on my friend's system will send it to the ISP's mail server, which will look up MX wolf.animal-lover on the conflicting root. Which will almost certainly not be the MX wolf.animal-lover that I use. So at best it gets bounced, at worst it goes to a completely uninvolved third party -- and my friend would never even know. (And neither would I.) And the next time my friend saw me, he'd ask me about it, and I'd have to say "it works for me", and then we'd spend a lot of time figuring out where the problem was. And then we'd yell and scream and curse and swear at the anarchy that led to Usenet being what it is today... and most likely create our own little VPN for the exchange of mail between our sites. Do we really -want- more VPN traffic flowing over the backbone? An implicit assumption made on the Internet today is that "e-mail addresses will be unique and will route to the proper person unless there is a technical reason that that is impossible". (Don't laugh, this is the view of everyone I've ever talked with -- they don't think it's possible that someone could take over their email account.) So 'mbutler(a)tonbu.com' will always route to me, unless the MX is wrong or my mail server's down. However, if we have conflicting zones, we'll never be able to guarantee communication is going to work properly across the Internet, and we'll be forced back to phone or pen&paper for REALLY important stuff. (Which will also have the effect of completely removing the trust essential for e-commerce to occur, since it'll never be truly possible to determine which TLD root you're going through.) It may be possible for larger corporations to buy through ALL registries for a given TLD... but that is inefficient, and if someone set up a registry for net. or com. or org. or mil., and then set up an alternate root for it, and someone else used that root... can you imagine the carnage? (Especially given ~$20/year per registry.) Name hijacking would be what it is, and there are laws against it (all the trademark laws, much less the fraud, malfeasance, misrepresentation, and many others) all around the world. Personally, I hope that the ICANN files a misrepresentation/fraud suit against new.net, and soon... though ICANN's way of doing things must not be condoned, at this moment the new.net system is NOT the correct way to fix the issue. -Mat Butler Speaking for himself, not his company -----Original Message----- From: Patrick Greenwell [mailto:patrick@cybernothing.org] Sent: Tuesday, March 13, 2001 8:40 PM To: Valdis.Kletnieks(a)vt.edu Cc: nanog(a)merit.edu Subject: Re: Statements against new.net? "...That one root must be supported by a set of coordinated root servers administered by a unique naming authority."

1 0

FW: DECNet over IP?
by Timothy R. McKee 14 Mar '01

14 Mar '01

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 - -----Original Message----- From: Timothy R. McKee [mailto:trm3@nuvox.net] Sent: Wednesday, March 14, 2001 12:12 To: Simon Lockhart Subject: RE: DECNet over IP? - -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Back a few years ago the Multinet stack for VMS supported DECNet/TCP interworking... Don't know who has the product now... If it is truly VAX and not alpha, the old CMU implementation had a DECNet driver. Tim - - -----Original Message----- From: owner-nanog(a)merit.edu [mailto:owner-nanog@merit.edu]On Behalf Of Simon Lockhart Sent: Wednesday, March 14, 2001 11:30 To: Stillman, Kevin Cc: 'nanog(a)merit.edu' Subject: Re: DECNet over IP? >Has anyone had any experience successfully getting native DECNet packets >encapsulated in an IP packet and transmitted over an IP network? The >solution I am trying to create will allow VAXes to continue to talk DECNet >on their LANs and have the ability to communicate with DECNet areas on a WAN >via IP. Essentially we are try to remove the DECNet protocol from our >intranet while not disrupting location's DECNet configurations. I've not tried it, but my gut reaction would be to use GRE tunnels. Have you looked on cisco.com for sample configs? Simon - - -- Simon Lockhart | Tel: +44 (0)1737 839676 Internet Engineering Manager | Fax: +44 (0)1737 839516 BBC Internet Services | Email: Simon.Lockhart(a)bbc.co.uk Kingswood Warren,Tadworth,Surrey,UK | URL: http://support.bbc.co.uk/ - -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com> iQA/AwUBOq+mWhRIXzEQLahvEQK+6ACgqYZoc23CJoKBBTnOhwYhS8cdczIAoKR5 euFqSHT+jko90sZNE8Q5Bk2W =Ncri - -----END PGP SIGNATURE----- -----BEGIN PGP SIGNATURE----- Version: PGPfreeware 7.0.3 for non-commercial use <http://www.pgp.com> iQA/AwUBOq+uWBRIXzEQLahvEQIyMwCcCJmFrXtcln3VrXumw+wzDUSzrC4An0Oh GN6mImDsbwExEqfzqqJDrgSW =O+xu -----END PGP SIGNATURE-----

2 1