Log in

No account? Create an account

IESG, Consensus and Community Interaction

A while back I commented on concerns about the ISD proposals expressed by the IESG. We've created yet another stir by declining a request to assign an IANA codepoint. I was responsible for the most controversial part of that decision: we went beyond declining the request and actually recommended against bringing the request for IETF review. The reason was simple. We think we know the parties involved well enough to know that the proposal will not be received favorably. We don't think spending years reviewing the proposal and ultimately deciding against will be in anyone's interest.

Putting it mildly, some people are upset. There are a lot of reasons; here I'm going to focus on people who are upset because we made a specific recommendation. What puzzles me is that some of these people would have been happier if we had withheld our belief that the review effort would be a waste of time. It seems misleading to withheld this information: the requester might well assume that we were supportive of the request but just wanted broader review. Such an impression would create great frustration when years later after review, the request was declined. There's an impression that by expressing an opinion, the IESG will not fairly follow the process should the community try to take a different course. Some seem unwilling to believe that if the requester did actually want IETF review the IESG would follow a fair process in seeking that review. I can understand the idea that if the IESG has a strong opinion it might get in the way of fair process. However that's true regardless of whether we actually express the opinion. It seems important to express such opinions; it seems important not to give people the false impression that they should spend a lot of time on a proposal without giving them realistic estimation of their chances of success. We need to find a way to do that without causing those who decide to go against our recommendation to feel that we are being unfair.

Another current frustration is the idea that the IESG is not part of the community. Particularly on process issues, some have expressed the opinion that when looking for consensus the IESG should be discounted. That seems dangerous: you don't want to exclude the opinion of a reasonably large subset of the people active in working with the standards process when deciding how that process should work. Besides leading to bad solutions, it is personally frustrating to be told that no, you aren't worth listening to. I realize it comes with the job. That doesn't mean I have to like it.



I suspect the big uproar is caused not by the expression of the opinion, but by the recommendation. If the IESG had said, the proper way is to form a working group, making sure to interface with working groups X, Y, and Z; and then point out that in the IESG's opinion, the working group would suffer from the following challenges since the proposal as written would break existing implementations, blah, blah, blah, it probably wouldn't have caused a stir.

From reading the IETF list, the indignation seems to come from the issuance of the recommendation. Many programmers are fundamentally fundamentalist libertarians, to the point of being 5-year old children. They object mightly to be told "don't touch the hot stove", and may try to touch the hot stove if you in fact try to tell them not to for their own good. But if you say, "go ahead a touch the stove if you want, but be warned that it's hot", then they will sometimes respond more rationally.
We considered telling people that while they could touch the stove that they might not want to because it would burn them. The problem is that this quickly becomes "The IESG approves of us touching the stove; we just have to solve this small problem of it being hot." Then a few years later, "Hey! The IETF is useless! You told us to go touch the stove and then after we spent years wouldn't let us do it because we couldn't figure out how not to get burned."

Perhaps we need to work on phrasing like "You can touch the stove if you insist, although we recommend against it because the burning problem needs to be solved and we don't think you can do that." In this specific instance, I think it might have been better if we had done more of a technical review up front. However that takes time and getting bogged down doing detailed technical reviews of pre-WG proposals is not ideal.

Often I've seen IESG members (and WG chairs, and IAB members) go well out of their way to emphasize that they are speaking "hatless" at a meeting (likely due to the next issue). Between this, and the concern that many people have over a "conflict of interest" if the people who finally approve a document can contribute to it (see the recent LEMONADE threads), its not surprising that there exists the idea that the IESG is not a part of the community.

Personally, the attitude seems sort of childish to me.