Robert Elz wrote:
>
> Date: Thu, 23 Aug 2001 20:52:00 -0400
> From: Alex Conta <[EMAIL PROTECTED]>
> Message-ID: <[EMAIL PROTECTED]>
>
> To be even less politically correct ...
>
> | The IPv6 WG is not a preferential club, or an exclusivist group. The
> | IPv6 WG is not to tell the IETF what standard is good and what standard
> | is bad.
>
> That is true, but
>
> | While the IPv6 WG develops IPv6, IT MUST ENSURE that IPv6 works
> | with, and it supports the other IETF standards.
>
> that is simple nonsense.
>
> There are all kinds of IETF standards around - a proportion of them are
> utter crap. In general, that is no problem - the vast majority of the
> rubbish that is proposed, worked on, and then progressed can simply be
> ignored - I know it is never going to affect me, because I am going to
> ignore it forever.
>
> But, if you're trying to tell us all that we have to go look at every IETF
> standard (and by that I assume you mean PS and up, as there aren't actually
> all that many full standards) and make sure that they are supported by IPv6,
> then you're way off base.
You know well, I was directly referring to QoS support for IP, i.e.
network layer protocols.
As you know that there are standards to which my statements applies. You
do not have to go to an extreme.
However, you seem to contradict yourself - you said earlier "that is
true".
Anyway, standards are in general made because people need or want them.
Some may look bad for one, or for a group. But they're good standards as
long as they help people that need them.
>
> Rather, if there are people who actually care about the other work, and need
> it to be supported, and they don't think it is, then they need to come to
> ipngwg (or whatever the name is this week) and argue for it. Make a persuasive
> case for some proposal, and whatever support is needed & possible is likely
> to appear. On the other hand, if ipngwg doesn't accept your request, then
> tough.
>
> Up to this point, exactly the right thing had been happening here, with the
> request, and the debate (with no clear decision yet that I could make out).
>
You are in fact POLITICALLY VERY CORRECT.
I am not.
To have a group of people, within a WG, decide to support with one of
the protocol functions, (flow label), only one QoS standard, and not the
other QoS standard, just shows me how the process can go wrong.
> But attempting to tell the WG that our hands are tied because some other
> WG claims to need some feature or other is way off base. The equivalent
> would be if ipngwg sent a message to diffserv saying that they had to make
> things work with nothing more than a random number, addresses, and
> encrypted payload, because that's all they're getting - after all, IPv6
> is a much more mature standard than diffserv. By your reasoning, diffserv
> would be compelled to support IPv6 that way.
>
That is nonsense.
It is not just "some feature". There is no equivalence. The flow label
part is not
mature - you ignore RFC 2460 itself. Furthermore, "random number" is not
part of the
standard, and rightly so.
> I actually treat this message as a concession that there are no strong
> enough arguments that can be made to ipngwg that would cause model (c)
> for the flow label to be adopted.
>
> kre
There is no concession at all.
It brings things in perspective: getting bogged down in details blurs
the essence, the very simple principle.
IPv6 supports QoS. IPv6 supports currently Intserv, but it support ONLY
a subset of Diffserv: BA.
We need to add the same level of support for Diffserv. That does not
affect any of the current support
of Intserv.
To have to argue at such a length for the full support of Diffserv, to
have to argue for adding the same level of support as it is provided for
Intserv, is surrealist, is absurd.
S/MIME Cryptographic Signature
