I hate jumping into such a contentious issue, but the very fact that it is contentious, and that it will potentially impact both my employer, Teleglobe, and its customers, I have an obligation to point out several technical issues. I'll start with some recent threads:
But surely www.big-importantco.com would have their own machine and wouldn't share with www.my-little-home-page.org ?
The issue with non-IP based virtuals, is the difficulty and complexity, and more important, time-sensitivity involved, in *relocating* between servers. DNS-based virtuals are impacted by caching resolvers, which are ubiquitous. Lowering timers has risk too, especially if load spikes occur, eg for longer than timer values. If everyone is aware of the "slashdot" effect, then you can appreciate wanting to move such a "slashdotted" site to a separate server (or server farm), in a timeframe less than the DNS normal-TTL-value times. Not doing so would have a serious negative impact on 100 little-domains, who may have SLA's with you. Replace "slashdot" with "IPO" or "new software release", or any of a dozen other usage-spike events; each customer has their own traffic trigger, and the ISP won't necessarily have adequate warning. Three days is way too long; even three hours can result in bad press, angry customers, and cancelled contracts.
Nurani Nimpuno writes:
We would therefore like to request the community to consider making it mandatory for NEW installations to use domain based web-hosting, with the exception of a set of agreed applications needing IP based web-hosting (eg. SSL).
I think there are a number of issues concerning the definition of "NEW". Perhaps the only one to which most will agree is a square-one startup, with no pre-existing hardware, software, or address space. New address space, new servers, or even a new upstream, resulting in a mandatory upgrade places undue burden on any affected company, not the least of which is management systems for a new hosting system. And even there, there is another issue - the digital divide, the technical haves and have-nots. The first and third world. While there may not be as many RIPE members with customers in that category, the fact that *any* do means the policy must, IMHO, be sensitive to such issues. (Any RIPE members with offices in certain countries, eg USA, may be under legal obligation to do so, even if their head office, and/or customer, are not in said country.) There are many parts of the world, which would include parts of Europe which were formerly Iron Curtain countries, where the general expertese, available hardware and software, and language barriers, combined with newly-established free-market economies, put high demand for technology in the hands of the technical newbies, who are soooo far back on the learning curve that there is zero chance of them being proficient enough to deploy and configure DNS-based virtual domains as their first hosting service in a correct, or timely, fashion. I believe, that while it is admirable to encourage, strongly, those who can, to do DNS-based IP, that sufficient arguments in several areas run counter to mandatory policies for this technology. The vast majority of RIPE members are, I believe, commercial entities. Any policy which makes it necessary to turn away customers, would send the wrong message to the market in general. We all benefit from fair and open competition. If we permit "grandfathering" of IP-based virtuals, then to not permit new applicants to do so is ever-so-slightly unfair. ISPs need address space; this is a commercial issue for them. While we may hold ignorance and incompetence in contempt, (and I do, personally), I don't believe it is sufficient justification for the commercial impact of denying IP address space which is otherwise justified (via IP-based virtual hosting.) My two cents worth. -- Brian Dickson, Email: briand@teleglobe.net Director, Backbone Engineering Tel : +1 703 755 2056 Teleglobe Communications Corp., Fax : +1 703 755 2648 Rm 3214, 11480 Commerce Park Drive, Cell : +1 703 851 9053 Reston, Virginia, USA, 20191 http://www.teleglobe.com