Re: [Icar] ICAR draft charter

Eric Rosen <erosen@cisco.com> Tue, 13 January 2004 15:46 UTC

Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19994 for <icar-archive@odin.ietf.org>; Tue, 13 Jan 2004 10:46:51 -0500 (EST)
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgQkK-0002F9-MW for icar-archive@odin.ietf.org; Tue, 13 Jan 2004 10:46:24 -0500
Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id i0DFkOAK008617 for icar-archive@odin.ietf.org; Tue, 13 Jan 2004 10:46:24 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgQkK-0002Ep-84 for icar-web-archive@optimus.ietf.org; Tue, 13 Jan 2004 10:46:24 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19982 for <icar-web-archive@ietf.org>; Tue, 13 Jan 2004 10:46:20 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgQkH-0007Jk-00 for icar-web-archive@ietf.org; Tue, 13 Jan 2004 10:46:21 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgQiQ-0007HY-00 for icar-web-archive@ietf.org; Tue, 13 Jan 2004 10:44:26 -0500
Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AgQh2-0007F3-00 for icar-web-archive@ietf.org; Tue, 13 Jan 2004 10:43:00 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgQh3-0002AS-9V; Tue, 13 Jan 2004 10:43:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AgQgK-00029U-Nc for icar@optimus.ietf.org; Tue, 13 Jan 2004 10:42:16 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA19790 for <icar@ietf.org>; Tue, 13 Jan 2004 10:42:13 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AgQgI-0007CX-00 for icar@ietf.org; Tue, 13 Jan 2004 10:42:14 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AgQeT-0007A3-00 for icar@ietf.org; Tue, 13 Jan 2004 10:40:22 -0500
Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx with esmtp (Exim 4.12) id 1AgQcy-00072u-00 for icar@ietf.org; Tue, 13 Jan 2004 10:38:48 -0500
Received: from cisco.com (erosen-u10.cisco.com [161.44.70.36]) by rtp-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id i0DFcDLE029186; Tue, 13 Jan 2004 10:38:13 -0500 (EST)
Message-Id: <200401131538.i0DFcDLE029186@rtp-core-1.cisco.com>
To: Alex Zinin <zinin@psg.com>
cc: icar@ietf.org
Subject: Re: [Icar] ICAR draft charter
In-reply-to: Your message of Wed, 07 Jan 2004 12:25:03 -0800. <1044648133.20040107122503@psg.com>
Reply-To: erosen@cisco.com
User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.3 (sparc-sun-solaris2.8) MULE/5.0 (SAKAKI)
MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya")
Content-Type: text/plain; charset=US-ASCII
Date: Tue, 13 Jan 2004 10:38:12 -0500
From: Eric Rosen <erosen@cisco.com>
Sender: icar-admin@ietf.org
Errors-To: icar-admin@ietf.org
X-BeenThere: icar@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/icar>, <mailto:icar-request@ietf.org?subject=unsubscribe>
List-Id: Improved Cross-Area Review <icar.ietf.org>
List-Post: <mailto:icar@ietf.org>
List-Help: <mailto:icar-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/icar>, <mailto:icar-request@ietf.org?subject=subscribe>
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=none autolearn=no version=2.60

I think the charter's fine.  

Whether  the group  will  actually achieve  something  is another  question.
Getting early cross-functional  review is a great idea,  at least in theory,
but in practice I have the following concerns: 

- While  I would welcome an APPs  guy's perspective on how  a routing change
  might impact APPs,  I don't necessarily want the APPs  guys telling me how
  to do routing.  For cross-functional review to be effective, the reviewers
  and  reviewees must  respect each  others' knowledge  in  their respective
  areas of expertise. 

  In the absence of this mutual respect, the whole thing is just an exercise
  in politics.

- If one really  wants to  know, e.g.,  how a  security change  will impact
  routing, it might  take a security guy and a  routing guy working together
  to figure  out all the  inter-relationships.  That's a bit  different than
  throwing the spec over the wall for someone in another field to review. 

- Everybody will  want to  see the  trade-offs  made in  such a  way as  to
  create the simplest result their own area.  This will lead it irresolvable
  conflicts (as we  frequently see on the main IETF list).   It is also easy
  to demand that other areas do things  that are beyond the state of the art
  in that area. 

I  look   forward  to  seeing   what  can  be   done  to  ensure   that  the
cross-functional review doesn't become counter-productive. 





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