Re: Uneccesary slowness.

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> This is a very good example of the approach that many folks have taken, in
> thinking about these problems.  It is really pretty amazing, given the nature
> and history of this community.  It is not immodest to assert that we are a
> community of relatively self-actualized participants, with a considerable
> history of solving difficult protocol (process) problems.  Yet in the matter
> of solving serious deficiencies in our organizational processes, we shrug and
> give up, rather than look for changes that solve the bottlenecks, improve
> quality and retain the underlying culture of the original IETF process.

> For example, as you note, the IESG approves working groups and working group
> charters.  So the IESG does, in fact, have the ability to control the later
> demand placed on it.

Well, sort of. For one thing, note your own use of the word "later". The IESG
that creates a WG is often not the one that ends up having to deal with its
output.

Second, in the apps area at least, we have in fact seen a dramatic reduction
of the number of WGs. I just checked, and when I left the IESG there 
were 25 apps area groups. This number is now down to 14. And while there
are obviously lots of other factors, close to a factor of 2 reduction in the
number of groups should have had some effect. Have you noticed any?

> Another example is the kind of mission creep that John Klensin noted.  The
> IESG review is supposed to be for some vary narrow purposes, but the scope has
> greatly expanded.

I'm afraid I have to agree with this assessment, and I think it causes
timeliness problems, although I confess that I do not have empirical evidence
to support this belief.

> >  A policy that creates an expectation that an individual submission will
> >  be published and receive the implicit endorsement of IETF (disclaimers
> >  to the contrary notwithstanding), taking up resources from the RFC
> >  Editor and/or IESG, is even sillier.  Or at best anachronistic.

> Many of these problems derive from the IESG believing that it is solely
> capable of being responsible for doing all the reviews for all documents. The
> official scope of the IESG review of non standards-track individual
> submissions is supposed to be pretty darned limited.

All this assumes that there are in fact lots of fairly problematic individual
submissions for the IESG to deal with. (I think those of us who have been there
all agree that these are the documents that are far and away the most costly in
terms of time.) Checking the datatracker for the two apps ADs, I didn't find
any documents I would say qualified. Indeed, the number of truly individual
submissions (as opposed to submissions that happen to be under someone's name
but are in fact closely related to longstanding IETF activities, such as moves
to draft) seems to be pretty low.

I therefore have to question whether we are talking about the actual factors
that are _currently_ creating delays.

				Ned

_______________________________________________

Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]