--On Saturday, July 16, 2011 16:03 -0400 Ronald Bonica
<rbonica@xxxxxxxxxxx> 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@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