--On Friday, 24 June, 2011 12:57 -0700 Doug Barton
<dougb(_at_)dougbarton(_dot_)us> 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
instrument of making a protocol specification historic:
explaining what needs to be done to get it right (your
document does a lot of that) and then figuring out ways to
warn against the uses and configurations that we all (or
mostly) agree are bad news.
By "your document" above are you referring to Brian's
http://tools.ietf.org/html/draft-ietf-v6ops-6to4-advisory ?
yes
If
so I would argue that the extensive WG discussion about both
documents meets your criteria. Taken together the 2 documents
represent a series of compromises between those of us whose
opinion is "Kill 6to4 dead, yesterday" and those who would
like to give it as graceful an exit as possible.
Doug, you have just returned to the main point of Paul's
question. Let me state it in a different way. WGs who produce
drafts on a given issue tend to be made of folks who are heavily
concerned with that issue and who share similar perspectives on
it (that doesn't mean they agree on the answers, but they often
agree on the problem to be solved). To even a much greater
degree than a decade or two ago, they also tend to be pretty
homogeneous (again, that doesn't mean they necessarily agree).
The reason we do IETF Last Calls is in order to bring community
perspective to bear, to consider things both cross-area and
cross-perspective and, if a WG has gotten over-focused on one
set of issues and ignored others, to create an opportunity to
bring the others out.
Now, the IESG gets to listen to all of those opinions, both WG
and non-WG, and say (in an extreme case) "the WG has engaged on
all the issues and has it right and the rest of the community,
no matter how numerous, doesn't have adequate understanding and
should be ignored". This is supposed to be a process that
brings different technical perspectives out if they exist, not a
popularity contest. I don't have any problem with that; I'm not
even clear that Paul does.
_However_ if something causes as much controversy as this did, I
think it is desirable for the IESG to be cautious in at least
two ways. One is to examine whether it is worth sending the
draft back to the WG, saying "please review these points once
again and make sure you don't want to modify your
recommendation". As far as I know, they did that... or
consulted with the WG leadership and concluded that the WG
position was sufficiently hardened that no amount of re-review
would make an difference. Second, I think the IESG has some
implicit obligation to really document such a decision and the
reasons for it, not [just] to issue a Protocol Action notice
that can be easily construed the way several people on this list
have construed it, i.e., as "well the WG and the community input
disagreed, so screw the community".
Personally, I don't believe that was the basis on which the IESG
made the decisions they made but, as is often the case in this
community, a little more explicitness and transparency about how
and why controversial decisions were made can head off a lot of
problems.
FWIW, if people actually believe that the IESG has gotten too
high-handed or dismissive of community input, I note that the
Nomcom Chair is looking for volunteers and will soon be looking
for input.
The
"historic" document points out the reasons that doing it at
all is probably a bad idea, and asks that it be off by
default; while the "advisory" document tells people that want
to to do it anyway how to do it right. Personally I was very
satisfied with both products of the WG and taken as a whole I
think they describe a very rational approach.
And, if you will go back and read my comments on the subject,
you will find that I, personally, largely agree. I just don't
think that adding "historic" to those pieces of advice will be
influential in accomplishing the goals, that it is a too-blunt
instrument, and its application in this sort of situation is
more likely to bring discredit on the IETF than to accomplish
the purpose for which its advocates are encouraging it. I
believe I'm probably in the minority on that position and
recognize that I'm not likely to persuade anyone who isn't
persuaded already. It certainly isn't the first time that has
happened and I have no particular problem with it.
But I do think that this is a situation in which a more nuanced
approach is appropriate (which is what my earlier note said) and
for more explanation from the IESG about the reasoning behind
their conclusion (which this one addresses).
I will now go back to lurking.
john
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf