Bob,
Bob Hinden wrote:
>
> Alex,
>
> I am responding because you sent the email to me directly.
>
It was in response to Brian, and you - your addition to Brian's list of
options.
But it is good to hear your opinion, and now I know how to get it (-:
> >IPv6 is not X's, or Y's IP. It is IETF's IPv6, in fact, everybody's
> >IPv6.
> > [...]
> >The IPv6 WG is not a preferential club, or an exclusivist group. The
>
> The chairs try to keep the working group process open and fair.
To keep the process open and fair may be challenging. It is nice that
the chairs try.
>
> >IPv6 WG is not to tell the IETF what standard is good and what standard
> >is bad. While the IPv6 WG develops IPv6, IT MUST ENSURE that IPv6 works
> >with, and it supports the other IETF standards.
>
> I don't think your statements are correct. There is not a formal IETF
> requirement that the working groups output support all other IETF standards.
>
I didn't say "all". I was referring directly to the QoS standards, which
are part of the IP layer's set of standards (IPsec is another). It
applies to others
as well, non-IP, like transports, etc...
I think I qualified that already in an earlier message to Kre.
> "c)" is one of the choices being discussed on the mailing list. From my
> read of the list, I don't see a consensus on any of the choices.
Brian was generous. He didn't put "f) Diffserv only" in his list. Maybe
some people that are not convinced about Intserv/RSVP would have voted
for that.
It would have been interesting for a consensus building process.
c) is a nice consensus building block, it can be seen as a superset of
b) It does
not exclude Intserv, it only adds Diffserv. It is a WIN-WIN (hint,
hint).
> [...] Perhaps you only meant to include MPLS, Diff
> Serv, and Int Serv standards in your assertion.
>
> In this case, I don't think that the w.g. has to do this (i.e., MUST).
> [...]
> However, it will have to a reason more compelling than
> other IETF working groups have standardized something.
If this is indeed the process, then it gives an unfair power to IPv6 WG
to undersupport (could read undermine) standards created by other WGs
(Diffserv), which are IP standards, and which inter-depend with IPv6.
This is in my view a broken process.
.
The appropriate and fair process would be, in my view, for the IPv6 WG
to standardize functions that other IP standards depend on, unless there
is a consensus on a compelling reason, that it should not do so.
> p.s. For what it is worth, my current thinking is that I would prefer not
> use the flow label field for any specific QOS approach(s).
I do not think we can afford not to support specific QoS models. In
fact, it is stringent to add the Diffserv support -- there are many
vendors building IPv4 forwarding and QoS engines in silicon. Many do
IPv6 as well, and it is a struggle to make that cost/performance
comparable with IPv4.
> I am open to
> something that makes it easier to identify flows.
This is already done.
> This could be used for
> QOS or other flow related applications.
I wish you were more specific.
Flow related applications other than QoS in the network layer, to me, to
many, do not mean
much, besides forwarding. And that is already done by MPLS. Based on
your response, I
would not expect your encouraging of functions that would be friendly to
MPLS, so I am
a bit puzzled.
Alex
S/MIME Cryptographic Signature
