"Adult supervision"

[Pete Resnick]

As Charlie said before:

>It will be better to not exaggerate positions.

On 5/7/03 at 11:16 AM -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. We're not talking about a group of people who don't 
understand, we're talking about a group of people who *refuse* to do 
what they know is the right thing (for whatever motives). And we have 
enough of these groups that detailed explanations would have to be 
repeated *more than 4 times*.

Keith, like Charlie, I would suggest that the sort of hyperbole 
represented by your statement above (and of course my statement 
above) does nothing to move this conversation forward. If any of the 
above were really true, the game is over and we might as well all go 
home.

More likely what is actually true is that we have a large number of 
working groups with a large number of new participants (and even 
leaders) who do not understand bigger picture constraints on their 
solution space. And (as Edward pointed out in another message) if you 
want to take seriously the characterization of these less experienced 
folks as needing "adult supervision", then I would suggest that it is 
squarely the fault of the adults that they do not convey the 
appropriate messages to the children in a way that the children can 
understand.

Characterizing the actions of these working groups as conscious 
malice doesn't help, anymore than it helps to characterize the inane 
quips, terse replies, and authoritarian-sounding pronouncements from 
some ADs as malicious. 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? I'm really getting quite tired of the other 
interpretation, and I really think it needs to stop.

>>>usually this isn't something that would kill working group 
>>>efforts, it's something that the working group should be doing in 
>>>order to fulfill 2026 requirements for standards-track document 
>>>quality, but refuses to do.
>>
>>Then it's documented in RFC 2026.
>
>not in detail.  2026 says "no known technical omissions".

It says "no known technical omissions *with respect to the 
requirements placed upon it.*"

>the detail says that (for example) "failure to provide 
>authentication is a technical omission" or "failure to interoperate 
>with the global Internet is a technical omission". you'd think 
>things like this would be obvious, but groups will insist that they 
>aren't.

Uh, sorry, but 2026 doesn't say that and, as far as I can interpret, 
doesn't intend that. The paragraph in question says:

    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." That is, you can't require something in a Proposed 
Standard and then not provide it. The IESG waiver was put in there to 
allow incomplete specifications like (at the time) IPv6 because 
deployment was seen as more important than finishing all of the 
technical details. I cannot imagine an IESG waiver granted under any 
circumstances for any document that does not provide authentication 
where the document has a requirement for authentication, and 
therefore cannot imagine that it is the sort of thing that was in 
mind as a "technical omission with respect to the requirements placed 
upon it." Maybe you have it in mind that all documents (perhaps 
implicitly) have an authentication requirement or have an 
"interoperate with the global Internet" requirement, but I think I 
can come up with multiple examples of good Proposed Standards that do 
not have one of those requirements, and they aren't "necessary".

pr
-- 
Pete Resnick <mailto:presnick at qualcomm.com>
QUALCOMM Incorporated