On Thu, Aug 22, 2013 at 11:12 PM, Dave Crocker <d...@dcrocker.net> wrote:
> 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. Remember the discussion about how "last call" is more like the middle of a document's evolution, and we should admit that in our process documentation? This is closely related. If, in reality, people are frustrated at the attempted rapid pace of last calls, then we should allow for that. We have time. We don't have to be like the ones we all know who sneer at anyone presuming to get in the way of their code going into production. Simple comments and questions -- your "educating everyone who tracked the wrong group" -- can be dealt with easily through referral. Even substantial ones can be directed to specific discussion threads. Real issues can be considered. It's only too late if we say it is, in our processes, and if an issue is substantial, it should never be too late.
