Re: Issues around sponsoring individual documents

[Martin Duerst <[e-mail]>]

At 09:44 07/09/07, Lisa Dusseault wrote:
>
>The Applications area does not have a lot of attendees or WGs (I  
>oversee five, and of those five, three are within a document or two  
>of closing).  Much of the current work is being done as individual  
>submissions (abbreviated IS in this email) [0].  I'd like to get some  
>input on how IS's should be handled.  I have many opinions on IS  
>tradeoffs, having written several and sponsored more, but I'm trying  
>to phrase these questions without entirely presupposing my own  
>answers, and to reflect conflicted opinions and the criticisms I've  
>heard.

I think the main case for IS is that there is less overhead.
There are cases where something started as an IS, but there was
controversy, so a WG was founded (LTRU, which I'm co-chairing).
Without controversy, it wouldn't have needed a WG, because two
predecessor documents (RFC 1766 and RFC 3066) were done as ISes.


>(BTW, I'm sure I can follow the advice of "Use your judgement" if  
>anybody decides to say that, but it doesn't really inform that  
>judgement does it?  )
>
>Is an IS that defines a new protocol for the Standards Track fine in  
>general?

Protocol is a very wide term. Something major like mail, HTTP, Atom, Jabber,...
most probably no, but there are minor protocols that could easily
be done by IS.

>Is an IS that extends a standard protocol developed in a WG fine in  
>general?

In most cases, yes. One of the goals of good protocol design is to
make this possible. Things are often done on the mailing list of the
former WG, or are done even while the WG is still around, but
preferring to work on the main pieces, and not taking on a draft
because they think it's uncontroversial and can be done as an IS.

>Is an IS that obsoletes a standard protocol developed in a WG fine in  
>general?

If that protocol is dead anyway, it will be difficult to find a WG
chair and WG members,...

I think there is another question that you may want to pose here:
Is an IS that moves a Proposed/Draft Standard developed in a WG
fine in general?

And I would say yes to that question. The URI spec is definitely
a good example.

>Do IS's suffer from less review?  Is that a problem?

Some probably do. But there are very thin WGs, and there are WGs
with lots of members but rarely anybody reading a document.
More review is always better, but never easy to get.

>Whose responsibility is it to get sufficient review?

Mostly the author's.

>Is it mostly well-connected individuals that can use the IS track,  
>knowing an AD to do the sponsoring?  Or mostly individuals with a lot  
>of time on their hands?

Time is needed both for WG drafts and for individual drafts.
Connections are good, but they serve more to reduce the inhibition
threshold. The first and foremost thing you need as an IS sumbmitter
is to know that this can actually be done, and that happens mostly
through connections.

>An IS can have a non-AD document shepherd.  Does encouraging that  
>improve the situation or make IS publishing even more dependent on  
>the author's connections?

I think it's a good idea. It can definitely take off some load
from the AD.
But it may not always work out, or not always the same way.
For draft-duerst-archived-at, the main thing that my shepheard
did was to submit it as an IS when I didn't have the time to do so.
After that, he wasn't reachable by email for a while.

>Should I limit time spent sponsoring IS's? [1]  IESG work plus IS  
>work could consume 30 hours a week, or 40, or 50...

You definitely have to be careful with your load! I'm not sure
why you say "IESG work plus IS work", after all, ISes also go
for IESG approval. I'd written "WG work and IS work".

The Application Area had lots more WGs a few years ago. You may
scare off a few people by telling them that you won't accept
a draft unless it comes through a WG, but you may then just
get more WGs. Other Areas have some semi-standing WGs for
extensions and updates and other ongoing work. We could have
a "standing Email WG" and a "standing HTTP WG" and so on,
but I don't think that would decrease your workload or
would significantly improve the quality of what's now
published via ISes.

>Assuming I limit the potentially endless amount of work devoted to  
>IS's, do I limit it algorithmically (e.g. first come first served),   
>as a matter of pure taste, or other?
>How should I prioritize IS sponsoring work? Which documents get my  
>attention first?  [2]

I think a major point is weeding out stuff that's not yet ready
or doesn't really fit in your area, and so on.

>When there's a question of consensus for an IS document, should I  
>just drop the document?

That very much depends on the nature of the stuff, and the
nature of the non-consensus.

>Assuming I try to determine consensus how do I do so without an  
>official owning WG -- consensus calls to the IETF discuss list?

There is a Last Call anyway, so I would only use the IETF list
in very special situations.

>Choose a related list and hope people are paying attention?

Related lists are definitely a good thing. If there is no
related list, that may be a sign that it doesn't belong in
the IETF. But you shouldn't have to do that. The submitter
(or shepherd) should come to you and give you pointers to
discussions on such lists that already took place.

>Do I need to ensure there's a quorum?

There are no quora for WGs, so why would there be for ISes?
I think one good check I'd use is whether there was discussion.
In many ways, discussion with some degree of disagreement is
better than no discussion, because it shows you that people
have read the document, and have thought things through and
hashed them out.

>How would appeals against IS documents affect answers to these  
>issues? (Usually individual ADs take the first stab at handling  
>appeals, formal or informal, against WG chair decisions.  When  
>there's no WG chair involved with a doc, I guess the appeal would go  
>straight to the whole IESG...)

If it smells like appeals, it definitely smells like WG.

>Does sponsoring many IS documents give an AD, and the IESG as a  
>whole, too much power?

I don't think so. People can always complain during IETF Last Call,
and if something is controversial, it will need a WG.
Having ISes as a ligthweight process is a great advantage
of the IETF, even if for you personally, ISes are more work
than WG drafts.

>Are we discouraging legitimate WGs by encouraging IS's?

There is a wide spectrum where you can have it both ways.
Which way you want it is mostly your call (and Chris',
unless you are ready to have 10 WGs and don't mind if
he only has 5 :-).

>What other purposes do WG's serve besides simply publishing  
>documents, that are not met by IS's? [3]

Besides what you say below, I think WGs are crucial for document
suites. I don't think something like e.g. the series of documents
currently being worked on by EAI could be handled as ISes.

>If we turned down ISs in Apps, would the proposed work die, go  
>elsewhere or ... ?  Would that be bad?

If you think it belongs elsewhere, you should turn it down.
Although I think you as an AD can sponsor just about any IS,
I'd use "does it fall into the IETF work area" and "does it
fall into the Application Area" as main criteria.

Regards,    Martin.s

>Lisa
>
>[0] Note "Independent Submission" is a different thing, an I-D that  
>goes through the RFC Editor to RFC and never gets an IETF last call,  
>so it's marked as not an IETF document
>
>[1] So far I have been sponsoring nearly every document I'm asked to,  
>not really limiting.  However I can see time limiting becoming required.
>
>[2] My current practice is to do WG-related work first, then IS- sponsoring work in rotation.  Note that with WG-related work, the WG  
>chair does some work which I have to do with IS documents. IS  
>documents are usually more work for me than WG products.
>
>[3] I'll take a first stab at this one:
>  - creating buy-in among potential implementors,
>  - developing relationships that can lead to more interop work than  
>otherwise,
>  - choosing document editors that can reflect or build consensus,  
>strongarm them if necessary
>
>
>
>
>
>
>


#-#-#  Martin J. Du"rst, Assoc. Professor, Aoyama Gakuin University
#-#-#  http://www.sw.it.aoyama.ac.jp       mailto:[e-mail]