My thoughts about the problems of the IETF

[John C Klensin]

--On Monday, 21 April, 2003 08:32 -0700 Dave Crocker 
<dhc at dcrocker.net> wrote:

>> Margaret,
>>     perhaps we need an
>> explicit criterion on all standards-track RFCs that are
>> candidates for advancement that says "this document must
>> be clear enough that it is precisely obvious to anyone
>> skilled in the area what needs to be tested for
>> interoperability".

> I agree with the sentiment and the suggestion, except for a
> concern about the pragmatics.
>
> Requiring a specification to delineate its points of
> interoperability places the burden on the right people, and
> permits the burden to be satisfied *during* the working group
> process, rather than having it pop up as a show-stopper at the
> end of the process.
>
> The two problems that seem likely are :  1) too much
> bureaucracy in the creation of specifications and 2) to much
> difficulty in providing the interoperability detail for
> "sophisticated" (that is, large and/or complicated)
> specifications.

Dave, we are in agreement about this.  And, as always, I suggest 
that some room for rational flexibility (subject to appeal) has 
got to be an important element of almost anything we devise, 
this included.  But, while I share you concern about the 
pragmatics, the alternates seem to lead to late-stage 
disagreements about what is and is not required and, worse, 
disagreements into which the WG participants and development 
process has little input.   Put differently, if providing the 
interoperability detail is too complex for the relevant WG, then 
we are leaving that decision-making up to the wisdom (or, if one 
is paranoid, whim) of one AD, which seems less desirable.

But that difficulty does create a potential for some 
process-tuning.  If we think it is a problem, then we might give 
WGs, in consultation with the relevant ADs or the IESG as a 
whole, a choice:

	* Include the interoperability statement that will apply
	at maturity level X+1 in the document at maturity level
	X.
	
	* Create that statement as part of the later process of
	getting to X+1

That distinction may be particularly important for Proposed 
Standards, since there has been much discussion to the effect 
that adding more burdens to getting those out is, itself, a 
problem.  But expecting an explicit consensus on what is, and is 
not, required to be demonstrated as interoperable before 
something advances to Draft would seem to be appropriate.

I also note, fwiw, that almost any step in the direction of 
being more explicit about interoperability requirements moves us 
back toward the notion of explicit conformance statements such 
as those we had with the MAY/SHOULD/MUST definitions of RFC 
1122/1123 and away from the "this is really, sort of, probably 
not required to make things work well" definitions of RFC 2119.

    john