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@xxxxxxxx [mailto:ietf-bounces@xxxxxxxx] On Behalf Of
> Joel Jaeggli
> Sent: Friday, July 15, 2011 3:17 PM
> To: John C Klensin
> Cc: v6ops@xxxxxxxx; 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@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.
>
> 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@xxxxxxxx
> https://www.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf