RE: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
3) What's wrong with treating assignments like property and setting up a market to buy and sell them? There's plenty of precedent for this: Mineral rights, mining claims, Oil and gas leases, radio spectrum. Before you start making inferences from an analogy, you had better be sure that you have the right analogy. IP addresses are not like any of the things that you mention. They are like phone numbers which also are not property and also managed by a central admin function NANPA. --Michael Dillon
Re: [routing-wg]BGP Update Report
On Fri, 8 Sep 2006, Joe Provo wrote: On Fri, Sep 08, 2006 at 05:57:10PM +0300, Hank Nussbacher wrote: On Fri, 8 Sep 2006, [EMAIL PROTECTED] wrote: Strike me as curious, but this seems as if Connexion by Boeing is handing off a /24 from ASN to ASN as a certain plane moves over certain geographic areas. Or is there some other explanation? Detailed at nanog 31 (among other meetings): http://www.nanog.org/mtg-0405/abarbanel.html 2005 detail from a blogger: http://bayosphere.com/node/879 2006 detail from another blogger: http://www.renesys.com/blog/2006/04/tracking_plane_flight_on_inter.shtml -- RSUC / GweepNet / Spunk / FnB / Usenix / SAGE Yep. And they also presented it on this side of the Atlantic, back in May'2004: http://www.ripe.net/ripe/meetings/ripe-48/presentations/ripe48-routing-global.pdf Best Regards, ./Carlos Skype: cf916183694 -- Wide Area Network (WAN) Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt Internet is just routes (196663/675), naming (millions) and... people!
Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
Your statement about preferential treatment is factually incorrect. Larger ARIN members do not get larger allocations. It is the larger network infrastructures that get the larger allocations which is not directly tied to the size of the company. Yes, larger companies often have larger infrastructures. And that's the point: A company that is established gets preferential treatment over one that is not; that is called a barrier to entry by the anti-trust crowd. You need to understand the basics of networking to see that this is NOT preferential treatment but is instead even-handed treatment. You see, a network is a collection of devices interconnected with circuits. Each point where a circuit connects to a device is called an interface. Devices may have more than one interface. Typically, the devices used by network operators have many interfaces. IP addresses are numbers used to uniquely identify such interfaces and the Internet Protocol (IP) requires that these numbers be assigned in a structured manner. It is then obvious that larger networks have more interfaces and therefore can TECHNICALLY justify more addresses. This is even-handed treatment even though small companies end up with less addresses than large companies. You may feel that such a barrier is justified and fair, but those on the other side of it (or more importantly, their lawyers) are likely to disagree. Yes, lawyers do not understand networks. No doubt some of them will read the above text and begin to get a glimmer of understanding. Of course it's directly connected; all you have to do is look at the current fee schedule and you'll see: /24 = $4.88/IP /23 = $2.44/IP That is completely untrue. ARIN's web page here http://www.arin.net/billing/fee_schedule.html says nothing of the sort. In fact, ARIN's annual fees are structure so that organizations which have a larger transaction volume pay a larger fee. These transactions could be IP address applications or SWIP transactions or in-addr.arpa traffic. The size categories are just a rough rule of thumb for categorizing organizations that has been accepted by the ARIN members themselves. So, just between the two ends of the fee schedule, we have a difference of _two orders of magnitude_ in how much an registrant pays divided by how much address space they get. Large organizations get their allocations bit by bit, applying for 3-6 months requirements at a time. Small organizations may have only a single allocation. Besides the above, Kremen also points out that larger prefixes are more likely to be routed, therefore refusing to grant larger prefixes (which aren't justified, in ARIN's view) is another barrier to entry. Again, since the folks deciding these policies are, by and large, folks who are already major players in the market, it's easy to put an anticometitive slant on that. Routability decisions are not made by ARIN. If anyone is unhappy with routability they should be suing those organizations which recommend route filtering. But they would have to prove that the route filtering is not technically justified which will be difficult when all the expert witnesses are on the other side. --Michael Dillon
Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
Since the public policy meetings and mailing lists where consensus is judged are open to any interested party, it is very hard to view this as an anti-competitive act in my opinion. Kremen filed the suit on April 12, 2006. That is the last day of the ARIN public meeting in Montreal. I was at the Montreal meeting and Kremen never appeared publicly there to question ARIN's actions. It make me think that he did not make a reasonable attempt to resolve the situation out of court. --Michael Dillon
RE: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?
Even if you assume that allocations made by ARIN are not property, it's hard to argue that pre-ARIN allocations are not. They're not subject to revocation and their grant wasn't conditioned on compliance with policies. The reason that ARIN allocations are not property is that pre-ARIN allocations were not property. ARIN is merely continuing the former process with more structure and public oversight. Are telephone numbers property? In any case, since the conditions of the pre-ARIN allocations were all informal, unrecorded and largely verbal, nobody can prove that there was any kind of irrevocable grant. --Michael Dillon
Re: comast email issues, who else has them?
On Sat, 2 Sep 2006, Fergie wrote: Ack: X-Originating-From should be mandatory. Far better to use a Received: header stating HTTP in the with protocol field. (And the IANA registry should be updated to include that as one of the standard values.) Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR GOOD.
Re: [routing-wg]BGP Update Report
On Mon, Sep 11, 2006 at 12:32:57PM +0200, Oliver Bartels wrote: Hi Gert, On Fri, 8 Sep 2006 18:06:00 +0200, Gert Doering wrote: Ummm, well, this is a damn fast plane if it will reach another continent 1843 times per day (or even per week)... - which should be the only time the BGP announcement moves. Sounds more like the BGP-follows-plane system has some stability problems. Nack. Probably they are using low or medium earth orbit satellites, which _are_ damn fast in orbit. Otherwise the round trip time would be unacceptably high. As the whole thing is 3D, some of them might have contact to ground stations on this or the other side of the great lake, depending on their 3D position, even thru the plane travels on a well defined track (probably a 3D circle, too) in just one direction only. Ceterum censeo: Nevertheless this moving-clients application shows some demand for a true-location-independend IP-addresses announcement feature (provider independend roaming) in IPv6, as in v4 (even thru this isn't the standard way, but Connexion is anything but standard). Shim etc. is not sufficient ... One might also imagine that more globally-friendly way to implement this would have been to build a network (VPN would be adequate) between the ground stations and assign each plane a prefix out of a block whose subnets are only dynamically advertsed within that network/VPN. Doing that would prevent the rest of the global Internet from having to track 1000+ routing changes per prefix per day as satellite handoffs are performed. --Vince
Re: comast email issues, who else has them?
On Mon, 11 Sep 2006, Tony Finch wrote: On Sat, 2 Sep 2006, Fergie wrote: Ack: X-Originating-From should be mandatory. Far better to use a Received: header stating HTTP in the with protocol field. (And the IANA registry should be updated to include that as one of the standard values.) That suggestion is likely to be contrary to SMTP design. Received trace fields are for use of recording of where data that was RFC2822 formatted came from and how. Use of these fields also assumes that start of email transmission took place somewhere else. The with clause in Received is used to indicate the transport protocol but assumes that data itself is already properly formatted (compare to that the same type of L7 protocol can use either TCP or UDP; this is not perfect fit but gives you some idea). In case of web-based email services however, the start of the transmission is the webserver which is the one putting data in RFC2822 format and initiating the transmission. So use of with HTTP is inappropriate here - the only case where with HTTP would be appropriate is when email client like Thunderbird creates entire email message as it normally would but instead of using SMTP or SUBMIT to send it, it is sending the data using HTTP PUT or SOAP or XML-RPC - this is not the case with web-based email. If you really want to indicate the source of transmission for non-SMTP origination point, the best is to create new trace field for this purpose. With Received the closest clause would be via but I think via is largely for use with complete message being gatewayed through non-SMTP protocol and this is probably not the correct use of it either. -- William Leibzon Elan Networks [EMAIL PROTECTED]
[Fwd: RE: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
Even if you assume that allocations made by ARIN are not property, it's hard to argue that pre-ARIN allocations are not. They're not subject to revocation and their grant wasn't conditioned on compliance with policies. The reason that ARIN allocations are not property is that pre-ARIN allocations were not property. ARIN is merely continuing the former process with more structure and public oversight. Are telephone numbers property? In any case, since the conditions of the pre-ARIN allocations were all informal, unrecorded and largely verbal, nobody can prove that there was any kind of irrevocable grant. --Michael Dillon IP addresses appear to be property - - read http://news.findlaw.com/ hdocs/docs/cyberlaw/kremencohen72503opn.pdf. Given that domain names are property, IP addresses should be property, especially in California where are constitution states All things of value are property Also, what about ARINS hardcore attitude making it near impossible to aquire ip space, even when you justify it's use? I have had nightmares myself as well as MANY of my collegues share similar experiences. I am having an issue right now with a UNIVERSITY in Mexico tryin to get ip's from the mexican counterpart. Why is it that they involve lawyers, ask you all your customers names and etc... This is more information than I think they should be requiring. Any company that wishes to engage in business as an ISP or provider in some capacity should be granted the right to their own ip space. We cannot trust using ips swipped to us by upstreams and the like. Its just not safe to do that and you lose control. Actually, is there anyone else who shares these nightmares with me? I brought up the lawsuit with Kremen and ARIN to see if this is a common issue. What are your views, and can someone share nightmare stories? Don't get me wrong, I think there has to be SOME due dilligence, however their methodology is a bit hitlerish. If you have had similar problems, contact me off list or on, if you wish. I'd love to talk to you. AIM is preferred. Chris Jester Suavemente, INC. SplitInfinity Networks 619-227-8845 AIM: NJesterIII ICQ: 64791506
Re: [routing-wg]BGP Update Report
On Mon, Sep 11, 2006 at 10:28:49AM -0700, Vince Fuller wrote: One might also imagine that more globally-friendly way to implement this would have been to build a network (VPN would be adequate) between the ground stations and assign each plane a prefix out of a block whose subnets are only dynamically advertsed within that network/VPN. Doing that would prevent the rest of the global Internet from having to track 1000+ routing changes per prefix per day as satellite handoffs are performed. As has been said before, and is also readable in that blog entry: the system is supposed to create *one* advertisement change when the plane is crossing from the Europe to the US ground station (etc.), not 1000+. The comment still applies. Imagine that this system were implemented globally on all international/intercontinental air routes. It would still be nice to avoid having each of those airplanes cause a globally-visible routing update whenever it crosses some geographical boundary. --Vince
Re: [routing-wg]BGP Update Report
Hello; On Sep 11, 2006, at 6:32 AM, Oliver Bartels wrote: Hi Gert, On Fri, 8 Sep 2006 18:06:00 +0200, Gert Doering wrote: Ummm, well, this is a damn fast plane if it will reach another continent 1843 times per day (or even per week)... - which should be the only time the BGP announcement moves. Sounds more like the BGP-follows-plane system has some stability problems. Nack. Probably they are using low or medium earth orbit satellites, which _are_ damn fast in orbit. Otherwise the round trip time would be unacceptably high. I believe that all Connexion support is / was from geostationary satellites. As the whole thing is 3D, some of them might have contact to ground stations on this or the other side of the great lake, depending on their 3D position, even thru the plane travels on a well defined track (probably a 3D circle, too) in just one direction only. Ceterum censeo: Nevertheless this moving-clients application shows some demand for a true-location-independend IP-addresses announcement feature (provider independend roaming) in IPv6, as in v4 (even thru this isn't the standard way, but Connexion is anything but standard). Shim etc. is not sufficient ... That seems like a reasonable conclusion. Kind Regards Oliver Regards Marshall Oliver Bartels F+E + Bartels System GmbH + 85435 Erding, Germany [EMAIL PROTECTED] + http://www.bartels.de + Tel. +49-8122-9729-0
Re: [routing-wg]BGP Update Report
Hello; On Sep 11, 2006, at 1:34 PM, Vince Fuller wrote: On Mon, Sep 11, 2006 at 10:28:49AM -0700, Vince Fuller wrote: One might also imagine that more globally-friendly way to implement this would have been to build a network (VPN would be adequate) between the ground stations and assign each plane a prefix out of a block whose subnets are only dynamically advertsed within that network/VPN. Doing that would prevent the rest of the global Internet from having to track 1000 + routing changes per prefix per day as satellite handoffs are performed. As has been said before, and is also readable in that blog entry: the system is supposed to create *one* advertisement change when the plane is crossing from the Europe to the US ground station (etc.), not 1000+. The comment still applies. Imagine that this system were implemented globally on all international/intercontinental air routes. It would still be nice to avoid having each of those airplanes cause a globally-visible routing update whenever it crosses some geographical boundary. In a typical flight Europe / China I believe that there would be order 10-15 satellite transponder / ground station changes. The satellite footprints count for more that the geography. --Vince Regards Marshall
Re: [Fwd: RE: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
IP addresses appear to be property - - read http://news.findlaw.com/ hdocs/docs/cyberlaw/kremencohen72503opn.pdf. Given that domain names are property, IP addresses should be property, especially in California where are constitution states All things of value are property I'm not sure how you can say that 32 bit integers have monetary value. There are more than 4 billiion of them and anyone can use any number they choose. What is valuable is the unique registration service which provides for a set of cooperating entities to share a single 32 bit number space without collision. Also, what about ARINS hardcore attitude making it near impossible to aquire ip space, even when you justify it's use? I have had nightmares myself as well as MANY of my collegues share similar experiences. I am having an issue right now with a UNIVERSITY in Mexico tryin to get ip's from the mexican counterpart. Why is it that they involve lawyers, ask you all your customers names and etc... This is more information than I think they should be requiring. Any company that wishes to engage in business as an ISP or provider in some capacity should be granted the right to their own ip space. We cannot trust using ips swipped to us by upstreams and the like. Its just not safe to do that and you lose control. I have a great deal of difficulty identifying with this. The information ARIN requests is, in my experience, reasonable and necessary for them to accurately verify that your request is in compliance with allocation policies. If you don't provide customer names, you can claim any number of customers you want and fabricate as large an artificial network as you like with no checks or balances. Having said that, in my experience, a properly filled out template in compliance with the policies has little or no difficulty getting addresses issued by ARIN. If you don't like the policies, then, there is an open process to change them. Having participated in that process for a number of years and having worked actively to make it possible to get address space for smaller entities (2002-3, Assignments of /22, for example) and portable IPv6 assignments for end-users (Policy 2005-1), I know it is possible to change ARIN policy. However, like any form of governance, this is a slow process and requires the building of consensus. Actually, is there anyone else who shares these nightmares with me? I brought up the lawsuit with Kremen and ARIN to see if this is a common issue. What are your views, and can someone share nightmare stories? There may be people who share your nightmares, but, I suspect it would be less of a nightmare if you worked with the ARIN staff instead of railing against them. Don't get me wrong, I think there has to be SOME due dilligence, however their methodology is a bit hitlerish. This is completely opposite of my experience. There was a time when I might have agreed with you, but, ARIN has changed a lot and is a much friendlier organization today than even 5 years ago. If you have had similar problems, contact me off list or on, if you wish. I'd love to talk to you. AIM is preferred. I've had the opposite experience across a number of ARIN allocations and assignments for organizations of various sizes. Owen PGP.sig Description: This is a digitally signed message part
Re: [Fwd: RE: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
On Mon, 11 Sep 2006, Chris Jester wrote: IP addresses appear to be property - - read http://news.findlaw.com/ hdocs/docs/cyberlaw/kremencohen72503opn.pdf. Given that domain names are property, IP addresses should be property, especially in California where are constitution states All things of value are property Intrinsic or non-intrinsic value? It's an important distinction. Also, what about ARINS hardcore attitude making it near impossible to aquire ip space, even when you justify it's use? I have had nightmares myself as well as MANY of my collegues share similar experiences. I am having an issue right now with a UNIVERSITY in Mexico tryin to get ip's from the mexican counterpart. I worked for a large-ish ISP for over seven years and made multiple requests for IP space from ARIN in that time. My experience with this was not at all bad. I did not find it to be like pulling teeth to get the space. As long as the request documentation is in order, it was not too bad. I disagree with the notion that IP addresses are property. jms
Re: [routing-wg]BGP Update Report
The comment still applies. Imagine that this system were implemented globally on all international/intercontinental air routes. It would still be nice to avoid having each of those airplanes cause a globally-visible routing update whenever it crosses some geographical boundary. The problem is physics: The speed of light is about 300.000km/s in air and about 200.000km/s in fibre, which means a VPN solution causes an _additional_ 70ms delay for some additional 7000km VPN distance. If one assumes a well-engineered VPN solution that interconnects the ground stations to peering points to the rest of the Internet, then there should be no increase in delay for traffic outbound from the plane toward the Internet - traffic path will still be plane - ground station - nearest exit point to Internet. The amount of delay increase for return traffic is hard to quantify; it will depend on how well the Conxion service network/VPN is connected to its upstream providers, how well-connected those providers are to interconnect points to the rest of the Internet, whether shortest-exit routing (or some other optimized exit routing) is implemented between the various providers, etc. Many of these issues will apply to the current, dynamically-route-every- prefix model, too. In some cases, the VPN will make little or no different in delay; in some cases, it may increase one-way delay a bit. On the upside, worries about more-specific filtering and route-dampening will go away. No, VPN and NAT and PA and shim are not the solution for todays mobile communications demands. From the view point of the developer of such an intercontinental communications system todays internet technology looks outdated, the BGP re-anouncement is just a hack. Indeed, RFC1661 is dated July 1994. This is just another example for the obvious demand of a true dynamic routing system beeing capable to handle large numbers of prefixes and dynamic changes in the routing table. Other demand results from mobile networks, IPv6 PI etc. The demand _is_ there, simply saying don't use PI, do keep 200 customers rules (IPv6), don't accept small prefixes, don't permit dynamic changes, do wait for our perfect shim solution which takes short additional 10 years to develop, do purely theoretical discussions on geoadressing as the restrictive approach is not the solution. Either the Internet community will find good answers to these demands, or the markets will find solutions without the Internet community ... Ceterum Censeo: BGP_Standard_Update subito, IPv6 PI subito ... If one assumes no changes to ipv6 semantics, it is hard to envision such a solution being possible. PI routing degenerates into flat routing and building a true dynamic routing system beeing capable to handle large numbers of prefixes and dynamic changes in the routing table is difficult to impossible if one assumes a) a single number space that accomodates both routing information and endpoint-identification (which is a fundamental design assumption in ipv6 as currently specified) and b) continued super-linear growth in the number of unique subnets that are identified using that numbering space. There are smart people who have been looking at how to fix this for more than a decade (some would say that research along these lines dates back to the 1960s...see http://www.nanog.org/mtg-0606/fuller.html for a recent NANOG presentation on this topic, with pointers to earlier work); virtually all of the designs that have been offered require routing locator/endpoint-id separation. Unfortunately, those who put together the current ipv6 did not choose to follow the locator/endpoint-id separation path. For a variety of reasons, trying to retro-fit the split into ipv6 with something like shim6 is difficult and it running into a lot of resistance. --Vince
Re: [Fwd: RE: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
On 11-Sep-2006, at 13:44, Chris Jester wrote: Also, what about ARINS hardcore attitude making it near impossible to aquire ip space, even when you justify it's use? I have had nightmares myself as well as MANY of my collegues share similar experiences. I have talked to many people who have not taken the time to read the appropriate policy documents or supply adequate documentation who have had terrible difficulty getting resources assigned from all the RIRs, not just ARIN. I have never yet met anybody who has followed the procedures (and who meets the criteria within the policy) who hasn't received exactly the resources they asked for. Actually, that's not true -- I know of several people who have received more than they asked for, since the RIRs in question noticed that the original request contained sufficient justification for a larger allocation. Perhaps by ARINS [sic] hardcore attitude you mean their insistence that the policy be followed? My opinion on that is Good Work, ARIN. While my experience is mainly with APNIC and ARIN, it's not obvious to me that the other RIRs are substantially more difficult to deal with. I am having an issue right now with a UNIVERSITY in Mexico tryin to get ip's from the mexican counterpart. Why is it that they involve lawyers, ask you all your customers names and etc... You might advise the university in question to seek the help of someone who has actually read the policy documents (or to read them themselves -- the ARIN number resource policy manual, for example, is written in very straightforward language). Joe
Re: comast email issues, who else has them?
On Mon, 11 Sep 2006, william(at)elan.net wrote: On Mon, 11 Sep 2006, Tony Finch wrote: Far better to use a Received: header stating HTTP in the with protocol field. (And the IANA registry should be updated to include that as one of the standard values.) That suggestion is likely to be contrary to SMTP design. Received trace fields are for use of recording of where data that was RFC2822 formatted came from and how. Use of these fields also assumes that start of email transmission took place somewhere else. I'm not entirely convinced by that argument. You could squint a bit and view webmail as a sort of gatewaying, in which case it makes sense to map webby concepts onto 821 and 822 as accurately as possible. The other reason for using Received: for this kind of job is it scales better to other submission methods: what about an XMPP-to-email gateway, for example? It would be madness to define ad-hoc X- headers for each submission protocol. The with clause in Received is used to indicate the transport protocol but assumes that data itself is already properly formatted (compare to that the same type of L7 protocol can use either TCP or UDP; this is not perfect fit but gives you some idea). What about with MMS where the message format is not (quite) 822? If you really want to indicate the source of transmission for non-SMTP origination point, the best is to create new trace field for this purpose. With Received the closest clause would be via but I think via is largely for use with complete message being gatewayed through non-SMTP protocol and this is probably not the correct use of it either. The only non-TCP via defined at the moment is UUCP, which I guess implies batch SMTP - i.e. via is the level under the message transport protocol. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ FISHER: WEST OR NORTHWEST 4 OR 5 BECOMING VARIABLE 3 OR 4. FAIR. MODERATE OR GOOD.
RE: [Fwd: RE: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
Owen, I totally agree-- In the last 2 years I have worked with ARIN and received several assignments for end users and NONE of them were difficult for the assignment. I think the worst I saw was getting an outdated ORG ID record changed! The time from request to assignment in one case was less than 2 weeks, and the worst was 6 weeks. That one required ORG ID changes, contact changes, ASN assignment, and was interlaced with both me and the customer contact being out of town on different weeks. If you read carefully and just call the helpdesk they are there to help. NOT hinder. Sure the ORG ID change was difficult and I would have had it no other way! That protects all of us! Remember all those hijacked IP blocks? Where is William L?(sorry I can't remember your last name) Later, Jim
Re: [Fwd: RE: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
On Mon, 11 Sep 2006, Chris Jester wrote: Also, what about ARINS hardcore attitude making it near impossible to aquire ip space, even when you justify it's use? I have had nightmares myself as well as MANY of my collegues share similar experiences. I am having an issue right now with a UNIVERSITY in Mexico tryin to get ip's from the mexican counterpart. Why is it that they involve lawyers, ask you all your customers names and etc... This is more information than I think they should be requiring. Any company that wishes to engage in business as an ISP or provider in some capacity should be granted the right to their own ip space. We cannot trust using ips swipped to us by upstreams and the like. Its just not safe to do that and you lose control. Actually, is there anyone else who shares these nightmares with me? I brought up the lawsuit with Kremen and ARIN to see if this is a common issue. What are your views, and can someone share nightmare stories? Having successfully been through the ARIN application process several times, on behalf of a few different organizations, and watched others both succeed and fail, it doesn't look all that complicated. Those who qualify under the policies, have or can generate good documentation, supply complete information as requested, and respond completely to any follow-up questions, tend to get through the process fairly quickly. Those who don't qualify, or who decide that the process is going to be too difficult and attempt to fudge, it often get into trouble. Those who are successful in this business usually follow the process, because it's the path of least resistance. That's the practical answer. One of the legal questions in this case seems to be whether the policies are legal, and I suspect few of the active participants on this list have the necessary legal background to answer that. -Steve
RE: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
Joe makes a good point. Everyone is shouting no one owns IP addresses, but that is proof by assertion. Yelling louder doesnt make it so. Neither does ARINs assertions or their policies. What would establish IP addresses as some sort of ARIN-owned and licensed community property? Well, winning a court case like this, or congress passing a law. Frankly, those who want ARINs ownership of IP addresses to be established, should hope Kremens put on a good case here, to establish a nice solid precedent. Who cares about when CIDR came out? It was background information and not really material to the case. Kremens was the victim of a very nasty fraud. People are acting like hes a bad guy, when, in fact, he was a victim of one of the worst cases of domain hijacking, and his original case is one that we rely on for protection today. There is a strong argument to be made for ownership of IP addressing and subsequently trading address space as a commodity, with ARIN as a commodity exchange and clearinghouse. Is this reaction people hating lawyers more than ARIN, or what? - Daniel Golding From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe mcguckin Sent: Friday, September 08, 2006 1:37 PM To: nanog@merit.edu Subject: Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?] I read the complaint. I don't like the fact that a lot of my friends are named in the suit, but I think there are some points worth discussing within the community: 1) IP address blocks are not 'property' Domains are not property. The assignee of a domain has no ownership interest Network Solutions made this same argument years ago. That was their shield against lawsuits when negligence (or worse) on NetSols part would cause a domain to be erroneously transferred. When mistakes were made, Network Solutions was notoriously unwilling to reverse the transaction to correct the error. Then they got sued for refusing to reverse a fradulent domain transfer, and they lost. The case had the side effect of setting the precedent that domains *are* in fact tangible property. Now when a registrar or registry makes a mistake, they can be legally held responsible. (What case was that? Kremen v. Network Solutions) I would say that's an improvement. 2) Why does ARIN believe that it can ignore a court order? 3) What's wrong with treating assignments like property and setting up a market to buy and sell them? There's plenty of precedent for this: Mineral rights, mining claims, Oil and gas leases, radio spectrum. If a given commodity is truly scarce, nothing works as good as the free market in encouraging consumers to conserve and make the best use of it. Joe McGuckin ViaNet Communications [EMAIL PROTECTED] 650-207-0372 cell 650-213-1302 office 650-969-2124 fax
RE: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
Nick, You make an incorrect assumption - that IP addresses are currently free (they are not, in either money or time) and that commoditizing them will increase their cost (there is significant evidence it will not). If I have the choice between paying $500 for a /24 of PI space or going to my upstreams, getting IP space, applying to ARIN for a /22 of PI space, eventually numbering out of the PA space - how much money have I spent? - Daniel Golding -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Nicks Sent: Friday, September 08, 2006 2:19 PM To: [EMAIL PROTECTED] Cc: nanog@merit.edu Subject: Re: [Fwd: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?] The real fundamental flaw with this free-market approach to handling IP assignments is the fact that it will further create an environment where smaller (start-ups, small businesses) entities trying to acquire PI space will face insurmountable challenges (eg, financial). While I think the majority of people these days would agree that the free-market approach to economics is definitely the best, certain resources are not very applicable to be traded in a free-market environment. I myself do not like over-bureaucratic processes, and while all of us at one time or another have complained about ARIN's procedures, policies, and practices, the purpose they serve is a needed one. Best Regards, -Michael -- Michael Nicks Network Engineer KanREN e: [EMAIL PROTECTED] o: +1-785-856-9800 x221 m: +1-913-378-6516 [EMAIL PROTECTED] wrote: 3) What's wrong with treating assignments like property and setting up a market to buy and sell them? There's plenty of precedent for this: Mineral rights, mining claims, Oil and gas leases, radio spectrum. If a given commodity is truly scarce, nothing works as good as the free market in encouraging consumers to conserve and make the best use of it. I think you're dead-on there, but you forget who you're really trying to convince. It'll happen eventually but in the meantime the greybeards who were largely responsible for the Internet as we know it (and who by and large still wield significant influence if not still stewardship) will be dragged there kicking and screaming from their academic/pseudo-Marxist ideals, some of whom seem to still resent the commercialization of the Internet. It's also hard to see the faults in the system when you are insulated by your position as member of the politburo. The flip side of the coin of course is that if you let the free market reign on IP's, you may price developing countries right off the Internet which I don't think anyone sees as a desirable outcome. There's sure to be a happy middle ground that people smarter than I will figure out, and maybe it takes a silly lawsuit such as this to kick things off. Andrew Cruse
Re: comast email issues, who else has them?
On Mon, 11 Sep 2006, Tony Finch wrote: On Mon, 11 Sep 2006, william(at)elan.net wrote: On Mon, 11 Sep 2006, Tony Finch wrote: Far better to use a Received: header stating HTTP in the with protocol field. (And the IANA registry should be updated to include that as one of the standard values.) That suggestion is likely to be contrary to SMTP design. Received trace fields are for use of recording of where data that was RFC2822 formatted came from and how. Use of these fields also assumes that start of email transmission took place somewhere else. I'm not entirely convinced by that argument. You could squint a bit and view webmail as a sort of gatewaying, in which case it makes sense to map webby concepts onto 821 and 822 as accurately as possible. You need to have protocol to map it from. HTTP is not a protocol but type of transport of initial email submission data to a submission server. The other reason for using Received: for this kind of job is it scales better to other submission methods: what about an XMPP-to-email gateway, for example? It would be madness to define ad-hoc X- headers for each submission protocol. I never said about defining X- fields for each protocol (although it does appear to be the way things are being done right now). I said that there is a need for submission trace field to identify source of submission no matter how initial submission of data was done. As far as XMPP if you can define proper mapping from and to SMTP then you likely can start using with clause in Received for when first SMTP email server is talking about message that came from XMPP. The with clause in Received is used to indicate the transport protocol but assumes that data itself is already properly formatted (compare to that the same type of L7 protocol can use either TCP or UDP; this is not perfect fit but gives you some idea). What about with MMS where the message format is not (quite) 822? They defined proper mapping in RFC4356. Personally I think mapped protocols should use via clause but it appears the way things are currently being done is that when mapping exist then with can be used. If you do not have mapping and just using protocol for direct transfer of data then with is only appropriate if entire data was already in appropriate RFC2822 form. If you really want to indicate the source of transmission for non-SMTP origination point, the best is to create new trace field for this purpose. With Received the closest clause would be via but I think via is largely for use with complete message being gatewayed through non-SMTP protocol and this is probably not the correct use of it either. The only non-TCP via defined at the moment is UUCP, which I guess implies batch SMTP - i.e. via is the level under the message transport protocol. I think that via is probably for use with a transport-level protocol independent of internet, i.e. gateway to/from non-internet world. That is why I think that via would have been better for use with MMS. In any case I've yet to see any convincing argument that with HTTP as couple places are doing is appropriate nor is via HTTP likely any better. P.S. I've distinct feeling there 1% on this list who care about such details of SMTP as we discussed and are interested in discussing it (the person who raised the issue originally probably only meant that he wants to see ip address of the user creating webmail message and does not care how that information is carried as long as all are doing it). For protocol details, perhaps it would be better if this discussion were to move to [EMAIL PROTECTED] -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: comast email issues, who else has them?
william(at)elan.net wrote: You need to have protocol to map it from. HTTP is not a protocol but ^ type of transport of initial email submission data to a submission server. Really?! -- Requiescas in pace o email Ex turpi causa non oritur actio http://members.cox.net/larrysheldon/
Re: comast email issues, who else has them?
On Mon, 11 Sep 2006, Laurence F. Sheldon, Jr. wrote: william(at)elan.net wrote: You need to have protocol to map it from. HTTP is not a protocol but type of transport of initial email submission data to a submission server. Really?! Yes. Since we're talking text messaging protocols (i.e. email or alike). HTTP when used with webmail a transport protocol, but not messaging protocol as it does not define anything like From or To fields. -- William Leibzon Elan Networks [EMAIL PROTECTED]
proposed NANOG charter amendments
[this message has been cross-posted to nanog@ and nanog-futures@, with followups set accordingly, as we used to say back when Usenet was read by humans. If you're interested in discussing any of this, and you're not on nanog-futures@ already, see http://www.nanog.org/ email.html] ** If you're not interested in the continuing organisational aspects of NANOG, hit delete now. Zero operational content follows. ** There are several proposed charter amendments up for vote in St Louis. You'll see a summary of them here: http://www.nanog.org/charter/ There's one change pending to that summary, which is to break out the three options in proposal 2006-03 so that they can each be voted on separately (they're mutually exclusive, so you should only be able to to vote for one of them). If you have opinions on any of the proposals, now would be a good time to voice them on the nanog-futures@ list. Agents are standing by. Joe (for the steering committee)
Global Crossing issues?
Is anyone seeing any problems when their traffic is hitting Global Crossing in the Midwest? I have equipment at several different carrier-neutral POPs, and any traffic going through gblx.net is having horrible latency or getting dropped entirely. Thanks,-brandon-- Brandon GalbraithEmail: [EMAIL PROTECTED]AIM: brandong00Voice: 630.400.6992A true pirate starts drinking before the sun hits the yard-arm. Ya. --thelost
Re: Global Crossing issues?
I ride them out of IN and haven't had any issues today. We have voice going over it and even the smallest blip is noticed. tv - Original Message - From: Brandon Galbraith To: [EMAIL PROTECTED] Sent: Monday, September 11, 2006 5:28 PM Subject: Global Crossing issues? Is anyone seeing any problems when their traffic is hitting Global Crossing in the Midwest? I have equipment at several different carrier-neutral POPs, and any traffic going through gblx.net is having horrible latency or getting dropped entirely. Thanks,-brandon-- Brandon GalbraithEmail: [EMAIL PROTECTED]AIM: brandong00Voice: 630.400.6992"A true pirate starts drinking before the sun hits the yard-arm. Ya. --thelost"
Re: proposed NANOG charter amendments
On Mon, 11 Sep 2006, Joe Abley wrote: There are several proposed charter amendments up for vote in St Louis. You'll see a summary of them here: http://www.nanog.org/charter/ There's one change pending to that summary, which is to break out the three options in proposal 2006-03 so that they can each be voted on separately (they're mutually exclusive, so you should only be able to to vote for one of them). If you have opinions on any of the proposals, now would be a good time to voice them on the nanog-futures@ list. Agents are standing by. A few comments: 6.4 Elections: The word NANOG in the first line is in the wrong place. 48 hours seems awfully short as a voting period. The previous election was an entire week. 7.1.2 Mailing List Administration: It might be better to spell out Mailing List, rather than abbreviating it ML. Also, while amending it, would it make sense to pluralize list, to allow for the formation of other lists in the future? There's a consistency issue with the Mailing List Committee appointment process versus the Program Committee appointment process. The amendments as written have the Mailing List Committee appointed at the start of the fall meeting, by the outgoing Steering Committee right before the election. The Program Committee amendment has the Program Committee appointed by the incoming Steering Committee. Is this intentional? 6.4.4 Dual Program Committee/Steering Committee Membership Prohibited: Remove the s from the word Resigns. -Steve
Re: [Fwd: RE: Kremen VS Arin Antitrust Lawsuit - Anyone have feedback?]
On Mon, 11 Sep 2006, Chris Jester wrote: Also, what about ARINS hardcore attitude making it near impossible to aquire ip space, even when you justify it's use? I have had nightmares myself as well as MANY of my collegues share similar experiences. I am having an issue right now with a UNIVERSITY in Mexico tryin to get ip's from the mexican counterpart. Why is it that they involve lawyers, ask you all your customers names and etc... This is more information than I think they should be requiring. Any company that wishes to engage in business as an ISP or provider in some capacity should be granted the right to their own ip space. We cannot trust using ips swipped to us by upstreams and the like. Its just not safe to do that and you lose control. Actually, is there anyone else who shares these nightmares with me? I brought up the lawsuit with Kremen and ARIN to see if this is a common issue. What are your views, and can someone share nightmare stories? When I went after my own /21 after headaches with the numbers from my upstreams, UUNET and SBC, I sought help from a consultant (inexpensive, I might add) to let me know *exactly* what I needed to provide to ARIN to justify a private allocation. Unlike the original poster's claim, I didn't have to open the kimono wide. ARIN looked at my existing utilization, my basic numbering plan, my then-existing map of domain names to IP addresses, my application for one ASN, and after one back-and-forth they said yes. Today I'm a very happy multi-homed camper.
