"Adult supervision"

Pete Resnick presnick at qualcomm.com
Wed May 7 16:45:07 CEST 2003


On 5/7/03 at 2:17 PM -0400, Keith Moore wrote:

>>>working groups choose to be derailed. a working group that refuses 
>>>to understand the constraints on its solution space before 
>>>investing significant effort in a solution, has nobody to blame 
>>>but itself.
>>
>>OK, so we are now talking about working groups that act out of malice.
>
>I wouldn't call failure of a group to do the necessary background 
>work "malice"

The words used in the past few messages are not about "failure of a 
group", they are about "choices" of a group and "refusals" of a 
group. Would "willful negligence" be preferable to "malice"? It's 
still about a *willful* decision on the part of these people to 
disregard something important, or (as in the house-building metaphor) 
an act of such huge and obvious stupidity and ignorance that people 
involved should not be allowed near *any* project. I find all of this 
hyperbolic, accusatory, and certainly not constructive. Again, when 
viewed through the lens of "willful actions", some of the activity of 
ADs seems equally horrific. (Or to put more of a point on it if we 
allow ourselves to view all of this action as intentional, not only 
would we be justified in saying that working groups choose to be 
derailed and should be blamed, but we would be equally justified in 
saying that certain ADs are/have been arbitrary, capricious, and 
power happy.) Cutting back on this "intentional" language would go a 
long way toward civilizing this debate, on both sides.

>I certainly agree that we need to find ways to better communicate 
>big picture needs, since what we have is clearly not working well. 
>I suspect we'll have to get out of fire-fighting mode before we can 
>find time to do that, though.

Quite true.

>>Can you (and the rest of us) make an attempt to assume that working 
>>groups do these things out of a lack of understanding and guidance, 
>>and that ADs do these things out of frustration and overwork?
>
>This is very close to what I do assume, and I didn't indicate otherwise.

Whether or not you indicated this, if you *mean* this, your previous 
language is not conveying it.

Again, dialing back the language would be helpful along these lines.

>>      A Proposed Standard should have no known technical omissions with
>>      respect to the requirements placed upon it.  However, the IESG may
>>      waive this requirement in order to allow a specification to
>>      advance to the Proposed Standard state when it is considered to be
>>      useful and necessary (and timely) even with known technical
>>      omissions.
>>
>>I have always taken this to mean that a Proposed Standard can't say 
>>something like, "This protocol requires some way for the client and 
>>server to rendezvous. It is left for future development to figure 
>>out how to do that."
>
>I have always taken this to mean that a document that fails to 
>address any important technical concern does not qualify for 
>Proposed Standard.

If it meant that, then why bother with the whole paragraph? Why not 
simply say (as you always seem to misquote it) "A Proposed Standard 
should have no known technical omissions", full stop? Unless, as I 
asked before, you think that things like providing authentication and 
interoperating with the global Internet are universal and implicit 
"requirements" in all Proposed Standards. I think there is sufficient 
evidence to the contrary.

2026 provides different places for input. Stating the requirements 
comes at the beginning of the process, either through chartering or 
through writing and approval of a requirements document. Deciding 
whether a document has met those requirements is what comes at the 
end of the process. The quoted paragraph above is about the latter. I 
find your interpretation of the paragraph a reach at best, and 
certainly inconsistent with the context of it.

pr
-- 
Pete Resnick <mailto:presnick at qualcomm.com>
QUALCOMM Incorporated - Direct phone: (858)651-4478, Fax: (858)651-1102


More information about the Problem-statement mailing list