Fw: "...the IPv4 TOS field should be end-to-end...."

["JIM FLEMING" <jfleming () anet com>]

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 <alan () mindvision com>
To: JIM FLEMING <jfleming () anet com>
Cc: Roeland Meyer <rmeyer () mhsc com>; 'Shawn McMahon' <smcmahon () eiv com>;
<nanog () merit edu>
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 (jfleming () anet com)
>  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 <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
> > > > 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?