--On Saturday, July 16, 2011 16:03 -0400 Ronald Bonica
<rbonica(_at_)juniper(_dot_)net> wrote:
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.
If you include a certain amount of oral tradition that predates
and surrounds 2026 in "read into it", I agree. It may be worth
remembering that 2026, like most similar documents, didn't
invent anything but was intended to reflect a community
consensus that existed about what should be done. Documents
like 2026 never capture that consensus exactly or
comprehensively. Whether that informal consensus means anything
once we write something down is a question that we rarely ask
ourselves, probably for good reason.
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.
I think the first interpretation can be valid although it must
be used with great caution. For example, I think we might all
agree that there are no remaining valid use cases for NCP,
despite the fact that TCP/IP could be argued to have replaced it
rather than precisely superceding it. Another, perhaps better,
example is that Novell IPX is almost certainly dead
("proprietary protocol abandoned by its owner" is a pretty good
predictor of "no valid use cases"). We wouldn't think using it
for anything in a contemporary network would be useful even if,
e.g., it has better scaling properties. Interestingly, while
RFC 1234 and 1553 were were moved to Historic, we have one Full
Standard (RFC 1123, STD 49), an Informational document (RFC
1634), a Proposed Standard (RFC 1420), and a some Experimental
documents (RFC 1791, RFC 1792). That pretty much covers the
whole range of possibilities.
If I didn't have the view that housekeeping exercises that
require community review and consensus were usually a poor use
of resources (see other note today), getting this whole pack
swept into Historic on the "no valid remaining use cases"
principle would be entirely appropriate. One could still not
prove that no one is using it: I have every reason to believe
that someone out there is still running Netware and happy about
it.
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.
Noting in passing that these sorts of statements are quite close
to the uses 2026 prescribes for Applicability Statements (and
for which we have even more precedent and oral tradition), if
the first of those is an adequate reason for identifying
something as historic, I recommend that we immediately move RFC
791 to Historic. Certainly we are likely to invest more effort
in the development of the technology. Now, some people would
read such a move as either an indication, as you suggest above,
that the IETF thought no one was using it any more, or that
there were no remaining valid use cases, etc., immediately
turning us into a laughingstock. But, by logic that suggests
moving 6to4 to Historic on the grounds that the IETF is not
going to invest effort in the technology.
So I think we disagree.
best,
john
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