Pete, et al, On 8/22/2013 7:22 AM, Pete Resnick wrote:
So, now at the point of IETF LC, the correct thing to happen is to let folks make their objections, point them to places in the prior conversation where the WG, the chairs, the ADs, and assorted other folks became convinced, and see if their arguments have some new subtlety that was missed earlier. And try to explain. Remember, these folks are already at a disadvantage; they've got an uphill climb to convince anyone else (especially, me and the rest of the IESG) that this long-considered conclusion is incorrect. IMO, that's the time to cut them as much slack as possible, because if they do have a serious objection hidden in among things that we've seen before, we *all* should want to hear it.
...
So, now at the point of IETF LC, the correct thing to happen is to let folks make their objections, point them to places in the prior conversation where the WG, the chairs, the ADs, and assorted other folks became convinced, and see if their arguments have some new subtlety that was missed earlier. And try to explain.
That's certainly a kind and gentle view of the obligations for handling LC comments. Kind and gentle on the folks making the comments. Not so kind or gentle or useful on the folks who have been spending months (or years) doing the work of developing the document. Therefore, I'm going to posit that your model is, in fact, critically flawed. (And on review I see there's an apt pun in that wording...) In pragmatic terms, the current operational model for a LC (and IESG) review tends to enforce no rules or limits to what can be challenged or suggested, while simultaneously expecting those who have been doing the work to then be responsible for educating the commenter and defending decisions in the document, at the level of re-arguing resolved issues. Your admonition that "these folks are already at a disadvantage" encourages this sense of obligation. However this is direct contradiction to our published rules for Last Call: RFC 2418, Working Group Guidelines and Procedures Section 8, Review of documents "It is important to note that a Last-Call is intended as a brief, final check with the Internet community, to make sure that no important concerns have been missed or misunderstood. The Last-Call should not serve as a more general, in-depth review." Note that last sentence. It's the essential point, if we are to have any real /respect/ for the extended effort already put into developing the document. It contrasts completely from the burden that is regularly placed on such folk these days. In other words, those making comments have obligations too, but that is not being discussed here, except to make excuses for them. And it is the fundamental flaw with your line of thinking. In practical terms, that thinking suggests that rather than treat it as a joke, we take seriously and tolerate behavior matching the cliche "I haven't read the spec, but I have some criticisms of your work." Besides mostly being incredibly wasteful, to the point of abuse, your model serves as its own disincentive for bringing work to the IETF; the hassle factor is just too damn high and, worse, the outcome too damn unpredictable. For all that we tout the occasional bit of added insight -- and I'm entirely in favor of those rare moments -- they are drowned out by the more predictable and dominant demands to re-explore old topics or new silly ones or to argue religious technical preferences.
But that's not what's gone on. Some folks have simply dismissively said, "Go read the archive", without pointers.
Last Call is for catching oversights and errors. It is not for educating folk who chose not to track the working group. If someone cares enough to press for specific choices, they need to show up when the work is being done. If they don't care that much, then I'm sorry but "we discussed that" or "go read the archives" is in fact an entirely sufficient and complete response. That is, if the IETF has any real respect for the work that was done developing the document. [For completeness, I'll note that this is an issue where it makes sense to handle Individual Submissions quite differently. Here there is no archive of IETF group work, and so it is reasonable to demand of the authors a handling of Last Call comments that really does look more like education and marketing. But not for working group documents.]
The dismissiveness AFAICT simply encourages people to post more comments without looking at the previous conversation. But your note went above and beyond. The sarcasm was sharp and directed. It seemed intent on ridiculing.
That's quite a lot to lay onto my brief "very constructive" statement. Which isn't to say you are wrong; although the intensity of your reaction really goes considerably beyond the worth of such a single, brief comment, particularly one lacking an explicitly ad hominem component and especially given that it really was in response to a strikingly inappropriate and unconstructive demand. But let's look at the specifics of the current situation. Comments during last call can come from folk who either have or lack knowledge about the IETF and/or the document's topic. The comments can be exploratory, in the sense of seriously seeking improvement, or they can be pushing the speaker's agenda, with no concern other than for winning their point. That last is typically marked by a lack of responsiveness to points of substance, along with an effort to look for any line of attack that might win. In all cases, of course, starting with moderated and serious responses is appropriate. And, of course, one would always wish that that continues. However, by and large, all of the comments to the SPFbis effort have been either naive, or represented an agenda, or both. And in this case that prompted my sarcasm, we had a highly knowledgeable critic refraining from serious discussion and, instead, pressing a very old and sustained and counter-productive agenda about DNS RRs. And he did it through several iterations. In other words, it was a religious effort, not a technical exploration, jumping around to find any line of attack that would prevent deprecating a patently useless RR (and one, in fact, that has been deemed to create an interoperability problem.) My sarcasm was prompted by the degree of disrespect and silliness in that final suggestion. From a highly experienced IETF participant.
And coming from someone who is already on the side of the called consensus (the side that "has already won", though I dislike that formulation)
You /should/ dislike it, because it entirely misses the style of attack against the work that is quite common during LC. And since it is by now easy to forget my earlier statement, I'll repeat that I am entirely in favor of LC and the constructive comments that do get made there. I am not criticizing the construct of LC but rather the unreasonable demands on document creators that result from LCs' current lack of limits on critics. LC should not be treated as a right of passage, to test the patience of folks who have developed a document. It should be exactly what RFC 2418 says it should be. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net