RE: Possible new Real-Time Applications and Infrastucture (RAI) Area

I'm of conflicting thoughts about this. On one hand, more Ads could
have more opportunity to do more hands-on work with working groups, etc.
This would be a good thing, and could potentially help WGs to progress
drafts through WGs faster.

On the other hand, 2 more ADs means two more potential DISCUSSes and
more Ads spending time on document reviews.  I'm not sure if what the
IETF needs is more Ads to review the documents and file DISCUSSes.

If there was a way to lighten-up the IESG review process, then this
would be
a good idea. For example, having a single DISCUSS per Area would be one
way
to reduce this could be one solution. 

In summary, I think that expanding the IESG would only be a good idea
only 
if we could adjust the IESG review load / process so that we are not
just
expanding the number of potential DISCUSSes.

thanks,
John

>-----Original Message-----
>From: ietf-announce-bounces@ietf.org 
>[mailto:ietf-announce-bounces@ietf.org] On Behalf Of ext IETF Chair
>Sent: 16 September, 2005 16:14
>To: IETF Announcement list
>Subject: Possible new Real-Time Applications and Infrastucture 
>(RAI) Area 
>
>As mentioned in the recent call for NomCom volunteers, the 
>IESG is considering the creation of a new area, as set out 
>below.  We solicit feedback from the community on the scope of 
>this potential new area as well as the impact on the IETF's 
>infrastructure and efficiency of setting up this new area. We 
>need to decide quite quickly, to fit the NomCom schedule.
>
>Please write to iesg@ietf.org, or to ietf@ietf.org if you want 
>community discussion of your comment. (There's no need to 
>write to both!)
>
>   Brian Carpenter
>
>-----------------
>
>Real-Time Applications and Infrastucture (RAI) Area Description
>
>The Real-Time Applications and Infrastructure Area develops 
>protocols and architectures for delay-sensitive interpersonal 
>communications. Work in this area serves an emerging industry 
>whose applications and services include voice and video over 
>IP, instant messaging and presence. These applications and 
>services are "real-time" in the sense that delay impedes human 
>participation in the associated systems.
>
>The RAI Area is seeded with existing working groups from the 
>Transport and Applications Area: SIP, SIPPING, XCON, SIMPLE, 
>GEOPRIV, ECRIT, ENUM, IPTEL, MEGACO, MMUSIC, IEPREP, SPEECHSC, 
>and SIGTRAN.  A good rule of thumb for the incorporation of 
>new work into RAI, as opposed to Transport or Applications, is 
>that the work in question has major goals supporting instant 
>interpersonal communication or its infrastructure.
>For example, they can range from applications to help users 
>make decisions about how best to communicate using presence 
>services, to session signaling protocols and emergency call 
>routing solutions, to work on the "layer five" issues for 
>Internet telephony.
>
>Like all areas of the IETF, the RAI Area draws on the work of 
>numerous other areas, and as such there can be no neat 
>mathematical boundaries delineating RAI's work from the rest 
>of the IETF. The new area will allow an existing community 
>within the IETF to solidify its vision and to benefit from 
>increased institutional support.
>
>_______________________________________________
>IETF-Announce mailing list
>IETF-Announce@ietf.org
>https://www1.ietf.org/mailman/listinfo/ietf-announce
>

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