ietf
[Top] [All Lists]

Re: Voting (again)

2005-04-27 07:43:16


Keith Moore wrote:
I wasn't advocating for more ADs, but for more 'virtual' ADs, i.e., to
move the work of reviewing out of the ADs, and let the ADs distrbute the
reviews and collect and interpret the results.


This is _more_ work for the ADs, not less, because the ADs have to
read the reviews in addition to the documents. 

That argues that there should be no PCs, only PC chairs, which isn't the
case.

The only way to releive work is to distribute it, not concentrate it.
The exceptions to this are based on expertise - and I don't buy that for
AD slots. There are too many non-expertise issues in their appointment.

You might ask why the ADs'
reviews are better than the virtual ADs' reviews. It's not inherently
the case, of course, but the "real" ADs will be exposed to more
information that informs such reviews, and the "real" ADs are in a
better position to work out technical compromises that helps keep
different protocols from fighting with one another. (for instance,
keeping linklocal addressing or site-local addressing from doing harm to
application-level interoperability).

ADs often don't have the time to track all the WGs and can end up
holding docs unnecessarily as a result. And they're not uniquely privvy
to the concept of compromise or negotiation; their "power" should come
from technical expertise, which is distributed in the IETF, not from
fiat (I didn't see white smoke from the Nomcom).


What you are advocating would help if the majority of documents
presented to IESG were not close to being acceptable for standards
track.  But that's not the case.  The majority of documents are
close to being acceptable - maybe 10% are not close.  But it can
take a lot of work for those documents that are "close" to be made
acceptable.  Some of the work required to craft technical
compromises could perhaps be offloaded to virtual ADs.  And when
you have truly non-controversial documents that don't require
cross-area review you can offload those reviews.  But the IESG
still needs to know what is in the document before it can make a
determination as to whether cross-area review is necessary, and you
can't really ask (say) a layer 3 person to make a determination as
to whether this protocol will affect layer 7 concerns -
particularly when layer 7 concerns are so diverse.

ADs are not the only ones who can look or work at mutliple layers; in
fact, their focus works against them in many cases in this regard.

And there are PLENTY of docs that need review that aren't standards
track that the IESG is just plain holding up.

There's also the problem of how to provide incentives for those
virtual ADs.

Ditto for PC members. Being a member is the incentive; the IETF is a
volunteer organization. If you can find a dozen or so people to stop
what they're doing and be ADs, you can certainly find more people who
will participate if they can do so at a lower level of commitment.

The Apps area had a directorate for many years with the
idea that some reviews could be offloaded to the directorate. It didn't
work very well, because those people were busy too, and it was hard to
find people who could reliably turn around a review of a difficult
document in time for the IESG telechat. They could (and did!) review the
short/easy/noncontroversial documents, but there aren't that many of
them, and they're not the ones that take up all of an AD's time.

OK, so we have ONE example where it didn't work. Let's throw it out. ;-)

The issue with "directorates" is that they turn into papal conclaves (to
reuse the allusion). They need to be more open, but they can work fine.

(Aside: I really do think that a limit on the number of documents, 
and a page limit on normative technical specifications, might go a
long way toward lessening AD workload and also helping WGs produce
well-written specifications. But there would need to be some way of
making exceptions, as there will be a few documents that really do
need to be long.)

Page limits are fine, but won't lessen the work, just the chunksize.

2. if the work being done has too much effort on the wrong tasks, it does 
not 
help things to have more people doing the wrong things.

I agree on this; IMO, if the ADs spend too much time reviewing, then
that's self-correcting - review less. I've never understood the 'review'
portion of this; I do understand the coordination with the IETF, but the
review is supposed to happen at the lower levels inside the WGs.

In my entire time in IETF, it's never worked that way. Nor can I
understand how it could work that way and produce reasonable output. WGs
are too focused on their immediate goals to think about the wider impact
of their work, and they tend to interpret difficult technical
requirements in such a way as to make them seem conveniently irrelevant.
It's easier to ignore problems than to solve them; it's easier to design
a protocol that only works in a limited set of conditions than to design
one that works on the global Internet.

While I can't speak for all WGs, I can speak for the ones I participate
in more heavily, and they certainly never operate that myopically. What
DOES happen is that we solicit cross-area review, or send authors to
other WGs to present docs before the IESG review.

Then the IESG says "did you take this to X?" - when we had years
earlier. The excuse was basically "we can't track EVERYTHING".  Sadly,
this is exactly the thing you expect ADs to fix, and IMO it's they are
problem in this regard, not the solution.

The other issue is more of "hey, *I* have a technical problem with this
doc", regardless of whether it has already had cross-area review and
consensus. In which case we end up trying to appease the AD to sate
their personal perspective, not the IETF or the Internet as a whole, and
often at the expense (not to the credit) of the broad vision of the
global Internet.

Joe

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
<Prev in Thread] Current Thread [Next in Thread>