--On Friday, 24 June, 2011 12:57 -0700 Doug Barton <dougb@xxxxxxxxxxxxx> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf