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

Lakshminath Dondeti <ldondeti@qualcomm.com> Wed, 21 September 2005 00:45 UTC

Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHskH-0001Pi-Ei; Tue, 20 Sep 2005 20:45:57 -0400
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHskE-0001OR-HJ for ietf@megatron.ietf.org; Tue, 20 Sep 2005 20:45:54 -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 UAA17385 for <ietf@ietf.org>; Tue, 20 Sep 2005 20:45:52 -0400 (EDT)
Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHsq4-00006Q-WD for ietf@ietf.org; Tue, 20 Sep 2005 20:51:59 -0400
Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8L0jVtC000858 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 20 Sep 2005 17:45:31 -0700 (PDT)
Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.100]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8L0jTkN016847 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 20 Sep 2005 17:45:29 -0700 (PDT)
Message-Id: <6.2.2.1.2.20050920172353.02ef5ea0@qcmail1.qualcomm.com>
X-Mailer: QUALCOMM Windows Eudora Version 6.2.2.1
Date: Tue, 20 Sep 2005 17:45:27 -0700
To: David Kessens <david.kessens@nokia.com>, ietf@ietf.org
From: Lakshminath Dondeti <ldondeti@qualcomm.com>
In-Reply-To: <20050921000225.GD6496@nokia.com>
References: <20050921000225.GD6496@nokia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format="flowed"
X-Spam-Score: 0.0 (/)
X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1
Cc:
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

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.

At 05:02 PM 9/20/2005, David Kessens wrote:

>I am very worried about the discussion on the new proposed area.
>Most mails are along the line that it sounds "nice" to have a new area
>formed.
>
>Forming a new area comes at a cost for the IETF, while there are also
>potential benefits. I believe it is very important for the community
>to consider and understand the costs versus the benefits for the
>creation of a new area.
>
>As for the benefits, I see that we would give more well deserved
>attention to an important area of work within the IETF. In addition,
>it should help to alleviate overload within the transport area.

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.


>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 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).


>- IETF documents will receive more scrutiny in the IESG. While this
>   could be considered a good thing, there has been a significant
>   amount of backlash in the community that enough is enough. I for one
>   believe that we currently already provide enough review, and possibly
>   already too much.

I am not sure.  I have been somewhat active in other SDOs and my take is 
that they seem to look to the IETF for thoroughly reviewed documents.  Sure 
they want things done quickly, but I don't think the suggestion is to move 
things along even if documents are in bad shape.

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.

Anyway I like that a new area is being formed to properly divide the work.

cheers,
Lakshminath

>
>- Management research has shown that optimal group sizes are in
>   general quite a bit smaller than the current IESG. In fact, I see
>   already significant strains within the IESG due to our group size.
>   For example, we have a hard time to find a time, date and location
>   for our retreats that work for all of our members. The definition of
>   "A hard time" is that we spend significant amount of time trying to
>   find a date and time that works for all of us. Other examples in
>   terms of meetings where we all have to attend is a conference call
>   regarding an appeal. We spend time on checking out who is actually
>   present during an IESG call. We have issues with conference calls
>   where somebody causes an echo on the conference system. The more
>   people attend, the more time it takes to debug the problem. We send
>   mail among each other, the more members we have the more mail we
>   will receive and the more time we will need to read and respond to
>   IESG internal mails. The more we specialize the function of areas,
>   the more inter-area coordination will be needed. We have discussions
>   about drafts and many other issues during the telechats, the more
>   people we have the more time we will spend on these discussions.
>
>   Adding two more ADs has the potential to make this quite a bit worse
>   as our group size is already in the territory of too large to
>   operate efficiently. Two more ADs will bring us yet another step
>   closer to the tipping point of where we will only be busy among
>   ourselves instead of serving the community.
>
>I guess it comes as no surprise that I have serious issues with this
>proposal.
>
>While the idea sounds nice, the operational details will cause us more
>pain than it provides benefits. An IESG that doesn't operate
>efficiently is not in the benefit of the IETF. I believe that many of
>the benefits of a new area can be had without adding a new area.
>Alternatives could be to create a special attention area towards Real
>Time Applications within the Application area with one of the two ADs
>in the Applications area specializing on such applications.
>
>Another approach could be to do serious surgery on how the IESG
>operates to make it a more scalable group.
>
>I believe it is very dangerous to add an area before addressing the
>issues associated with a larger IESG as it will get ever harder to
>make such changes while our group grows less efficient by piecemeal
>fixes instead of looking at the larger issue of how the IESG as a
>whole can become more efficient to the benefit of the IETF.
>
>David Kessens
>---
>
>
>_______________________________________________
>Ietf mailing list
>Ietf@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf


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