IETF mission (RE: pausable explanation for the Document Series)

[Ralph Droms]

Regarding Brian's call for radical thinking...

Is the problem:

   the 3 step standards track is largely fictional

the root problem or just a symptom?  

I think it's just a symptom of a mismatch among industry
uses for IETF standards, WG processes and IESG goals.

The current *usage* of the standards track effectively
has a single hurdle at PS.  I suggest we need to devise
a process and set of hurdles that include some intermediate
states that are not well-defined in the current usage
of the standards track.

One of the important states that is missing today is

   stable specification used for prototyping

My recent experience with specifications in the dhc WG
has been that "running (prototype) code" trumps
(potentially ad infinitum) speculative discussion about
whether the protocol is correct and completely
specified.  

The design problem, of course, is devising the right
document classifications and process to strike a balance
among nimbleness (getting to a stable specification
quickly), correctness and allowing for changes after
the prototypes have been developed (avoiding the
"we've deployed the prototype and now we can't change
the protocol" problem)...

- Ralph

At 01:50 PM 6/6/2003 +0200, Brian E Carpenter wrote:
>john.loughney at nokia.com wrote:
>> 
>> Hi Charles,
>> 
>> > I also wholeheartedly support the inclusion of an applicability
>> > statement whenever it makes sense.  However, I also suggest that
>> > the protocol SHOULD (within engineering discretion) not intentionally
>> > restrict its applcability to the situations delineated in the
>> > applicability statement.
>> >
>> > I would restate Postel's maxim:
>> >
>> > Be conservative in the claimed applicability, but generous
>> > in the potential applicability.
>> 
>> What I am concerned about is there seems to be a movement to
>> make a super-PS, one which would be the equavalent of a DS
>> & have no bugs.  I am not sure of the feasibility of this,
>> but I have noticed that simple protocol documents are getting
>> overloaded with a lot of applicability info, deployment concerns,
>> best practices and implementation guides.  Somehow, I think
>> overloading a single document with this info, is not a
>> reciepe for success.
>
>In any case, since we don't actually use the complexity we
>already have (3 grades of standard), the need is clearly to
>*simplify* the document scheme, not to complicate it. My thinking
>is getting more radical the longer this discussion continues. Let's
>think seriously about
>
> Problem: the 3 step standards track is largely fictional
>
>and possible solutions along the lines of
>
> Solution: let's scrap it and have all "standards" RFCs as a single level
> (with recycling in grade for corrections/updates).
>
>   Brian