Re: Issues around sponsoring individual documents

[Lars Eggert <[e-mail]>]

Hi, John,

On 2007-9-10, at 17:57, ext John C Klensin wrote:
> --On Monday, September 10, 2007 2:17 PM +0300 Lars Eggert  
> <[e-mail]> wrote:
>> you've gotten a lot of good feedback already. My viewpoint
>> differs a bit, in that I'm more hesitant about the widespread
>> use of the IS path. An IS should be a rare exception, with the
>> much more well-defined and -tested WG process the rule.
>
> Lars, I have to disagree, unless the WG process can be made both a  
> lot more efficient and a lot lower noise.   See my earlier note  
> about this and please understand that the Apps area may be more  
> subject to the noise factor than other areas... for several  
> reasons, some good and some bad.

I do agree that because APP produces standards that tend to get wider  
exposure outside the IETF, it's a tricky area, and progressing work  
can take a lot of effort. (TSV is comfortable wedged between INT and  
APP, so we are are a bit more sheltered.)

>> Because people see the IS path as a shortcut - and even worse,
>> an "insider" shortcut -  the more you let them take it, the
>> more requests you will get in the future.
>
> Well, some of us don't see it primarily as a shortcut (although  
> sometimes it might be) but as a more efficient way to get some  
> kinds of work done.

Being flippant for a second, let's all use this more efficient way to  
get work done then! There is a tragedy-of-the-commons effect here -  
the IS procedure is only powerful if used sparingly, because  
otherwise the benefits go away. I completely agree with you that for  
important work that needs to happen on an aggressive timeline and is  
not controversial, it is a valid option that makes a lot of sense.  
But it comes at a price, namely, taking up a LOT more AD cycles than  
WG documents do.

For special work items, IS is the right thing to do. But not everyone  
can be special.  One rule of thumb that I've used in the past is "is  
this document as important as 3-5 WG documents?" Because that's my  
totally subjective measure of how much additional effort it takes. If  
the proponents asking for IS have a convincing answer, well, good.

>> But in general, I'd encourage you to tell people to publish
>> their documents through the appropriate working group, and if
>> there isn't one, tell them to prepare a BOF.
>
> Which, under most circumstances, immediately adds at least four to  
> six months to the process without, in most cases, getting any  
> incremental work done.  It also tends to open up discussions about  
> what problem should be solved.  That is extremely useful in some  
> cases and a total waste of time in others, but the length of time  
> it takes seems to be independent of value.
>
> As costs rise and industry pressure for timely results increases,  
> "go spend an extra six (or more) months organizing a WG and then  
> take twice the time a WG should take, not due to tying down details  
> but with trying to deal fairly with irrelevant noise" is going to  
> be increasingly equivalent to "take that work outside the IETF".    
> I don't think an IETF effort should take one day less time than it  
> takes to get things right (separating me from some folks who favor  
> "accept the tolerably good as long as it is timely") but I don't  
> think it should take one week longer, either.  I don't think that  
> convincing people to go elsewhere is a desirable outcome.  That is  
> especially true when the issue at hand is revision/ advancement of  
> existing IETF standards, where we know who most of the experts are,  
> have mailing lists on which to "advertise" for participants, have  
> constraints about what changes can be made, and really don't need  
> to spend WG time reopening old issues.

I'm all for streamlining the WG process, but that's a different  
discussion. IS lets you bypass some of the delays associated with  
having a WG, which makes it attractive, but the AD pays that cost in  
terms of cycles. That model doesn't scale.

>> WGs have existed
>> to only work on one or two documents (PMTUD, for example). WGs
>> come with chairs and they come with an established management
>> process, both of which reduce your workload (even more so with
>> PROTO).
>
> Having been an AD, although long ago, and watched the process for  
> years, I question that generality of this assertion too. Sometimes  
> they do, sometimes they don't.

Yes, I shouldn't have generalized this. But at least for me  
personally, the benefits of having shepherds and a well-defined  
process reduce the workload.

>> PS: Another alternative to IS is something like TSVWG (and now
>> OPSAWG) to work in a more open fashion on documents and topics
>> that maybe don't warrant their own WG.
>
> Sure.  But it is not clear to me that those groups really force the  
> kind of topic-specific expert review that we assume that we get  
> from "ordinary" WGs.  If they do, that is fine.  But, if they  
> don't, we may delude ourselves by then using a shortcut community  
> review process that is inappropriate to those groups.

Oh, yes, having these catch-all WGs doesn't much help with getting  
documents adequately reviewed. It does help with the management  
aspect though.

> With the diversity of Apps such groups tend to be particularly  
> inappropriate (been there, tried that).  We have tried, or at least  
> discussed, a number of other alternatives to "pure" individual  
> submission handling in Apps.  I've shared some of these with Lisa.   
> They include special open directorate review meetings (perhaps more  
> like SAAG than like TSVWG, but I'm not sure any more), extending  
> the Apps Area review process (which seems to work well), open  
> review sessions at IETF meetings (tried once with IDNAbis and  
> something I would recommend based on that experience) and generally  
> holding independent submission authors and advocates responsible  
> for demonstrating that adequate review has occurred.

It may well be that a catch-all WG is the wrong model for APP. It's  
not a spectacular success in TSV, either, but it's better than any  
other alternative we though of. I only brought it up to bring it to  
Lisa's attention as an option to consider.

Lars