Re: What exactly is an internet (service) provider?
* Hadmut Danisch: 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) This happens on the sub-IP layer and hasn't got to do much with ISPs. - Some block or slowdown particular tcp ports to get rid of peer-to-peer file sharing You get what you pay for. - Some redirect the first web access to any site to their own to force you to read their ads Same here. - 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'.) You can't get reliable multicast service anywhere in the world. People tend to switch it off if it threatens to impact unicast traffic. It's not possible to run production services over multicast across the Internet at the moment, at least not without a fallback to unicast. - IPv6? Huh? What's that? It's not a real problem to get native IPv6 over ADSL or SDSL. - At least one large provider blocks port 25 to certain IP addresses in order to force you to use the provider's mail relay Which one is that? The case you are writing about does *not* block 25/TCP on the TCP/IP layer. It's true that certain extremely cheap products don't offer that much Internet or Service. These products are marketed aggressively and are usually sold at a loss. Nobody forces you to buy them. -- Current mail filters: many dial-up/DSL/cable modem hosts, and the following domains: bigpond.com, di-ve.com, fuorissimo.com, hotmail.com, jumpy.it, libero.it, netscape.net, postino.it, simplesnet.pt, spymac.com, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr, yahoo.com. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: What exactly is an internet (service) provider?
* Hadmut Danisch: That's currently a consequence of the shortage of IP addresses. There's no shortage of IPv4 addresses. Today, it's not a problem to get IP addresses if you have determined that NAT is not an option. -- Current mail filters: many dial-up/DSL/cable modem hosts, and the following domains: bigpond.com, di-ve.com, fuorissimo.com, hotmail.com, jumpy.it, libero.it, netscape.net, postino.it, simplesnet.pt, spymac.com, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr, yahoo.com. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: What exactly is an internet (service) provider?
On Sun, 20 Jun 2004 15:51:47 -0700 (PDT) Ole Jacobsen [EMAIL PROTECTED] wrote: 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. A retorical question. How do business travellers know that they don't want them, if they've never seen them demonstrated, because NAT limited the availablility of them to the point where their availability couldn't be relied upon. Not only may the next killer app not be the next killer app because it doesn't work with NAT, the next killer app may have already been invented a year ago, but wasn't able to be deployed because of the prevalance of NAT. Not only don't we know, we also don't know what we may be missing. This is the problem with NAT - it appears to be a nice easy solution, until you realise that the devil is in the details. Keith Moore has put together a good list of the things NAT breaks at http://www.cs.utk.edu/~moore/what-nats-break.html a related document, also by Keith, which also addresses some issues influenced by NAT is Dubious Assumptions about IPv6 http://www.cs.utk.edu/~moore/opinions/ipv6/dubious-assumptions.html Regards, Mark. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: What exactly is an internet (service) provider?
On Mon, Jun 21, 2004 at 09:21:44AM +0200, Florian Weimer wrote: ... This happens on the sub-IP layer and hasn't got to do much with ISPs. ... You get what you pay for. ... Same here. ... You can't get reliable multicast service anywhere in the world. ... It's not a real problem to get native IPv6 over ADSL or SDSL. ... Which one is that? The case you are writing about does *not* block 25/TCP on the TCP/IP layer. It's true that certain extremely cheap products don't offer that much Internet or Service. These products are marketed aggressively and are usually sold at a loss. Nobody forces you to buy them. You missed the point. This is not about complaining that I don't get enough for the money. This is that I don't know in advance what I do get for my money. Nobody forces you to buy them is true only as long as I do know what exactly they offer and as it is my decision to buy it or not. But if I buy Internet and don't see what I'm buying, then I don't have the choice. I do not want to blame anyone for selling NAT access. I want him to give a clear statement about what he is selling. regards Hadmut (And, btw, some of the statements are incorrect. - Some providers intentionally cut their customers off after 24 hours in order to force them to have a new IP address. - It is a real problem to get native IPv6 over DSL in Germany. Some providers simply don't want to provide IPv6, because they say Internet is IPv4. ) ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: What exactly is an internet (service) provider?
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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Ole Jacobsen Sent: 20 June 2004 23:52 To: Hadmut Danisch Cc: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] 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 mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: What exactly is an internet (service) provider?
On 20-jun-04, at 23:23, Ole Jacobsen wrote: But it's substandard service nonetheless. Huh? 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 exactly makes this NAT service substandard?? I'm not sure what you can and cannot do on your corporate network, but for me NAT gets in the way of some forms of streaming video (RTSP protocol), audio/video conferencing (SIP) and IPsec. It's a real shame that software companies are spending their money on getting around this rather than create real innovation. I am not advocating the use of NATs, I am just observing that NATs are a fact of life and I have a hard time accepting that such a service cannot be defined as Internet service. You can define it as partially broken internet service. I don't think the IETF should be in the business of defining what constitues Internet service based on religion rather than reality. And I don't think the IETF should do anything that even comes close to endorsing NAT. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: What exactly is an internet (service) provider?
Mark Smith wrote: Not only may the next killer app not be the next killer app because it doesn't work with NAT, the next killer app may have already been invented a year ago, but wasn't able to be deployed because of the prevalance of NAT. Not only don't we know, we also don't know what we may be missing. The next killer app a lot more important than Web for most business people is the Internet telephony, which may or may not use IETF standard protocol. Even though there are people who can not type, most of them can use telephony (maybe over TDD). And the second next killer app a lot more important than Web for most people including, but not limited to, business ones is Internet TV, which may or may not use IETF or Microsoft standard protocol. It has already happened to millions of people in Japan initiated by a commercial company and there will be tens and hundreds of millions of people using them. This is the problem with NAT - it appears to be a nice easy solution, until you realise that the devil is in the details. Yup. If you insist on NAT, you lose a lot of business chances. I can proudly say that I helped the commercial company above get global IPv4 addresses enough for millions of subscribers, which was essential for their aggressive service. The reality of life is that there are successful ISPs and there are poor network providers insisting on NAT. Masataka Ohta ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: What exactly is an internet (service) provider?
On Mon, 21 Jun 2004 10:03:46 +0100 Christian de Larrinaga [EMAIL PROTECTED] wrote: snip 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 ... using the following tunnel broker / VPN peer. The neat thing about it is that it uses SSL/TLS over UDP, and you can specify the UDP ports to use. As it uses UDP to encapsulate the IP packets, the outer IP header can be NATted. Also, as it uses UDP, and the ports are selectable, you may be able to punch a pipe through a firewall, by using UDP ports #53 a.k.a. DNS, depending on how well the firewall inspects DNS traffic. If that works out, The Internet user may always find a way to communicate on their own terms, irrespective of NAT. http://openvpn.sourceforge.net/ Regards, Mark. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Response to complaint from Dean Anderson (fwd)
[EMAIL PROTECTED] (Stephen Sprunk) writes: ... Dean's problem is that he sends mail from an open relay, which isc.org's servers block completely ... actually i think the reason dv8's ip address listed on SORBS is due to reported irregularities in the trust deed for that address block, rather than due to reported open relay activities. maybe dv8 will eventually sue somebody, so that a court can sort it all out and all the facts can be objectively and publically known. a note for harald and the others-- i've been lawsuit-threated by experts, and i can tell you from that experience, dv8 appears to not be an expert. -- Paul Vixie ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: What exactly is an internet (service) provider?
Ive been watching this thread for some time, and its time for me to pipe in... I've been working on a viable hotel solution for some time now, and the best I have been able to come up with is a terminal server with thin clients (bootp, tftp, xdmcp... you know the drill) in the guest rooms. The clients are NATed, due to cost of address allocation. They work fine in this scenario, for the standard business traveler, as well as providing universal access for everyone who does not carry a laptop. For someone who wants more and has their own hardware, the terminal server also routes v6 packets, providing end to end connectivity. Regarding the ISP filtering issue, I had to figuratively kick my local cable provider in the head to get them to drop the port 80 block on my circuit, and they list all of their non-business class IP's with a RBL in order to force usage of their mail relays. Its a sad situation. Scott On Mon, 21 Jun 2004, Florian Weimer wrote: * Hadmut Danisch: 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) This happens on the sub-IP layer and hasn't got to do much with ISPs. - Some block or slowdown particular tcp ports to get rid of peer-to-peer file sharing You get what you pay for. - Some redirect the first web access to any site to their own to force you to read their ads Same here. - 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'.) You can't get reliable multicast service anywhere in the world. People tend to switch it off if it threatens to impact unicast traffic. It's not possible to run production services over multicast across the Internet at the moment, at least not without a fallback to unicast. - IPv6? Huh? What's that? It's not a real problem to get native IPv6 over ADSL or SDSL. - At least one large provider blocks port 25 to certain IP addresses in order to force you to use the provider's mail relay Which one is that? The case you are writing about does *not* block 25/TCP on the TCP/IP layer. It's true that certain extremely cheap products don't offer that much Internet or Service. These products are marketed aggressively and are usually sold at a loss. Nobody forces you to buy them. -- Current mail filters: many dial-up/DSL/cable modem hosts, and the following domains: bigpond.com, di-ve.com, fuorissimo.com, hotmail.com, jumpy.it, libero.it, netscape.net, postino.it, simplesnet.pt, spymac.com, tiscali.co.uk, tiscali.cz, tiscali.it, voila.fr, yahoo.com. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf sleekfreak pirate broadcast http://sleekfreak.ath.cx:81/ ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: What exactly is an internet (service) provider?
On Mon, 2004-06-21 at 14:39, Mark Smith wrote: On Mon, 21 Jun 2004 10:03:46 +0100 Christian de Larrinaga [EMAIL PROTECTED] wrote: snip 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 ... using the following tunnel broker / VPN peer. The neat thing about it is that it uses SSL/TLS over UDP, and you can specify the UDP ports to use. As it uses UDP to encapsulate the IP packets, the outer IP header can be NATted. Also, as it uses UDP, and the ports are selectable, you may be able to punch a pipe through a firewall, by using UDP ports #53 a.k.a. DNS, depending on how well the firewall inspects DNS traffic. If that works out, The Internet user may always find a way to communicate on their own terms, irrespective of NAT. You are forgetting something very big here: Only the smart internet users will find a way out. Normal users, the masses, the ones that bring in the cash, don't know this. The smart ones will pick a real ISP anyways. The others bring in enough cash that even though there are only a few doing the tunneling thing the ISP doing this really doesn't care about those. This are all just normal 'business cases' the same like saying there are not enough IP addresses thus you get only one etc. IETF can't do much about it, except making protocols that can't be NATted and that are of the 'http' or 'p2p' rating, aka something that all the users want but which can't work behind a NAT... enter IPv6 ;) Also the above requires on to tunnel thus you are getting real service from somebody else and basically using your current provider as the l2 provider. The same is the issue with IPv6 Tunnel Brokers which can be seen as ISP's in the fact that they provide IPv6 connectivity. Though the 'l2 medium' is the IPv4 connectivity of another ISP instead of ethernet or cable. Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
RE: What exactly is an internet (service) provider?
Yes, with tunnel brokering and the ability to reverse-tunnel Roaming 'Internet users should be able find a way to communicate on their own terms', as they move in a Mobile Environment switching back-end networks if required, for Mobile VPN. Kudos to Cisco's Mobile Access Router 3200 for being an example for this architecture. Yes, I had the pleasure of piggyback riding a WiFi network setup by a neighbor while in a hotelroom in a remote, forsaken place and in the words of Ole, 'as a consumer of paid-for Internet service (that works)', there was no reason for me to care and probably these rules set for user terms will need to be integrated for policy to switch to another network if I really have to pay. Somebody is paying, but there really ain't no free lunch! Regards, Harsh Verma Director, RD, GLOCOL, Inc Past Vice-Chair (Industry) RD WG, NECCC Member, Cross Boundary WG Tel: +1(916)684-3262 E-Mail: [EMAIL PROTECTED] www.glocol.net -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mark Smith Sent: Monday, June 21, 2004 5:39 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: What exactly is an internet (service) provider? On Mon, 21 Jun 2004 10:03:46 +0100 Christian de Larrinaga [EMAIL PROTECTED] wrote: snip 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 ... using the following tunnel broker / VPN peer. The neat thing about it is that it uses SSL/TLS over UDP, and you can specify the UDP ports to use. As it uses UDP to encapsulate the IP packets, the outer IP header can be NATted. Also, as it uses UDP, and the ports are selectable, you may be able to punch a pipe through a firewall, by using UDP ports #53 a.k.a. DNS, depending on how well the firewall inspects DNS traffic. If that works out, The Internet user may always find a way to communicate on their own terms, irrespective of NAT. http://openvpn.sourceforge.net/ Regards, Mark. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
solution -- Re: Response to complaint from Dean Anderson (fwd)
The solution to this self-limitation problem [1], if the Internet MUST be the only communication path used by someone, is to use IETF web forms that go directly to the server. Anyone can access the web forms and submit their communication to the relevant persons/WGs. If the site is down, try later. Cheers, Ed Gerck [1] If someone wants to only use email for communication, this means that email will be his single point of failure in communication. Even if it's an ietf.org email. And, one may ask, what's wrong with using a postal address if email fails? After all, IETF IDs and RFCs include the postal addresses of authors. And some also have phone, fax, pager, IRC, IM, etc., available. Insisting on using only one communication path is un-Internet. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: What exactly is an internet (service) provider?
From: Markus Stumpf You have a contract. This should be listed in the contract and you can read it before signing it. If the contract doesn't talk about limits and they do limit you, sue them. Sue on what grounds? Who says that Internet service has no limits? All reputable service providers have terms of service that include limits, starting with something about network abuse. (Never mind how well those limits are enforced.) Many service providers limit their users to not running servers, but good luck finding someone who knows what they mean by server. Since there are always providers, you can't sue simply because you bought an account with limits you failed to clarify. Trying to find first line technical support people (never mind sales) at a consumer grade ISP who knows has any idea what sort of filtering their employer does is hopeless. It's generally foolish to expect to find someone who even understands the question. (And, btw, some of the statements are incorrect. - Some providers intentionally cut their customers off after 24 hours in order to force them to have a new IP address. (Some DSL modems including the Actiontec 1524 kill TCP connections after an hour or two all by themselves) You have to look at what they sell. They sell DSL Surf Accounts. Surfers usually aren't online for 24 hours without interuption and they don't have problems with the interupt in normal use. If you get a business access you will not have the problem in most of the cases. I've not seen anyone selling DSL Surf Accounts, but I've never looked, and certainly not in Germany. In any case, - which of the classes in http://www.ietf.org/internet-drafts/draft-klensin-ip-service-terms-02.txt is closest to a DSL Surf Accounts? - Should one of those four categories be renamed DSL Surf Accounts? - Should a new class named be DSL Surf Accounts be added? - exactly what filtering is imposed on a DSL Surf Account? Is port 25 filtered? 22? 135 and 138? Some or all UDP? ICMP? - and the same questions for business access. Telling people to read contracts ISP today is disingenuous. If the IETF would define DSL Surf Accounts and business access, then you could hope to ask for one or the other. You might then sue if you didn't get whichever you wanted. Vernon Schryver[EMAIL PROTECTED] ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: What exactly is an internet (service) provider?
Jeroen Massar You are forgetting something very big here: Only the smart internet users will find a way out. The argument that the smart users can use IP over HTTP makes John's classifications such as web providers unnecessary. Also the above requires on to tunnel thus you are getting real service from somebody else and basically using your current provider as the l2 provider. There are a lot of Hotels claiming Internet capable only because their rooms have extra RJ-11. At Geneva, Internet capable hotel rooms have RJ-45, not for Ethernet but for ISDN. :-| IETF can not stop them claiming Internet capable. So, let's call all the telephone companies ISPs. Smart users can, just like having VPN servers, have modems at home to establish dial-up connection to the Internet from any PSTN telephone in the world. Masataka Ohta ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Additional complaint about disparagement by Paul Vixie on IETF lists
Harald, Please add __Another__ complaint to the chair about inappropriate behavior by Mr. Vixie. Altering our name from Av8 Internet to dv8 is simply more disparagement and though we've all come to expect such 3rd grade, infantile behavior from Mr. Vixie, it is still inappropriate. The Chair's failure to chastise the many examples of this behavior by Mr. Vixie seems to indicate that the Chair has no interest in upholding the principles of the ISOC or the IETF, and the IETF Mission. If that is the case, then perhaps the Chair should resign, so the Chairmanship can be filled by someone who is interested in doing these things. Dean Anderson Av8 Internet, Inc -- Forwarded message -- Date: 19 Jun 2004 03:35:49 + From: Paul Vixie [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Response to complaint from Dean Anderson (fwd) [EMAIL PROTECTED] (Stephen Sprunk) writes: ... Dean's problem is that he sends mail from an open relay, which isc.org's servers block completely ... actually i think the reason dv8's ip address listed on SORBS is due to reported irregularities in the trust deed for that address block, rather than due to reported open relay activities. maybe dv8 will eventually sue somebody, so that a court can sort it all out and all the facts can be objectively and publically known. a note for harald and the others-- i've been lawsuit-threated by experts, and i can tell you from that experience, dv8 appears to not be an expert. -- Paul Vixie ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: Response to complaint from Dean Anderson (fwd)
While there have been reported irregularities, the person making the report (Alan Brown) is a court-proven liar, and has done this sort of thing in the past. An examination of the records shows no irregularities, and the entities assigned still exist. All the facts are already publicly known. The claim of being hijacked/disused is false. It is also publicly known that Mr. Brown, Mr. Sullivan, and Mr. Vixie have blacklisted companies that aren't spammers in the past. Both Mr. Brown and Mr. Vixie have been forced to retract those false claims by lawsuits, and have risked or actually lost significant amounts of personal assets in damages. Mr. Vixie's obvious malice for Av8 Internet is plain to see, as is his association with SORBS, Brown, Sullivan, and other disreputable characters. Av8 has been through the legal mill and hired lawyers on the subject, but that does not make it an expert on lawsuits. If Av8 were expert on lawsuits, we'd be able to practice law ourselves instead of hiring lawyers. Av8 is a expert on Open Relay operations, and on providing internet services to customers. However, it is unclear what Mr. Vixie's expertise is actually in, other than name-calling, and making disparaging alterations on another companies trademarks. I have seen little else. I suppose Vixie is also an expert at making false claims and using blacklists to block companies that aren't spammers. Dean Anderson Av8 Internet, Inc On 19 Jun 2004, Paul Vixie wrote: [EMAIL PROTECTED] (Stephen Sprunk) writes: ... Dean's problem is that he sends mail from an open relay, which isc.org's servers block completely ... actually i think the reason dv8's ip address listed on SORBS is due to reported irregularities in the trust deed for that address block, rather than due to reported open relay activities. maybe dv8 will eventually sue somebody, so that a court can sort it all out and all the facts can be objectively and publically known. a note for harald and the others-- i've been lawsuit-threated by experts, and i can tell you from that experience, dv8 appears to not be an expert. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: What exactly is an internet (service) provider?
--On Tuesday, 22 June, 2004 07:15 +0900 Masataka Ohta [EMAIL PROTECTED] wrote: Jeroen Massar You are forgetting something very big here: Only the smart internet users will find a way out. The argument that the smart users can use IP over HTTP makes John's classifications such as web providers unnecessary. Also the above requires on to tunnel thus you are getting real service from somebody else and basically using your current provider as the l2 provider. There are a lot of Hotels claiming Internet capable only because their rooms have extra RJ-11. At Geneva, Internet capable hotel rooms have RJ-45, not for Ethernet but for ISDN. :-| IETF can not stop them claiming Internet capable. No, IETF can't. But IETF can create definitions that help those who want to be truthful about what they are providing do that, in a way that is clear to themselves and their potential customers. Such definitions may also help folks with those RJ11 or ISDN connections understand why their customers get frustrated and threaten to never return -- today, they are mostly just bewildered. If, with or without those definitions, someone is determined to lie, they will certainly do that and IETF won't be able to do a thing about it. Perhaps local regulators and courts and hotel-rating agencies will, but not IETF. Let me give a specific example that leads me to believe there is hope in at least some portions of this problem. These days, before making a hotel reservation, I routinely check on whether they offer Internet access. As others have suggested, I don't bother asking about NATs, funny filters, etc. -- the odds that someone at the reservations desk will have a clue are about zero. But I do ask and, if I get a no answer, I'm reasonably likely to try to pick a different hotel (usually a much more competitive market than the range of options I have in my neighborhood for lowest price acceptable service, partially because I impose fewer requirements). Now I've gotten to hotels after getting a yes answer and had the same experiences that Ohta-san obviously has: I ask about Internet and am eventually pointed to an RJ11 jack or, worse, an RJ45 jack that might be ISDN and might be no longer hooked up and about which no one can answer questions about charging. Or, as happened a month ago, I find WiFi in the lobby but a beacon connected to... nothing. Seems the hotel took their wired Ethernet to the rooms out a month previously, hasn't gotten the 802.11 hooked up to a router yet, and didn't intend to start figuring what to do with the rooms until they figured out how much capacity the 802.11 has and how far it would reach. I tend to find these situations annoying, just as I find getting to a hotel that advertises Internet in every room and discovering that they mean a WebTV clone and nothing else, not even a spare RJ11 jack. I complain. I write letters. I collect selections of groveling apologies, especially from hotels that are members of chains in which I stay fairly often. But I also get a certain amount of astonishment from folks who were clearly clueless and don't quite understand why I'm upset. The I-D was driven partially by a desire to go to them and say ok, hotel manager, there are these categories, and they are pretty generally understood. Take the list to your supplier, find out what they are providing you, and then tell the truth when someone asks. If you are providing WebTV-clone-only access, and you tell someone that, and they say 'sorry, I'll find somewhere else to stay', then you have a basis for thinking about some business decisions. That is the best I know how to do, but I think it would be a step forward. And, that said, Ohta-san's note and the above suggests that there are at least two, maybe three, categories missing from the I-D because it sort of assumes a broadband connection or better, e.g., * We provide a really nice telephone line, but you are on your own for modems, adapters, and ISPs. * We provide a really nice telephone line that can be used with your modem, and an in-house terminal server connected to our ISP (that was popular several years ago, is anyone still doing it?) * There is this web-enabled TV set in your room, with its own keyboard, but you can't use your own machine except via the telephone. Does the I-D need any of that? Would anyone like to suggest language? So, let's call all the telephone companies ISPs. I can think of a lot of things to call telephone companies :-(. For better or worse, it seems to be the nature of language and marketing organizations that once-precise terms lose meaning. Many of us can actually remember when Decision Support System and even Management Information System meant something, and neither one was a glorified spreadsheet. It happens. It is too bad. But, if there is any cure, it is getting a bit ahead of the
RFC 3748 on Extensible Authentication Protocol (EAP)
A new Request for Comments is now available in online RFC libraries. RFC 3748 Title: Extensible Authentication Protocol (EAP) Author(s): B. Aboba, L. Blunk, J. Vollbrecht, J. Carlson, H. Levkowetz, Ed. Status: Standards Track Date: June 2004 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 67 Characters: 157994 Obsoletes: 2284 I-D Tag:draft-ietf-eap-rfc2284bis-09.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc3748.txt This document defines the Extensible Authentication Protocol (EAP), an authentication framework which supports multiple authentication methods. EAP typically runs directly over data link layers such as Point-to-Point Protocol (PPP) or IEEE 802, without requiring IP. EAP provides its own support for duplicate elimination and retransmission, but is reliant on lower layer ordering guarantees. Fragmentation is not supported within EAP itself; however, individual EAP methods may support this. This document obsoletes RFC 2284. A summary of the changes between this document and RFC 2284 is available in Appendix A. This document is a product of the Extensible Authentication Protocol Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc3748.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 3769 on Requirements for IPv6 Prefix Delegation
A new Request for Comments is now available in online RFC libraries. RFC 3769 Title: Requirements for IPv6 Prefix Delegation Author(s): S. Miyakawa, R. Droms Status: Informational Date: June 2004 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 6 Characters: 10287 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-ipv6-prefix-delegation-requirement-04.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc3769.txt This document describes requirements for how IPv6 address prefixes should be delegated to an IPv6 subscriber's network (or site). This document is a product of the IP Version 6 Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc3769.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 3767 on Securely Available Credentials Protocol
A new Request for Comments is now available in online RFC libraries. RFC 3767 Title: Securely Available Credentials Protocol Author(s): S. Farrell, Ed. Status: Standards Track Date: June 2004 Mailbox:[EMAIL PROTECTED] Pages: 25 Characters: 49552 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-sacred-protocol-bss-09.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc3767.txt This document describes a protocol whereby a user can acquire cryptographic credentials (e.g., private keys, PKCS #15 structures) from a credential server, using a workstation that has locally trusted software installed, but with no user-specific configuration. The protocol's payloads are described in XML. This memo also specifies a Blocks Extensible Exchange Protocol (BEEP) profile of the protocol. Security requirements are met by mandating support for TLS and/or DIGEST-MD5 (through BEEP). This document is a product of the Securely Available Credentials Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc3767.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 3784 on Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)
A new Request for Comments is now available in online RFC libraries. RFC 3784 Title: Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE) Author(s): H. Smit, T. Li Status: Informational Date: June 2004 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 13 Characters: 27422 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-isis-traffic-05.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc3784.txt This document describes extensions to the Intermediate System to Intermediate System (IS-IS) protocol to support Traffic Engineering (TE). This document extends the IS-IS protocol by specifying new information that an Intermediate System (router) can place in Link State Protocol (LSP) Data Units. This information describes additional details regarding the state of the network that are useful for traffic engineering computations. This document is a product of the IS-IS for IP Internets Working Group of the IETF. This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc3784.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 3812 on Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB)
A new Request for Comments is now available in online RFC libraries. RFC 3812 Title: Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) Management Information Base (MIB) Author(s): C. Srinivasan, A. Viswanathan, T. Nadeau Status: Standards Track Date: June 2004 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 68 Characters: 136475 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-mpls-te-mib-14.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc3812.txt This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for Multiprotocol Label Switching (MPLS) based traffic engineering (TE). This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc3812.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 3814 on Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB)
A new Request for Comments is now available in online RFC libraries. RFC 3814 Title: Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE) Management Information Base (MIB) Author(s): T. Nadeau, C. Srinivasan, A. Viswanathan Status: Standards Track Date: June 2004 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 42 Characters: 87518 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-mpls-ftn-mib-09.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc3814.txt This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for defining, configuring, and monitoring Forwarding Equivalence Class (FEC) to Next Hop Label Forwarding Entry (NHLFE) mappings and corresponding actions for use with Multiprotocol Label Switching (MPLS). This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc3814.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
RFC 3815 on Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP)
A new Request for Comments is now available in online RFC libraries. RFC 3815 Title: Definitions of Managed Objects for the Multiprotocol Label Switching (MPLS), Label Distribution Protocol (LDP) Author(s): J. Cucchiara, H. Sjostrand, J. Luciani Status: Standards Track Date: June 2004 Mailbox:[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Pages: 106 Characters: 215916 Updates/Obsoletes/SeeAlso:None I-D Tag:draft-ietf-mpls-ldp-mib-14.txt URL:ftp://ftp.rfc-editor.org/in-notes/rfc3815.txt This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP). This document is a product of the Multiprotocol Label Switching Working Group of the IETF. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to [EMAIL PROTECTED] Requests to be added to or deleted from the RFC-DIST distribution list should be sent to [EMAIL PROTECTED] Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to [EMAIL PROTECTED] with the message body help: ways_to_get_rfcs. For example: To: [EMAIL PROTECTED] Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to [EMAIL PROTECTED] Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution.echo Submissions for Requests for Comments should be sent to [EMAIL PROTECTED] Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. ftp://ftp.isi.edu/in-notes/rfc3815.txt ___ IETF-Announce mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf-announce
