On Apr 15, 2013, at 7:45 AM, Brian E Carpenter
<brian(_dot_)e(_dot_)carpenter(_at_)gmail(_dot_)com>
wrote:
On 15/04/2013 15:23, Ted Lemon wrote:
...
So in practice, although I feel great sympathy for this position, I think
it's mistaken. I want the other ADs to comment on anything that they
notice that looks like a problem.
There's an important class of problem that can only be found by someone
who is *not* a specialist - that is to say wording that's perfectly
clear and unambiguous to someone very familiar with the topic, but is
quite unclear to someone who isn't. This matters because we (presumably)
want our specifications to be useful to people who are implementing or
deploying them without already being members of the inner circle.
Just to be specific, here is a piece of text that came out of a WG
not so long ago. I have bowdlerized it:
"The Foobar standards [RFCxxx], [RFCyyy] provide useful generic
functionality like blah, blah and blah for reducing the overhead in
Boofar networks. This functionality can be partly applied to Bleep."
That was it - a third party implementing Bleep was apparently supposed
to guess which bits of those RFCs applied where.
This led to a DISCUSS and seven months of delay before that "partly"
was disambiguated. Was that inappropriate out-of-area review?
No, it was not. But I would argue that "seven months" in an IESG review was too
long. At some point, the responsible AD should have written a set of questions
and sent it back to whatever working group it came from with "don't send it
back until you have answered those questions". The ADs shouldn't have spent
their time trying to have the conversation; they should only have ensured that
they were OK with the result.
From the working group side, it would *also* have been helpful to have the AD
that raised the question get involved in the WG discussion, if only to ensure
that s/he was OK with the outcome when it came.