Bob Hinden wrote:
>
> Alex,
>
> >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.
>
> Process wise I think what you are suggesting doesn't scale. The IETF
> creates many standards. Some of the standards are widely used
> operationally, others are lightly used, and some are not used at all. If
> every IETF w.g. was required to support all other IETF standards, then I
> doubt the output would be very good. Individual working groups need to be
> able to make their own decision that is appropriate for the work they are
> doing.
>
Indeed. You are absolutely right, the process would have scaleability
problems
if extended to the entire IETF.
> I understand you are only really saying that IPv6 w.g. must support the
> proposed Diffserv flow label definition as proposed in the draft, but you
> keep doing it in general terms.
I am talking only about standards that are inter-related,
interdependent.
I am saying, that IPv6 should support Diffserv in its entirety, and not
just pieces, and that is independent of the Carpenter/Conta proposal.
>
> If you wish to change the IETF standards process to add the requirement
> that IETF w.g. must support every other IETF standard (or perhaps that they
> must support Diffserv), then the POISED w.g. is the place to propose it.
>
As already stated, not every other, but inter-dependent. I think you
understood
what I meant. Poised may be an option, but would have to check more on
the
definition of the process, since I am not an expert on that.
> I think you are going a bit far to suggest that the fate of Diffserv
> depends on what the IPv6 w.g. does with the flow label field. I suspect
> that Diffserv will live or die based on IPv4 usage. Also, as IPv6 is
> deployed much of it will be initially carried over IPv4. Any QoS solution
> that is going to be end-to-end will have to deal with a mix of native IPv6
> and IPv4/IPv6 headers.
>
> Bob
I am particularly concerned, and the proposal refers to that, about
access networks,
where, the address space is IPv6, i.e. before tunneling over IPv4.
Alex
S/MIME Cryptographic Signature
