Re: [newtrk] In support of Larry's proposal

[John C Klensin <[e-mail]>]

--On Saturday, 06 August, 2005 09:23 -0400 Sam Hartman
<[e-mail]> wrote:

>>>>>> "John" == John C Klensin <[e-mail]> writes:
> 
>     John> certainly represents a lot of time: if we could avoid
>     John> documents entirely and do things by direct
> brain-to-brain     John> transfer between the originating WG
> and the final     John> standards-user, we would see a quicker
> process.  
> 
> This is undoubtably true.  However a lot of the effort is
> actually spent clearing up details of the proposal in the WG's
> mind and no efficiencies in dealing with the document would
> remove this effort. For example even if you understood what
> Larry wanted perfectly, you would still be left with a
> partially formed muddle.  The idea is just at that stage of
> development.

Of course, we are in complete agreement about this.

>     John> If we establish a firm norm that says, as I think
> Larry's     John> proposal does (the absence of something
> specific, in I-D     John> form, is a problem at this level of
> detail), that     John> specifications will normally advance
> from Proposed to Draft     John> when checkoff items are
> completed, rather than requiring     John> revision of the RFC
> text, that creates considerable     John> _additional_
> pressure on getting the text perfectly correct     John> at
> Proposed.  That is not, IMO, helpful.  Worse, it may not
> John> save any time in the overall process: it might just shift
>     John> more editorial work from pre-Draft to pre-Proposed.
> 
> I agree that this is a potential problem.  I am not sure that
> I would consider it a blocking problem especially for the
> experimental phase. However I'd invite you to think about ways
> of avoiding the problem; I will do the same.  Larry already
> has a mechanism to collect comments associated with testing
> events--things you needed to interpret in order to understand
> the spec, things that might require updating.  The question is
> how to combat a desire to get things perfect to avoid a round
> of revisions.  That is almost certainly going to be an attitude
> issue more than a process issue.  The process clearly will
> allow revision.

Agree about the attitude issue, but certain process models may
support bad attitudes and vice versa.  We also, as others have
pointed out, need to be careful that an IETF-sanctioned
interoperability report living document or checklist doesn't
back us into the various conformance testing --or at least
certification of testing suites/methods-- without our noticing.

    john

.
newtrk resources:_____________________________________________________
web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html
mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html