Re: Cost vs. Benefit of Real-Time Applications and Infrastucture Area

David Kessens <david.kessens@nokia.com> Wed, 21 September 2005 05:25 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHx6r-0003yg-Pj; Wed, 21 Sep 2005 01:25:33 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHx6o-0003yV-Uk for ietf@megatron.ietf.org; Wed, 21 Sep 2005 01:25:31 -0400
Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA28628 for <ietf@ietf.org>; Wed, 21 Sep 2005 01:25:30 -0400 (EDT)
Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHxCm-00062w-Qh for ietf@ietf.org; Wed, 21 Sep 2005 01:31:41 -0400
Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8L5ODoA027608; Wed, 21 Sep 2005 08:24:13 +0300
Received: from esebh001.NOE.Nokia.com ([172.21.138.28]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Sep 2005 08:25:24 +0300
Received: from dadhcp-172019068136.americas.nokia.com ([10.241.58.151]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Wed, 21 Sep 2005 08:25:23 +0300
Received: from dadhcp-172019068136.americas.nokia.com (localhost.localdomain [127.0.0.1]) by dadhcp-172019068136.americas.nokia.com (8.12.11/8.12.11) with ESMTP id j8L5PWnR009406; Tue, 20 Sep 2005 22:25:32 -0700
Received: (from david@localhost) by dadhcp-172019068136.americas.nokia.com (8.12.11/8.12.11/Submit) id j8L5PPxF009405; Tue, 20 Sep 2005 22:25:25 -0700
Date: Tue, 20 Sep 2005 22:25:24 -0700
From: David Kessens <david.kessens@nokia.com>
To: Lakshminath Dondeti <ldondeti@qualcomm.com>
Message-ID: <20050921052524.GI6496@nokia.com>
References: <20050921000225.GD6496@nokia.com> <6.2.2.1.2.20050920172353.02ef5ea0@qcmail1.qualcomm.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <6.2.2.1.2.20050920172353.02ef5ea0@qcmail1.qualcomm.com>
User-Agent: Mutt/1.4.1i
X-OriginalArrivalTime: 21 Sep 2005 05:25:23.0929 (UTC) FILETIME=[DDF1E490:01C5BE6C]
X-Spam-Score: 0.0 (/)
X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d
Cc: ietf@ietf.org
Subject: Re: Cost vs. Benefit of Real-Time Applications and Infrastucture Area
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
Sender: ietf-bounces@ietf.org
Errors-To: ietf-bounces@ietf.org

Lakshminath,

On Tue, Sep 20, 2005 at 05:45:27PM -0700, Lakshminath Dondeti wrote:
> Ok, I'll bite :-).  I for one, think it is a good idea to have the 
> additional area and this is inline with my support of additional ADs for 
> areas that have a large number of drafts in waiting.  I consider this more 
> than "nice to have"; it is essential IMO and a natural way of areas being 
> formed and "deleted" from the IETF.  Now, if only we can find an area to 
> delete: SEC anyone ;-).  Just kidding, of course.

I would have a lot less trouble with the proposal of adding an area if
we would be able to find another one that could be abolished, or
reorganize ourselves in some way or form that would result in no net
addition of Area Directors.

Just like a company that has limited resources available, I would very
much prefer to keep a constant number of ADs (or actually even less
than our current number) and allocate the resources where we need them
most, instead of keeping to throw more resources at the problem.
Although we don't have money changing hands, there still is a real
cost of adding such resources and we should be very careful that we
don't ignore these costs.

> In addition to that, the argument made to me was that some topics didn't 
> quite belong in the APPS area or the TRANSPORT area.  So there were meeting 
> scheduling conflicts and the like as a result of that.

I hope that we have more effective ways to deal with scheduling
conflicts than adding an area.

> >However, there are also many costs associated with this proposal,
> >among others:
> >
> >- we need two more people out of the community who are going to spend
> >  a lot of their time on the administrative side of our organization
> >  instead of producing real work for the IETF.
> 
> Unless the work increases due to the formation of the new area, the flip 
> side is that we have 2 people doing 4 people's work.

The latter is true, unfortunately, I believe that the first part of
this statement is also true (though obviously, the workload increase
will be felt more in the areas that are not able to move working
groups to the new area).

> >- the nomcom will need to do more work to appoint more ADs.
> 
> I wish you said this last year :-) with all the IAOC work we had to do (I 
> am on the outgoing Nomcom).  Frankly, I would have found it easier to 
> select two more people with technical expertise than two with 
> administration type of expertise -- there are only a few of those in the 
> IETF and they are already active in ISOC activities and are now pulling 
> double duty (actually triple, considering they all want to be active in the 
> technical side of things as well).

;-). Thanks for doing this work. Serving on the nomcom is a lot of
hard work with very low payout.

> On the points below, I can't argue with you.  Perhaps a more hierarchical 
> structure is needed or perhaps only a subset of the IESG (randomly picked 
> or voluntary+assignment based allotment might reduce the number of people) 
> needs to review documents and discuss them.  Anyway, I don't have the 
> insight to discuss IESG operation (people say you have to be in it to know) 
> :-).  If IESG review is what's substituting for cross-area review, we need 
> to fix that.

Feel free to comment on IESG operations ;-). While it helps to be on
the IESG to understand it's workings, it is also very useful to have
people taking a fresh look at our operating procedures. And as you can
see from the postings by various ADs, we have our own diverse views on
our own role and how the IESG should operate too.

David Kessens
---

_______________________________________________
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf