ambiguous documents (was: Re: My thoughts about the problems of the IETF)

John C Klensin john-ietf at jck.com
Mon Apr 21 13:13:08 CEST 2003



--On Monday, 21 April, 2003 08:54 -0700 James Kempf 
<kempf at docomolabs-usa.com> wrote:

> The potential for the KRE decision to be interpreted as more
> wide ranging than it was intended, which I interpret to be
> your concern, was discussed and the wording of the decision
> was phrased to explicitly rule out that possibility. The
> decision was intended to just apply to the particular case at
> hand. I believe it is important for people to understand that
> it was not intended to be an open-ended invitation for anyone
> to file an appeal every time some point was unclear to them in
> a draft approved by the IESG.

James,

I'm not personally concerned about that, I just wanted to try to 
ensure we all had a shared understanding of the situation.

>From my perspective, if it were claimed that the IESG was 
permitting unclear/ ambiguous documents, or documents that 
seemed to deliberately cover up (rather than resolving or 
identifying) disagreements, to go forward onto the standards 
track, that would be a problem that we should be noting.  And 
that problem, were it to exist, has only one remedy mechanism in 
the current structure, which is an appeal.   If we don't like 
that remedy, than it should go on the problem list so that we 
can figure something else out.

Whether we have enough unclear/ ambiguous documents going 
forward to justify any work in this area --i.e., whether it is a 
problem that is worth spending time on-- is, of course, another 
question.  I suggest that the IAB decision, however narrow, 
identified one such case.  I think I have seen a few others. 
But it is also important, IMO, to preserve the ability of the 
IESG to say "this is good enough for Proposed" (and even 
encourage them to make that judgment more often), rather than 
getting early-maturity documents involved in time-consuming 
nit-picking of details that may turn out to be unimportant.

     john




More information about the Problem-statement mailing list