RE: ISPs as content-police or method-police
Please reference any suit regarding breach of contract. Examples abound. Port filtering may be construed as a material breach when the expectation is, that there is to be no port filtering. Access is access, even when the customer doesn't know that they are being restricted in their access. That just assures you that they will go ballistic when they find out. Face it guys, you KNOW that this is basically dishonest. As such, it is indefensible. I would almost bet <amount> that none of the transit providers mentions restrictions, on access, in their contracts. I would almost bet <1/2 amount> that NONE of the access providers mention same in THEIR contracts. The general expectation is for clear and open pipes. Put such restiction into your contracts and you will lose customers. Don't put them in and start filtering anyway and you will lose court cases...big ones.
-----Original Message----- From: Shawn McMahon [mailto:smcmahon@eiv.com] Sent: Monday, November 20, 2000 7:21 PM To: nanog@merit.edu Subject: Re: ISPs as content-police or method-police
On Mon, Nov 20, 2000 at 12:03:57PM -0500, Christian Kuhtz wrote:
What doesn't make sense in that argument is why you
upsell the customer to a managed fw solution etc if that's
Educate them, and let them decide based on the education
couldn't just simply the concern. they received.
Because it doesn't just affect them; it affects you, your customers, and your business.
I wouldn't be so sure, particularly because of the legal exposure...
Does anybody have a live example of this supposed legal exposure, to counter all the many examples those of us who don't believe in it have given?
In my opinion, the IPv4 TOS field should be end-to-end.... ...clients should set it....routers should leave it alone.... Jim Fleming http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp ----- Original Message ----- From: Roeland Meyer <rmeyer@mhsc.com> To: 'Shawn McMahon' <smcmahon@eiv.com>; <nanog@merit.edu> Sent: Monday, November 20, 2000 11:29 PM Subject: RE: ISPs as content-police or method-police
Please reference any suit regarding breach of contract. Examples abound. Port filtering may be construed as a material breach when the expectation is, that there is to be no port filtering. Access is access, even when the customer doesn't know that they are being restricted in their access. That just assures you that they will go ballistic when they find out.
Face it guys, you KNOW that this is basically dishonest. As such, it is indefensible. I would almost bet <amount> that none of the transit
providers
mentions restrictions, on access, in their contracts. I would almost bet <1/2 amount> that NONE of the access providers mention same in THEIR contracts. The general expectation is for clear and open pipes. Put such restiction into your contracts and you will lose customers. Don't put them in and start filtering anyway and you will lose court cases...big ones.
-----Original Message----- From: Shawn McMahon [mailto:smcmahon@eiv.com] Sent: Monday, November 20, 2000 7:21 PM To: nanog@merit.edu Subject: Re: ISPs as content-police or method-police
On Mon, Nov 20, 2000 at 12:03:57PM -0500, Christian Kuhtz wrote:
What doesn't make sense in that argument is why you
upsell the customer to a managed fw solution etc if that's
Educate them, and let them decide based on the education
couldn't just simply the concern. they received.
Because it doesn't just affect them; it affects you, your customers, and your business.
I wouldn't be so sure, particularly because of the legal exposure...
Does anybody have a live example of this supposed legal exposure, to counter all the many examples those of us who don't believe in it have given?
Jim An exception to this is Diffserv. This issue was discussed at length in the diffserv WG and decided Diffserv DSCP remarking does not really violate this. Bora ----- Original Message ----- From: "JIM FLEMING" <jfleming@anet.com> To: "Roeland Meyer" <rmeyer@mhsc.com>; "'Shawn McMahon'" <smcmahon@eiv.com>; <nanog@merit.edu> Sent: Monday, November 20, 2000 9:33 PM Subject: "...the IPv4 TOS field should be end-to-end...."
In my opinion, the IPv4 TOS field should be end-to-end.... ...clients should set it....routers should leave it alone....
Jim Fleming http://www.unir.com/images/architech.gif http://www.unir.com/images/address.gif http://www.unir.com/images/headers.gif http://www.ntia.doc.gov/ntiahome/domainname/130dftmail/unir.txt http://msdn.microsoft.com/downloads/sdks/platform/tpipv6/start.asp
----- Original Message ----- From: Roeland Meyer <rmeyer@mhsc.com> To: 'Shawn McMahon' <smcmahon@eiv.com>; <nanog@merit.edu> Sent: Monday, November 20, 2000 11:29 PM Subject: RE: ISPs as content-police or method-police
Please reference any suit regarding breach of contract. Examples abound. Port filtering may be construed as a material breach when the
is, that there is to be no port filtering. Access is access, even when
customer doesn't know that they are being restricted in their access. That just assures you that they will go ballistic when they find out.
Face it guys, you KNOW that this is basically dishonest. As such, it is indefensible. I would almost bet <amount> that none of the transit providers mentions restrictions, on access, in their contracts. I would almost bet <1/2 amount> that NONE of the access providers mention same in THEIR contracts. The general expectation is for clear and open pipes. Put such restiction into your contracts and you will lose customers. Don't put
expectation the them
in and start filtering anyway and you will lose court cases...big ones.
-----Original Message----- From: Shawn McMahon [mailto:smcmahon@eiv.com] Sent: Monday, November 20, 2000 7:21 PM To: nanog@merit.edu Subject: Re: ISPs as content-police or method-police
On Mon, Nov 20, 2000 at 12:03:57PM -0500, Christian Kuhtz wrote:
What doesn't make sense in that argument is why you
upsell the customer to a managed fw solution etc if that's
Educate them, and let them decide based on the education
couldn't just simply the concern. they received.
Because it doesn't just affect them; it affects you, your customers, and your business.
I wouldn't be so sure, particularly because of the legal exposure...
Does anybody have a live example of this supposed legal exposure, to counter all the many examples those of us who don't believe in it have given?
On Mon, Nov 20, 2000 at 11:33:30PM -0600, JIM FLEMING wrote:
In my opinion, the IPv4 TOS field should be end-to-end.... ...clients should set it....routers should leave it alone....
The IPv4 TOS bits are depreciated as proposed in RFC1349; RFC1349 was obsoleted by RFC2474. The DiffServ interpretation of the same bits used by RFC1349 (called the DS bits in RFC2474) does not impose end-to-end semantics on their use; it specifies "per-hop behaviours and mechanisms". Joe
You basically have 3 choices here. 1) Filter known trojan ports to your customers (Which argueably may or may not include port 139) 2) Routinely scan your customer blocks and inform them of trojans they could be infected with, and any open shares. 3) Do nothing and deal with the possible fallout which may include turning down the customers port, if they get compromised. Which do YOU view as the lesser of the evils here. Your arguing 1 isn't doable. 2 is possibly a no go, depending on the contract and customer also, and 3 isn't very good either. Jason --- Jason Slagle - CCNA - CCDA Network Administrator - Toledo Internet Access - Toledo Ohio - raistlin@tacorp.net - jslagle@toledolink.com - WHOIS JS10172 /"\ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . \ / ASCII Ribbon Campaign . If dreams are like movies then memories X - NO HTML/RTF in e-mail . are films about ghosts.. / \ - NO Word docs in e-mail . - Adam Duritz - Counting Crows On Mon, 20 Nov 2000, Roeland Meyer wrote:
Please reference any suit regarding breach of contract. Examples abound. Port filtering may be construed as a material breach when the expectation is, that there is to be no port filtering. Access is access, even when the customer doesn't know that they are being restricted in their access. That just assures you that they will go ballistic when they find out.
Face it guys, you KNOW that this is basically dishonest. As such, it is indefensible. I would almost bet <amount> that none of the transit providers mentions restrictions, on access, in their contracts. I would almost bet <1/2 amount> that NONE of the access providers mention same in THEIR contracts. The general expectation is for clear and open pipes. Put such restiction into your contracts and you will lose customers. Don't put them in and start filtering anyway and you will lose court cases...big ones.
Thus spake "Roeland Meyer" <rmeyer@mhsc.com>
Please reference any suit regarding breach of contract. Examples abound. Port filtering may be construed as a material breach when the expectation is, that there is to be no port filtering. Access is
even when the customer doesn't know that they are being restricted in their access. That just assures you that they will go ballistic when
access, they
find out.
If filtering is in the contract, it's hardly breach of contract to perform it.
Face it guys, you KNOW that this is basically dishonest. As such, it is indefensible. I would almost bet <amount> that none of the transit providers mentions restrictions, on access, in their contracts. I would almost bet <1/2 amount> that NONE of the access providers mention same in THEIR contracts.
AT&T, I believe, was the first major provider to start filtering port 25; here's the relevant part of their contract: http://www.att.net/general-info/terms.html "AT&T reserves the right to block, filter or delete Unsolicited E-Mails." While it doesn't explicitly state how they intend to "block, filter or delete" spam, filtering port 25 by default can be reasonably construed to fit that definition, and is therefore within the contract. Ths is also promising: "don't send materials that contain viruses, worms, or any other destructive elements; ... You may not use or attempt to use the Service to violate its security or the security of systems accessible through it, ... you should secure your computer equipment so that only authorized users can gain access to your Service account." You could claim that these sections authorize blocking of QAZ et al, since the activity of worms is prohibited. Also, customers are required to secure their computers to prevent intrusion, so leaving any blatantly insecure protocol like SMB enabled might be breach of contract. Wholesale blocking of SMB might even be allowed. Of course, I wouldn't want to use that logic in court, but a good lawyer could probably pull it off. I'd prefer to insert more specific wording into the contract first.
The general expectation is for clear and open pipes. Put such restiction into your contracts and you will lose customers.
As long as a user can request the filters be removed (as in AT&T's case), I doubt anyone will lose customers. In fact, I've seen many ads for ISPs which promote their filtering service with the belief that it will bring them more customers.
Don't put them in and start filtering anyway and you will lose court cases...big ones.
If an ISP refuses to turn off unrequested filters, and the filters aren't in the contract, I can see a lawsuit. I can also see the customer simply taking their business elsewhere and persuing the matter through the press. As AGIS proved, that turned out to be far more effective than courts. Then again, nobody here seems to be suggesting mandatory filtering. Why is there such a strong objection to opt-out filters, where a single call or email can get the filters turned off? Is using a phone really that difficult? S | | Stephen Sprunk, K5SSS, CCIE #3723 :|: :|: Network Design Consultant, GSOLE :|||: :|||: New office: RCDN2 in Richardson, TX .:|||||||:..:|||||||:. Email: ssprunk@cisco.com
participants (6)
-
Bora Akyol
-
Jason Slagle
-
JIM FLEMING
-
Joe Abley
-
Roeland Meyer
-
Stephen Sprunk