Re: report on the wlan difficulties in IETF?
At 08:15 AM 11/19/2003, Jari Arkko wrote... >Say, its pretty useless to authenticate beacons if >the radios are simply swamped by too many nodes who think they are >access points This is not a technical issue. By taking advantage of unlicensed frequencies, 802.1a/b/g must not cause interference with licensed services, and must accept interference from other users, at least in the US. There really is no basis for any complaint of lack of service due to interference from any other WLAN or ISM device/user. If you desire a somewhat assured RF medium, explored using licensed frequencies, but then you'll have to live with other restraints. Mike
Re: Ietf ITU DNS stuff
At 07:30 PM 12/3/2003, Dean Anderson wrote... >There are, though, good reasons to have some government controls on >telecom. Whether these controls are too excessive or too lax is not up to >ICANN or the ITU. I can think of cases were some good has come of it. >E911, for example. Radio, TV, cellphone allocations. Ham Radio licences. >If license-free wireless operation weren't restricted in power, few people >would be able to use 802.11 because one company would be broadcasting at >hundreds of watts, etc. None of what you mention is even remotely comparable to the Internet. RF spectrum is a naturally shared, limited medium. Because physical law cannot be changed, manmade laws must be used to regulate it for efficient use. No such case can be made for the Internet, which is not bounded in either bandwidth or number of connections in any practical sense. It is also not something which can be subjected to any sort of control, as it is not a "thing." The Internet is strictly an intellectual construct, nothing more. There is nothing physical or real to control. It's a bunch of network operators who have agreed to interconnect using agreed-upon protocols. Sure, some governments can try to control some of the physical media which the Internet makes use of, but getting around that is simply a matter of reconfiguration.
RE: Ietf ITU DNS stuff
At 10:45 AM 12/4/2003, Steve Silverman wrote... >The Internet is _in part_ an intellectual construction but so is >the telephone network. I disagree. >It doesn't do much without a physical implementation. Cognitive thought doesn't exist without a brain. That doesn't mean that thought is only "_in part_ an intellectual construction." :-) >Whatever rights you, I, or anyone else may think are >inalienable, in many parts of the world, the only rights anyone has >are what the >government allows. I'm not saying I like with this but as a practical >matter, >if the government controls the switches and can throw people in jail >(or simply shoot them), it can >also restrict what is implemented on the network equipment. Many governments have over time attempted to control thought and personal speech, and none has been successful for any extended period of time. The Internet is no different, as it is easily re-configured and is by design self-healing.
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
At 05:42 PM 1/9/2004, [EMAIL PROTECTED] wrote... >On Fri, 09 Jan 2004 15:13:50 EST, [EMAIL PROTECTED] (Mike S) said: > >> Use of the MAPS RBL and DUL clearly impairs the availability and integrity of >> the Internet email system and the information transferred using that system. >> MAPS RBL and DUL participants are actively participating in illegal denial of >> service > >Erm. Sounds like you're choking on something. > No. You are. >Note that MAPS is *NOT* blocking a single piece of e-mail itself. None. Zip. Zero. Of course not. MAPS is simply a database. As I quite clearly said, *USE* of MAPS impairs email. >Meanwhile, the site that's actually rejecting your mail has made that decision >*itself*, >that it doesn't want to receive mail from you, possibly with MAPS as one component >of the information used to make said decision. > >To have a chance of winning this argument, you'll have to prove that the receiving >system is legally *obligated* to accept every piece of mail that you might happen to >want to send. MX <> recipient. If I send email [EMAIL PROTECTED] to the published MX for aol.com and aol.com blocks the ultimate recipient from receiving that email, they are in violation of the law, having interfered with the availability of email for both the sending and receiving systems. By publishing an MX, they have agreed to accept email for any valid address within their domain. That's what an MX is. They are likely in breach of their civil contract with the recipient, also. Of course, anyone who publishes an MX record but refuses mail is simply an idiot incapable of understanding why the Internet exists in the first place. The Balkanization has begun. The Internet is dead.
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
At 06:43 PM 1/9/2004, Ken Raeburn wrote... > If you think there's some violation of law going on here, please be more > specific. What law, and in what country? Try to keep up. A specific citation has already been made.
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
At 12:03 PM 1/9/2004, Keith Moore wrote... >> There's >> just one more condition - his mate, though great as mates go, is an anti- >> RBL purist. He refuses to use RBLs. > >His mate is a wise man. RBLs are a really terrible idea, and they've >caused a lot of valid mail to be rejected. Not only that, but at least in the U.S., they are illegal per 18 U.S.C. 1030 -Fraud and Related Activity in Connection with Computers. That law reads in part: "Whoever... knowingly causes the transmission of a program, information, code, or command, and as a result of such conduct, intentionally causes damage without authorization, to a protected computer...shall be punished..." MAPS RBL and DUL and those who participate in it knowingly transmit information (zone lookups) and commands (SMTP configurations) which causes unauthorized damage to protected systems. "[T]he term "protected computer" means a computer... which is used in interstate or foreign commerce or communications, including a computer located outside the United States that is used in a manner that affects interstate or foreign commerce or communication of the United States" This clearly covers any computer with which the user may send email for Internet commerce, including eBay and web purchases. "The term 'damage' means any impairment to the integrity or availability of data, a program, a system, or information" Use of the MAPS RBL and DUL clearly impairs the availability and integrity of the Internet email system and the information transferred using that system. MAPS RBL and DUL participants are actively participating in illegal denial of service
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
At 08:42 AM 1/10/2004, Bill Sommerfeld wrote... >> > If you think there's some violation of law going on here, please be more >> > specific. What law, and in what country? >> >> Try to keep up. A specific citation has already been made. > >and already been debunked. If one considers spraying bullets and so shooting and killing innocent bystanders while defending against an assailant as legal, then yes, it's been debunked.
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
At 06:41 PM 1/9/2004, Vernon Schryver wrote... >Could you point to significant amounts of real mail, as opposed to >theoretical examples, that might reasonably have consider legitimate >by its targets but that was rejected as the result of a MAPS RBL >listing? Note that the validity of mail is determined not its senders >but by its targets. Yes. For a lengthy period, all mail.com SMTP servers were included in the RBL, blocking significant numbers of legitimate, private, non-spam emails from reaching willing recipients.
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
At 10:32 PM 1/9/2004, Ken Raeburn wrote... >Not in any mail I've seen so far, but the other traffic since implies I've missed >something. Investigating that... my apologies. 18 U.S.C. 1030 >In any case, the quotations I've seen suggest you believe that the blocking is done >without authorization. That is correct. Understand that I am NOT referring to UCE/spam. In the case of UCE/Spam, I will stipulate that the intended recipient may indeed have authorized upstream blocking/filtering. It is, however, irrational and incorrect to argue that the recipient has authorized blocking/filtering of email replies sent in direct response to queries they have sent. RBL/DUL makes no distinction between these types of email, and indiscriminately causes both types to be blocked. One cannot argue that general "best effort" or "no guarantees" terms of service cover this situation, since the blocking is known and deliberate. > As I said in my previous mail, I suspect the service agreement is likely to provide > for it; I can only speak for the ISP agreements I've been a party to, and they do NOT authorize any upstream filtering or blocking. >And I suspect the receiving computer to which "damage" would be done would be the >ISP's mail server; presumably none of this is interfering with the transmission >between the ISP's mail server and the customer's machine. It is interfering with communications between sender and recipient, which is exactly what the cited law prohibits. The maintainer of the MX has publicly agreed to accept mail destined for the domain (by publishing an MX record). Blocking/refusing/filtering email bound for a protected system is a violation of U.S. law, unless specific authorization has been granted to do so, which has not occurred (see above).
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
At 12:08 PM 1/10/2004, Richard Welty wrote... >might i suggest citing some case law demonstrating the relevance >of the statute you cited? Non sequitor. By your implied logic, no new laws could be effectively created or enforced, since all would lack precedent. The relevant code is relatively new, so only limited, if any, case law can be expected to be extant in any case.
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
At 01:55 PM 1/10/2004, [EMAIL PROTECTED] wrote... >I'm sure if that legal theory were sustainable, MAPS would have been served notice >of a lawsuit by now So, your argument amounts to the equivalent of "If life is possible on Mars, then life must exist on Mars." You'd better let NASA know, it may save them a bundle of money.
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
At 06:07 PM 1/10/2004, Daniel Pelstring wrote... >The administrator doing the blocking would be in the clear, since >they are authorized to access this computer (and are in fact authorized to >change this information, even if you disagree with the change.) The law prohibits "intentionally cause[ing] damage without authorization, to a protected computer." The MX is not the "protected computer" in the discussion at hand. The "protected computer" is the computer of the email addressee. The MX is merely an intermediary. By the logic you present, one could argue that no violation (of this law) would be present for hacking a backbone router and inserting a filter which dropped all incoming packets bound for any next hop, since that router would not be "damaged" under the definition given by 18 U.S.C. 1030, the "damage" only occurring external to that router. > The >provider of a blocking list would not have accessed this computer at all, >since they did not make the change. The desires of the intended recipient >do not matter at all under this law, as they do not own the computer on >which the change was made. The change interferes with the delivery of email to a "protected computer," i.e. the computer of the person to whom the email is sent. The ISP's mail exchanger is simply an intermediary. The RBL and DUL are quite clearly (and openly) designed and intended to be used to implement denial of service. Doing so with the explicit authorization of the email recipient would be legal. Using MAPS RBL and/or DUL is an act which "knowingly causes the transmission of a program, information, code, or command, and as a result of such conduct, intentionally causes damage ['impairment to the integrity or availability of data, a program, a system, or information'] without authorization, to a protected computer," a violation of 18 U.S.C. 1030. The "protected system" is the email addressee's, not the ISP's. If a recipient is not receiving desired email due to ISP use of the MAPS system, the ISP is guilty of unlawful denial of service. Not only the ISP, but also MAPS, is guilty of knowingly and intentionally damaging a protected computer. A person may authorize, indeed ask, that spam be blocked upstream. With such authorization, an ISP is clearly free to block spam email. As I have already pointed out, it is irrational to claim that a addressee has authorized that _desired_ email be dropped. I have encountered exactly that situation due to use of the MAPS DUL. The MAPS system does not, and cannot, distinguish between spam email and legitimate, addressee desired email. It is a brute force system which throws the baby out with the bathwater.
Apology
The recent thread which I've been contributing to has extended too far from both the original subject and the purpose of this list. I will make no further responses via this list. Those interested and willing to argue their points of view are free to use direct email, which is what I will do should I respond further.
Re: Death of the Internet - details at 11
At 02:02 PM 1/12/2004, Tony Hain wrote... >While one aging application does not constitute 'the Internet', this should >be taken as an early indicator of things that are happing, with more to >come. The true threat is administrative, not technical. It won't do any good to have an IPv6 address space when ISPs won't allow personal servers (and block ports to enforce that ban), blackhole lists block communications from anyone not considered to be "in the club," and ISPs allow TOS/AUP contracts to be violated in proportion to the customer's monthly bill. It won't be long before ISPs only allow SYNs to flow one-way for "non-business" customers. Welcome to the new, improved Interweb.
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
At 06:50 PM 1/12/2004, Vernon Schryver wrote... >Instead of paying the extra cost to hire an ISP that cares >enough to not have spamming customers, people complain about the evils >of blacklists. Feh. Once again with an argument based on incorrect assumptions. I don't spam. I would preferentially route email direct for two main reasons: 1) privacy - routing via my ISP's outbound SMTP gives them the right to intercept and read my email, according the ECPA; 2) control - sending from my own system allows me to control retry attempts and times, instead of being forced to wait 4 days for my ISP to bounce an undelivered back to me, assuming they don't just silently lose it. I can't do so because my IP address is on a blacklist. I have cable modem, but the world thinks I'm a dial-up. For that reason alone, having nothing whatsoever to do with spam, I'm forced to give up privacy and control of my communications. "Anti-spam" initiatives that are based on such blacklists are quite simply the failed results of irrational, fascist thought. Regardless of your exact definition of spam, all reasonable ones I've heard have one thing in common - it's based on CONTENT, not IP address. Blacklists couldn't care less about content - legitimate email or spam, out it goes, to the detriment of communications, which is the Internet's raison d'etre. I take that back, it used to be that way. Now the Internet is meant to make big corporations lots of money. Blacklists also, quite clearly, don't work to eliminate spam.
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
At 09:58 PM 1/12/2004, Dean Anderson wrote... >On Mon, 12 Jan 2004, Mike S wrote: >1) privacy - routing via my ISP's outbound SMTP gives them >> the right to intercept and read my email, according the ECPA; > >Err, Just the opposite is more freqently the case.The ECPA specifically prohibits the >ISP from exceeding its limited authority. Cite, please. I've got one: "(2)(a)(i) It shall not be unlawful under this chapter for an ... agent of a provider of wire or electronic communication service, whose facilities are used in the transmission of a wire or electronic communication, to intercept, disclose, or use that communication in the normal course of his employment..." >2) control - sending from my own system allows me to control retry >> attempts and times, instead of being forced to wait 4 days for my ISP >> to bounce an undelivered back to me, assuming they don't just silently >> lose it. > >If your contract allows you to run your own system, then the ISP would not >be allowed to prevent you from doing that. This could be made into an >ECPA issue---some people think it is merely and only a contract >non-performance issue and said contract excludes liability for failure to >perform. Like the Sherman Anti-Trust Act, the ECPA is a criminal statute >with civil actions permitted, and carries its own civil and criminal >penalties. My ISP's support of the MAPS DUL, and the use of the MAPS system by others, is a violation of 18 U.S.C. 1030. Email me for details, but I've covered this on this list recently. >Of course, if your contract does not allow you to run your own system, >then you don't have a complaint about blacklists blocking it. There is nothing to prohibit direct routing of email.
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
At 06:41 PM 1/9/2004, Vernon Schryver wrote... >Could you point to significant amounts of real mail, as opposed to >theoretical examples, that might reasonably have consider legitimate >by its targets but that was rejected as the result of a MAPS RBL >listing? Note that the validity of mail is determined not its senders >but by its targets. Yes. For a lengthy period, all mail.com SMTP servers were included in the RBL, blocking significant numbers of legitimate, private, non-spam emails from reaching willing recipients.
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
At 06:50 PM 1/12/2004, Vernon Schryver wrote... >Instead of paying the extra cost to hire an ISP that cares >enough to not have spamming customers, people complain about the evils >of blacklists. Feh. Once again with the incorrect assumptions. I don't spam. I would preferentially route email direct for two main reasons: 1) privacy - routing via my ISP's outbound SMTP gives them the right to intercept and read my email, according the ECPA; 2) control - sending from my own system allows me to control retry attempts and times, instead of being forced to wait 4 days for my ISP to bounce an undelivered back to me, assuming they don't just silently lose it. I can't do so because my IP address is on a blacklist. I have cable modem, but the world thinks I'm a dial-up. For that reason alone, having nothing whatsoever to do with spam, I'm forced to give up privacy and control of my communications. "Anti-spam" initiatives that are based on such blacklists are quite simply the failed results of irrational, fascist thought. Regardless of your exact definition of spam, all reasonable ones I've heard have one thing in common - it's based on CONTENT, not IP address. Blacklists couldn't care less about content - legitimate email or spam, out it goes, to the detriment of communications. They also, quite clearly, don't work to eliminate spam.
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
At 10:45 PM 1/12/2004, Vernon Schryver wrote... >Mr. Sauve could rent an IP address that is not on dial-up or dynamic >blacklists and run his systems there. Proven wrong, you now change your argument to one of trying to rationalize interference with legitimate email, and attempting to place the burden on those who wish to use the Internet as designed, not as damaged by your beloved blacklists. As I said, fascist.
Re: SMTP Minimum Retry Period - Proposal To Modify Mx
At 10:45 PM 1/12/2004, Vernon Schryver wrote... >Mr. Sauve could rent an IP address that is not on dial-up or dynamic >blacklists and run his systems there. Proven wrong, Vernon now changes his tack to one of trying to rationalize interference with legitimate email and attempting to place the burden on those who wish to use the Internet as designed, not as damaged by his beloved blacklists. As I said, fascist. He has learned to use whois and Google, though, and seems very self-impressed at his ability to learn such simple things. He has apparently not, however, discovered dictionary.com. "In the design of ... software tools, 'the fascist alternative' is the most restrictive and structured way of capturing a particular function;"
Re: The right to refuse, was: Re: Principles of Spam-abatement
At 07:56 AM 3/14/2004, Iljitsch van Beijnum wrote... >On 14-mrt-04, at 12:49, Dr. Jeffrey Race wrote: > >>You are right a different approach is needed, but not this one >>because it does not admit communication from strangers. > >I addressed this part at the end of my message. A mechanism to allow strangers to get >hold of a desirability tag would of course be included. (If the holder of a tag >misbehaves the tag is invalidated, of course.) If a stranger can get a "tag," then it is useless, as there is nothing to stop a spammer from repeatedly getting new tags as old ones are invalidated. Basing them on source domain, IP, etc. makes no difference, as these are already frequently changed. It also requires creation of an entirely new authority and infrastructure to handle creation and distribution of these "tags." Specifics, please, if you don't feel this is the case.
Re: Problem of blocking ICMP packets
At 12:34 AM 6/16/2004, Sally Floyd wrote... >Alberto Medina, Mark Allman, and I have a draft paper on >"Measuring the Evolution of Transport Protocols in the Internet" >that has a section (Section V.B.) on Path MTU Discovery. >>From the paper: > >"Table X shows that PMTUD is used and succeeded for slightly less >than half of the [web] servers on our list. For 31\% of the servers >on our list, the server did not attempt Path MTU Discovery. For >18\% of the servers on our list, Path MTU Discovery failed, presumably >because of middleboxes that block ICMP packets on the path to the >web server." Any router configured to block ICMP packets is, quite simply, in violation of RFC792 (STD5), which clearly states "ICMP is actually an integral part of IP, and must be implemented by every IP module." For a router, "implemented" means forwarded to the destinations next hop. So the fact is, by blocking ICMP, such ISPs have broken IP connectivity, and can no longer claim to be providing Internet (IP) service. ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: draft-farrel-rtg-morality-requirements-00.txt
At 05:23 PM 11/16/2004, James M. Polk wrote... >http://www.ietf.org/internet-drafts/draft-farrel-rtg-morality-requirements-00.txt > >I do not see why this ID should be limited to the Routing area... Morals exist at layer 3, and are therefore related to Routing. Ethics exist at layer 2, perhaps you would like to submit an RFC covering switching ethics? (Self-preservation and enlightened self-interest are layer 1, and are self-defining) ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: reduce jitter in routed network for voip applications
At 06:09 AM 3/28/2005, Daniele Giordano wrote... >RTP is transparent at the transport layer. We analyse TCP and UDP: >TCP is connection oriented and so the communication begins with the >definition of a virtual circuit. >A virtual circuit is a temporary connection of sequence nodes with relative >reservation of bandwidth. >A connection oriented service gives the certainty that all information units >use the same nodes with a same medium latency. >Same latency maintains reduced the jitter. That is incorrect unless _other_, stateful protocols (ex. RSVP, integrated services) are in use throughout the entire network. That is not the general case. IP routes on a per hop basis, whether TCP or UDP. There is no "virtual circuit" created, except at the endpoints. >I think that RTP should use a layer 4 connection oriented protocol (like >TCP) but without retransmissions of information units with excessive delay >or errors (like UDP). > >What do you think about this? You're trying to solve a problem which is incorrectly defined, and therefore doesn't exist. Diffserv already provides a QoS mechanism for VoIP and does not require gateways to maintain state for each connection. It, like Intserv, cannot be assumed to exist through any random Internet path. RFC2474, RFC2475. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: reduce jitter in routed network for voip applications
At 01:26 PM 3/28/2005, Daniele Giordano wrote... >CoS, ToS, QoS work on the information units queued in a buffer of a device. >I think that, in the same way of a circuit switched network, an >establishment phase could exist. In this phase the network could reserve the >right resources. >i.e. virtual circuit, bandwidth, > >Thanks. It has already been done. Look up RSVP. Look up "integrated services." Do some research and you'll find that others have already recognized the significant problems (scalability, resiliency) associated with trying to implement such a protocol, which requires that gateways maintain state for potentially millions of connections. Diffserv is one (the) answer to those issues. If you want a circuit switched network, just use the ones which already exist. Look up ATM. Look up Frame Relay. Look up X.25. Look up PSTN. Do your homework. http://www.google.com/ Thanks. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
