Again we run into the thorny old policy issue of viewing the user as merely a captive consumer. But what happens when it turns out that to consume you need to run an application not "supported" by the intervening network? This is clearly a break of the principle of end to end application transparency that the IP layer provides. This does necessarily break the semantic description of Internet Service Provider. But there is little to be done arguing that point now. The problem as a travelling user (or as a housebound German it seems) is you don't know what you are going to be able to do until you try and as a hotel or end node provider you may legally have an obligation to try to protect your network from being a source of abuse by transients. A traveller cannot change ISP easily so either will just have to accept some things cannot be done or will find a way. As it happens one can preplan and setup a proxy service or a tunnel broker etc that can get round many of these issues. Perhaps the IETF would be wiser to give a warning about the futility of trying to break application transparency. "The Internet user may always find a way to communicate on their own terms" Christian Christian de Larrinaga -----Original Message----- From: ietf-bounces@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx]On Behalf Of Ole Jacobsen Sent: 20 June 2004 23:52 To: Hadmut Danisch Cc: ietf@xxxxxxxx Subject: Re: What exactly is an internet (service) provider? If by "IPSec" you mean what the marketing folks call VPN, then so far it has worked just fine. Muticast, VOIP and the rest of stuff you mention probably does NOT work, but my point was that this is NOT what most business travellers want. And, yes, I agree they should provide a matrix of what is available for what cost. Ole Ole J. Jacobsen Editor and Publisher, The Internet Protocol Journal Academic Research and Technology Initiatives, Cisco Systems Tel: +1 408-527-8972 GSM: +1 415-370-4628 E-mail: ole@xxxxxxxxx URL: http://www.cisco.com/ipj On Mon, 21 Jun 2004, Hadmut Danisch wrote: > On Sun, Jun 20, 2004 at 02:23:51PM -0700, Ole Jacobsen wrote: > > > > We can certainly have an argument about what is a reasonable price, but if > > I can do *exactly* the same things (read/send e-mail, browse the web, > > transfer files, make connections to remote hosts via SSH, listen to BBC > > Radio 4, etc.) as I can from inside the corporate network, then what > > > - How would you do a Voice-over-IP phone call with someone > else if both of you are in such a NAT-hotel-room? > > - How do you join a multicast session (actually this is not > a matter of NAT, but of different levels of Internet services). > > - I and some friends use a UDP based protocol to exchange > status messages with a central server. The next version > will allow to send notifications if mail has arrived > to avoid polling continuously. How would you do that? > > (I'm sometimes using IP over GRPS with my cellphone, where > I receive a RFC1918 address, which is NATed. When I am awaiting > an important e-mail, I have to poll every few minutes. Polling > over GPRS is expensive. The provider which seems to be the cheaper > could turn out to be more expensive.) > > - How would you do IP-address based authorization > (e.g. RMX/SPF/CallerID) if other people can have the > same IP address at the same time? > > - IPSec through NAT (if not UDP-encapsulated)? > > - What about UDP or TCP protocols which run into the > NAT timeout? > > - What about forensics? How do you track back an attack from > behind a hotel's NAT router? > > > I don't say that all hotels have to support full internet. > But I'd like to know what I pay for in advance and decide > whether it is sufficient for my needs before purchasing. > > I've never seen hotel staff people who could explain what's > going on there. But if you give things a name, then they > can simple tell you what they offer without the need to > understand anything. They just need to learn > "We offer XXX service for x$ and YYY for y$". > > And with home internet providers you can compare whether > the one for US$n-2 is really cheaper than the one with US$n. > > > > regards > Hadmut > _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf