Hi John,
I think that most of the rancor around RFCs 3056 and 3068 is due to RFC 2026's
very terse definition of HISTORIC. According to RFC 2026, "A specification that
has been superseded by a more recent specification or is for any other reason
considered to be obsolete is assigned to the Historic level." That's the entire
definition. Anything more is read into it.
Granted, the phrase "for any other reason considered to be obsolete" is pretty
subjective. In this thread, I have seen people interpret that phrase as follows:
"the IETF thinks that there are no longer any valid use cases for this
technology"
"the IETF recommends that you remove this technology from your network"
"the IETF believes that nobody is using this technology"
I doubt if any of these interpretations are valid, because the IETF is not in a
good position to evaluate what is in use or tell an operator how to run a
network. A more likely interpretation is as follows:
"the IETF is not likely to invest effort in the technology in the future"
"the IETF does not encourage (or discourage) new deployments of this technology.
Ron
-----Original Message-----
From: ietf-bounces(_at_)ietf(_dot_)org
[mailto:ietf-bounces(_at_)ietf(_dot_)org] On Behalf Of
Joel Jaeggli
Sent: Friday, July 15, 2011 3:17 PM
To: John C Klensin
Cc: v6ops(_at_)ietf(_dot_)org; IETF Discussion
Subject: Re: Another look at 6to4 (and other IPv6 transition issues)
On Jul 15, 2011, at 11:52 AM, John C Klensin wrote:
--On Friday, July 15, 2011 09:40 -0700 Joel Jaeggli
<joelja(_at_)bogus(_dot_)com> 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.
And there are people that disagree with you on that.
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.
<SNIP>
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.
You missed the boat about a decade back I guess. Transition
technologies (none of them) are a substitute for actual deployment.
They should naturally decline in popularity and in fact in the portions
of the internet where we can measure them they are. Right now if we try
and fit a story to the evidence that is happening because of host
changes, and not because of deployment. ipv4 is becoming less usable
and it's taking autotunnels with it, nobody here has a proposal that
changes that.
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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf