--On Friday, July 15, 2011 09:40 -0700 Joel Jaeggli
<joelja@xxxxxxxxx> wrote:
> So the rational for the advice document not being combined
> with the standards action in it is that the later has some
> polarizing impact, the advice document does not. the advice
> document is through and done, historic is not.
Joel (and others),
I understand the rationale. At the risk of repeating myself, I
simply do not think it works or is appropriate. Recategorizing
set of documents as "Historic" is an extremely blunt instrument.
If we do it in a consistent and logical fashion, the advice
document would have to go to Historic along with the base
documents because giving advice about a piece of ancient history
is meaningless. That is not what most people who like the
advice document intended, at least as I understood the consensus
on that Last Call.
Worse, for those who are successfully operating 6to4 and finding
it useful, reclassifying the specifications to Historic sends a
clear message that, from their perspective at least, the IETF is
clueless (since "Historic" essentially says the thing is useless
and/or that no one is using it... and they know better because
they are a counterexample). The consequence of that, in turn,
is that they either simply ignore the advice or conclude that
they should postpone IPv6 deployment until the IETF gives advice
that is both coherent and believable.
I think there are probably a dozen "right" ways to do this, with
the differences depending on issues that I haven't followed
v6ops or 6to4 deployment closely enough to have opinions about.
What they have in common is a real analysis of issues and some
meaningful recommendations ("-advice" seems to do much of that)
and the used of "updates" to effectively incorporate that advice
and guidance into the base spec. If that is better done with a
standalone document that references the base spec and the advice
document, updating all of them, I'm fine with it (although,
under that scenario, I'd prefer to have the advice document on
standards track).
Finally, if we had a wonderful transition model that would work
well in all situations, then it would make sense to recommend it
and depreciate everything else. We don't. What we have are a
bunch of mechanisms, each with advantages and disadvantages,
some much better adapted to particular situations than others.
It would be easier if we had a good single solution, but we
don't... that is life, or at least engineering. Given that, we
serve the community much better with analyses and explanations
of tradeoffs (and RFC 6180 is, IMO, a really good start) than we
do by going through exercises of figuring out what to denounce.
IMO, the _only_ thing we should be categorically denouncing are
tactics and strategies that encourage people to put off getting
serious about IPv6. Unfortunately, trying to slap a "Historic"
label on one particular transition strategy, or to rank
transition strategies that have proven useful to some actors on
the basis of how much various of us loathe them, are about
denunciation and, however unintentionally, with the risk of
encouraging people to sit and wait, not about progress or
network engineering.
back to lurking...
john
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf