Hi Hadmut, On Sat, 19 Jun 2004 11:42:23 +0200 Hadmut Danisch <hadmut@xxxxxxxxxx> wrote: > Hi, > > at least here in Germany Internet providers tend to > do and not to do what they want. > > - Some cut off their clients every 24 hours (DSL) > > - Some block or slowdown particular tcp ports > to get rid of peer-to-peer file sharing > > - Some redirect the first web access to any site > to their own to force you to read their ads > > - Very few support multicast. When I asked my > own provider, they didn't even know what this is. > (They said 'no, because they don't support Linux'.) > > - IPv6? Huh? What's that? > > - At least one large provider blocks port 25 to certain IP > addresses in order to force you to use the provider's > mail relay and have the sender e-mail address replaced > by the customers default address at the provider's domain. > They say it's against spam, but I guess it's because they > take money for opening the port and allowing to use > SMTP and such any sender domain. > > - ... > > > So it would be good to have some kind of > standard or definition, what exactly an > internet provider has to do and what to refrain > from. > I tend to come up with the answer to your question the following way : (Q) What is the "Internet" ? (A) A global network that runs the "Internet Protocols", and follows the Internet architecture. (Q) What is the Internet architecture ? (A) It is described in RFC1958 - "Architectural Principles of the Internet" (http://www.faqs.org/rfcs/rfc1958.html). (Q) What does an Internet Service Provider do ? (A) Provides access to the "Internet". (Q) What if the "Internet Service Provider" doesn't provide access to the Internet in a way that follows RFC1958 ? (A) They aren't providing access to the Internet, so I think they shouldn't be calling themselves an "Internet" service provider. A number of things you describe, such as blocking port 25, redirecting URLs etc. do not follow RFC1958. I don't consider those organisations to be true ISPs, and I don't give them my "Internet" access business, as they don't seem to be prepared to properly provide it. Regards, Mark. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf