RFC1883 and ipv6 spec v2

[bound@zk3.dec.com]

>the basic question being addressed by the diffserv effort is the
>best way to provide different qualities of Internet service in diferent
>environments - RSVP is just the right answer for some types of QoS
>problems but may not be the best way to deal with others.

I agree.  To stress my point further.

I can deploy IPv6 within XYZ Motors Intranet and use RSVP and IPv6
flow label to define a QOS strategy that will permit Warren MI to
Engineering Workstation running UNIX flavor "Finite Element Analysis"
application to accept multiple streams a) from Arizona Test Bed and b)
from Rochester Design Center at a higher priority than other packets on
the XYZ private internet.  The MCAD engineers packet never touches the
"Internet" its pure private enterprise and this can be done with RSVP
and I believe today with IPv6, if we as vendors can get some gurantee of
what bits we can count on for IPv6 Flow Label.  

But if the MCAD engineer wants to get a part from Ireland and to do that
must go through ISP and possibly over the Internet then the gurantees of
RSVP may not apply and diff services need to be used.  But, IMO the Flow
and other parameters in the packet must be in tact when the packet is
delivered to the Server or Client in Ireland for continuity and priority
within that Intranet so a global network corporate policy can be
maintained for that company.  The ISP market will differentiate
themselves IMO on who can give the best proximation of diff services to
support global corporate entities between-Intranet sites.

As far as TAG-SWITCHING.  First I think its a really good idea.  But
given the mail on this list I will read their specs before as they go to
last call to the IESG (as I am not on that mail list) and will raise an
objection and support within the IETF if that WG attempts to step on the
IPv6 Flow Label and not put it back in tact when exiting their DOI of
that packet when forwarding back to the private Intranet site.

Same for diff services.

The legal implications of stepping on my packet must be consistent with
the legal agreement I have with my ISP in entry to the Internet, or I
with my ISP will have the option of using any legal means necessary to
protect my privacy and right of packet containment en-pass thru the
Internet.  I don't think the IETF or IESG should permit alteration of
packets that affect the semantics of the packet being depended on by a
business, without legal council from the ISOC and in the U.S. by the
DOC.  All this adds up to "ergo" ----> what does the flow label
constitute in IPv6??????   And possibly the entire header.  IPSEC makes
it even more complex, add Key Escrow and it goes over the top. 

It is a very slippery slope to touch packets with IETF specifications. 

/jim