On Thu, Aug 22, 2013 at 11:12 PM, Dave Crocker <dhc@xxxxxxxxxxxx> 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.