--On Friday, 24 June, 2011 16:10 -0700 james woodyatt
<jhw@xxxxxxxxx> wrote:
> On Jun 24, 2011, at 09:08 , John C Klensin wrote:
>>
>> What I saw was what appeared to me to be some fairly strong
>> arguments for looking at the problem in a different way -- a
>> way that I've seen no evidence the WG considered at all.
>> That would be to explore alternatives to the rather blunt
>...
> That's not how it appeared to me when I was participating the
> WG discussions and WG last call. What I remember was that we
> had two drafts, the first, 6to4-advisory, aimed to do exactly
> what Mr. Klensin describes, and the second, 6to4-to-history,
> aimed at giving operators an excuse not to read the advisory,
> because hey-- 6to4 is history now. The working group
> considered the option of publishing one and not the other.
> That evaluation seemed to me to come to an end when the author
> of 6to4-advisory came out in support of publishing both
> documents.
First. as I've told that author at more length privately, I
disagree with that decision as, apparently, do many others. As
others have pointed out, it sends a very confusing message to
someone who doesn't know the WG history, is reading the RFCs in
isolation, and isn't doing so carefully. Fortunately or
unfortunately, that is a pretty good description of the typical
reader of RFCs, as least in my experience/observation.
As I told Brian, if the intent is to deliver a clear "we think
you REALLY REALLY SHOULD NOT (a term that is not quite in 2119)
use this, but, if you do anyway, take this advice", then you do
that in one document that explains both. When you publish the
advice document and simultaneously publish a document that can
be read as saying "never mind, this, including the advice, is
all ancient history and you should pay no attention to it", you
are just being confusing. IMO, that is largely independent of
whether you also move everything to Historic except that the
formal Historic classification just adds to the confusion.
Now that opinion obviously disagrees with that of the WG. My
hypothesis is that the WG just got too close to the problem to
see the issue from the casual reader of RFCs who doesn't have a
long history with debates about the issue. And, as others have
said, I believe that IETF LC is designed to identify exactly
that problem. In matters of technical expertise, I believe the
IESG should balance WG opinion and IETF opinion very carefully,
giving great (but certainly not absolute) weight to issues that
the WG considered carefully and reached a conclusion about.
But when the evaluation is about whether the document is clear
to an expert who did not participate in the WG or whether it
sends a clear message, then I believe the opinions of those
outside the WG, without the history and shared understanding,
should absolutely predominate. And I hope that, if you think
about it for a while, that reasoning will be clear.
> In the WG discussions leading to the adoption of both drafts
> as work items, I supported 6to4-advisory and strenuously
> argued against taking up 6to4-to-historic. When it became
> clear that I was on the losing side of that argument, and that
> WG consensus for publishing *both* would be achieved during
> LC, I analyzed my own reasons for opposing the
> 6to4-to-historic draft and concluded that I didn't really care
> that much if 6to4-to-historic were published, because the
> draft is clearly written to specify something other than what
> its authors and most of the WG were intending.
And, if IETF Last Call had pointed out, really clearly, that the
intent of "...historic" was different from what the WG intended,
would you expect the IESG to follow the WG's intent or the text
of the document? That is actually a serious question. If I
were IESG, I'd argue strongly for punting both documents back to
the WG at that point and say "figure out what you really want
and mean and express it clearly and consistently in one
document". But I'm no on the IESG and know that I'm taking
advantage of not having to deal with possible consequences and
side-effects of such a move.
> The WG consensus is to throw 6to4 into the historic trash bin.
> The draft, however, doesn't do that. It just tells the IETF
> to stop worrying and learn to love the bomb, while all the
> vendors of 6to4-capable equipment keep on keeping on with
> exactly what they're doing today. I could live with that, and
> I said so. Nobody seemed to care about it, but the
> observation *was* on the table.
Yes. And??? (see above)
> I see that some of those in the opposition to 6to4-to-historic
> do not agree with me that the draft is utterly harmless and
> will be roundly ignored by industry. To the extent that I can
> see how 6to4-to-historic may divert its intended audience from
> reading the much more important 6to4-advisory draft, I
> sympathize, but I don't see that argument moving too many
> minds. I had kinda hoped that IESG would put a stop to this
> nonsense and kick the draft back to the WG with instructions
> to develop a phase-out plan for 6to4. Alas, that didn't
> happen. Oh well.
With one major exception, I think that puts us pretty much on
the same page, including with some small disappointment at the
IESG for not telling the WG to do its job. The exception is
that I believe that every authoritative-sounding document that
is published in the IETF Stream and then ignored by industry
strikes a blow against IETF's overall credibility and that those
blows, however small, are cumulatively damaging.
>...
And, from your later note but very much to the same point...
> But no, it looks like 6to4 tunnel-router mode will be going
> into the same bucket as wired equivalent privacy (WEP), i.e. a
> technology that everyone knows is obsolete, and would like to
> see go away forever, but nobody wants to buy the phase-out
> plan for it, and so it will continue to be ubiquitous and kept
> in support forever.
In addition, WEP, and the process that created it, are routinely
held up outside that group as the product of a clueless
standards body that probably understood radios but that
exhibited a complete lack of clue where encryption was
concerned. That may be an unfair rap, or may not be, but, as
far as good reputations are concerned, it is bad news...
john
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf