North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Fw: "...the IPv4 TOS field should be end-to-end...."
With the advent of DiffServ, intermediate nodes may modify the Differentiated Services Codepoint (DSCP) [RFC2474] of the IP header to indicate the desired Per-hop Behavior (PHB) [RFC2475, RFC2597, RFC2598]. The DSCP includes the three bits formerly known as the precedence field. Because any modification to those three bits will be considered illegal by endpoints that are precedence-aware, they may cause failures in establishing connections, or may cause established connections to be reset. ----- Original Message ----- From: Alan Hannan <[email protected]> To: JIM FLEMING <[email protected]> Cc: Roeland Meyer <[email protected]>; 'Shawn McMahon' <[email protected]>; <[email protected]> Sent: Tuesday, November 21, 2000 12:15 AM Subject: Re: "...the IPv4 TOS field should be end-to-end...." > > This has been addressed in the appropriate standards bodies: > > ftp://ftp.isi.edu/in-notes/rfc2873.txt > > -alan > > Thus spake JIM FLEMING ([email protected]) > on or about Mon, Nov 20, 2000 at 11:33:30PM -0600: > > > > 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 <[email protected]> > > To: 'Shawn McMahon' <[email protected]>; <[email protected]> > > 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:[email protected]] > > > > Sent: Monday, November 20, 2000 7:21 PM > > > > To: [email protected] > > > > 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 > > > > couldn't just simply > > > > > upsell the customer to a managed fw solution etc if that's > > > > the concern. > > > > > Educate them, and let them decide based on the education > > > > 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? > > > > > > > > > > > > > > > > >
|