From exim@www1.ietf.org Tue Dec 9 19:27:15 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA26300 for ; Tue, 9 Dec 2003 19:27:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATsBy-0001sr-9x for icar-archive@odin.ietf.org; Tue, 09 Dec 2003 19:27:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBA0R2Ji007235 for icar-archive@odin.ietf.org; Tue, 9 Dec 2003 19:27:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATsBy-0001sc-5C for icar-web-archive@optimus.ietf.org; Tue, 09 Dec 2003 19:27:02 -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 TAA26292 for ; Tue, 9 Dec 2003 19:26:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATsBw-000501-00 for icar-web-archive@ietf.org; Tue, 09 Dec 2003 19:27:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1ATsBw-0004zw-00 for icar-web-archive@ietf.org; Tue, 09 Dec 2003 19:27:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATsBx-0001sN-2y; Tue, 09 Dec 2003 19:27:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1ATsBU-0001rp-9Y for icar@optimus.ietf.org; Tue, 09 Dec 2003 19:26:32 -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 TAA26274 for ; Tue, 9 Dec 2003 19:26:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1ATsBS-0004zI-00 for icar@ietf.org; Tue, 09 Dec 2003 19:26:30 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1ATsBS-0004zE-00 for icar@ietf.org; Tue, 09 Dec 2003 19:26:30 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1ATsBS-000041-Fz for icar@ietf.org; Wed, 10 Dec 2003 00:26:30 +0000 Date: Tue, 9 Dec 2003 16:25:50 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <5991801693.20031209162550@psg.com> To: icar@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Icar] Moving on with ICAR: WG formation and charter 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Folks- Steven Belovin and I will be taking care of the pre-WG discussion on ICAR for the IESG. Before we go any further, I would like to solicit feedback from the community on the following points: 1. Do you believe that a WG should be formed to work on improving IETF cross-functional review (see IESG message [Ref1] for more detail)? If so: 2. Would you be willing to actively participate in this WG (by contributing to or reviewing the documents, participating in the discussions, etc.)? 3. Please review the part in [Ref1] that provides a preliminary description of the WG and send your comments. The text in the message is likely to be used for the WG charter if there's sufficient support to form the WG. Please send your replies to the ICAR mailing list (icar@ietf.org). Thank you. Alex Zinin ---- [Ref1] The IESG, "Improving IETF review - further work", 05 Dec 2003 http://www1.ietf.org/mail-archive/ietf-announce/Current/msg27596.html _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Mon Dec 15 20:52:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11365 for ; Mon, 15 Dec 2003 20:52:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW4NX-0000zE-Nr for icar-archive@odin.ietf.org; Mon, 15 Dec 2003 20:52:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBG1q3kF003786 for icar-archive@odin.ietf.org; Mon, 15 Dec 2003 20:52:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW4NX-0000yz-8F for icar-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 20:52:03 -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 UAA11356 for ; Mon, 15 Dec 2003 20:52:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW4NV-0002e5-00 for icar-web-archive@ietf.org; Mon, 15 Dec 2003 20:52:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW4NT-0002dy-00 for icar-web-archive@ietf.org; Mon, 15 Dec 2003 20:52:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AW4NT-0002du-00 for icar-web-archive@ietf.org; Mon, 15 Dec 2003 20:51:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW4NV-0000yj-Ap; Mon, 15 Dec 2003 20:52:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW4FP-0000oy-EL for icar@optimus.ietf.org; Mon, 15 Dec 2003 20:43:39 -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 UAA11254 for ; Mon, 15 Dec 2003 20:43:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW4FN-0002SC-00 for icar@ietf.org; Mon, 15 Dec 2003 20:43:37 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW4FM-0002S5-00 for icar@ietf.org; Mon, 15 Dec 2003 20:43:36 -0500 Received: from tutakai.map-ne.com ([140.239.227.14] helo=Mail.MAP-NE.com) by ietf-mx with esmtp (Exim 4.12) id 1AW4FL-0002S1-00 for icar@ietf.org; Mon, 15 Dec 2003 20:43:35 -0500 Received: by Mail.MAP-NE.com (Postfix, from userid 105) id 12C943F746; Mon, 15 Dec 2003 20:43:35 -0500 (EST) To: icar@ietf.org In-reply-to: <5991801693.20031209162550@psg.com> (message from Alex Zinin on Tue, 9 Dec 2003 16:25:50 -0800) Subject: Re: [Icar] Moving on with ICAR: WG formation and charter From: "Michael A. Patton" References: <5991801693.20031209162550@psg.com> Message-Id: <20031216014335.12C943F746@Mail.MAP-NE.com> Date: Mon, 15 Dec 2003 20:43:35 -0500 (EST) 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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 It's been nearly a week and I haven't seen any responses to Alex Zinin's original posting, so I thought I'd try and spark some discussion... Before we go any further, I would like to solicit feedback from the community on the following points: 1. Do you believe that a WG should be formed to work on improving IETF cross-functional review? My initial answer is "no". Not because I think that a WG is a bad idea, but because I feel that there is a lot of improvement that can be hashed out and tried in some test cases without the overhead of forming a full WG. This is analogous to trying out a few ideas for a protocol before deciding to form a WG for a standard. I'll make this more concrete by offering such an idea in a separate message. If there are concrete things that require updates to the existing procedures RFCs, then, yes we should have a WG. But I think we can get many of the improvements within the current framework, and that just requires discussion, some trial exploration and then including it To be more specific, I think that we may get more initial thrust if ICAR starts out more like the description of PROTO (see http://www1.ietf.org/mail-archive/ietf-announce/Current/msg27636.html for that description), and after some gains have been made within the existing framework, form a working group IF there are concrete changes that require updates to the existing spec. My gut feeling on this is that 75% of what can be done fits in the existing high level procedures and is really just a tweak to how they are implemented. If so: [Well, since I said "no" this technically makes the rest moot, but I'll respond to that, too, because this was really "If you think there's work to be done" as opposed to "If you think that work should start with forming a WG".] 2. Would you be willing to actively participate in this WG (by contributing to or reviewing the documents, participating in the discussions, etc.)? Yes. Perhaps sometimes only by offering cross-functional review of documents under discussion... But often participating (or spurring, when required :-) discussion, and even offering text... 3. Please review the part in [Ref1] that provides a preliminary description of the WG and send your comments. The text in the message is likely to be used for the WG charter if there's sufficient support to form the WG. I believe the text in that message is a good rough goal. If the consensus goes for making a WG, It's a good first cut at a charter. But as I said, I think the first job for the list is NOT forming a WG, but discussing things that could be done NOW within the current procedural RFCs. -MAP _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Mon Dec 15 22:16:24 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA14067 for ; Mon, 15 Dec 2003 22:16:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW5gj-0003dl-EN for icar-archive@odin.ietf.org; Mon, 15 Dec 2003 22:15:57 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBG3Fv5x013987 for icar-archive@odin.ietf.org; Mon, 15 Dec 2003 22:15:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW5gi-0003dW-DO for icar-web-archive@optimus.ietf.org; Mon, 15 Dec 2003 22:15:56 -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 WAA14059 for ; Mon, 15 Dec 2003 22:15:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW5ga-0005cD-00 for icar-web-archive@ietf.org; Mon, 15 Dec 2003 22:15:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW5gA-0005c6-00 for icar-web-archive@ietf.org; Mon, 15 Dec 2003 22:15:22 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AW5gA-0005c3-00 for icar-web-archive@ietf.org; Mon, 15 Dec 2003 22:15:22 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW5fr-0003cc-La; Mon, 15 Dec 2003 22:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW5ey-0003bv-M6 for icar@optimus.ietf.org; Mon, 15 Dec 2003 22:14:08 -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 WAA14053 for ; Mon, 15 Dec 2003 22:14:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW5ev-0005bw-00 for icar@ietf.org; Mon, 15 Dec 2003 22:14:05 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW5eu-0005bp-00 for icar@ietf.org; Mon, 15 Dec 2003 22:14:05 -0500 Received: from eikenes.alvestrand.no ([158.38.152.233]) by ietf-mx with esmtp (Exim 4.12) id 1AW5eu-0005bH-00 for icar@ietf.org; Mon, 15 Dec 2003 22:14:04 -0500 Received: from halvestr-w2k1 (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E52CE61B9B; Tue, 16 Dec 2003 04:13:33 +0100 (CET) Date: Mon, 15 Dec 2003 18:54:46 -0800 From: Harald Tveit Alvestrand To: "Michael A. Patton" , icar@ietf.org Subject: Re: [Icar] Moving on with ICAR: WG formation and charter Message-ID: <339049717.1071514486@localhost> In-Reply-To: <20031216014335.12C943F746@Mail.MAP-NE.com> References: <5991801693.20031209162550@psg.com> <20031216014335.12C943F746@Mail.MAP-NE.com> X-Mailer: Mulberry/3.1.0 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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=AWL autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Michael, there's been some efforts towards various types of cross-area review: - the SIRS effort - the MIB Doctors, Ops Directorate and Routing Directorate - the Security Advisors - the DCCP review in Vienna I think we could try to capture some of the experiences with those mechanisms, to give us a handle on what's worthy of emulation and what's not so good to emulate. And I think a WG-like structure is a nice way to structure a discussion forum for building on that experience. So while I'm not saying that you're wrong in saying "just do it", I'd like to know that we know what we're doing, and why.... Harald _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Tue Dec 16 01:00:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA17985 for ; Tue, 16 Dec 2003 01:00:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW8Fc-0008IL-2b for icar-archive@odin.ietf.org; Tue, 16 Dec 2003 01:00:08 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBG607Zp031869 for icar-archive@odin.ietf.org; Tue, 16 Dec 2003 01:00:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW8Fa-0008Ho-OB for icar-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 01:00:06 -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 BAA17969 for ; Tue, 16 Dec 2003 01:00:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW8FX-0001iC-00 for icar-web-archive@ietf.org; Tue, 16 Dec 2003 01:00:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW8FW-0001i5-00 for icar-web-archive@ietf.org; Tue, 16 Dec 2003 01:00:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AW8FW-0001i2-00 for icar-web-archive@ietf.org; Tue, 16 Dec 2003 01:00:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW8FX-0008HU-Kr; Tue, 16 Dec 2003 01:00:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AW4lF-0001uN-Lj for icar@optimus.ietf.org; Mon, 15 Dec 2003 21:16:33 -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 VAA11969 for ; Mon, 15 Dec 2003 21:16:30 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AW4lC-0003OE-00 for icar@ietf.org; Mon, 15 Dec 2003 21:16:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AW4l9-0003O5-00 for icar@ietf.org; Mon, 15 Dec 2003 21:16:27 -0500 Received: from tutakai.map-ne.com ([140.239.227.14] helo=Mail.MAP-NE.com) by ietf-mx with esmtp (Exim 4.12) id 1AW4l9-0003ML-00 for icar@ietf.org; Mon, 15 Dec 2003 21:16:27 -0500 Received: by Mail.MAP-NE.com (Postfix, from userid 105) id E3B0A3F746; Mon, 15 Dec 2003 21:16:12 -0500 (EST) To: icar@ietf.org From: "Michael A. Patton" Message-Id: <20031216021612.E3B0A3F746@Mail.MAP-NE.com> Date: Mon, 15 Dec 2003 21:16:12 -0500 (EST) Subject: [Icar] Tagging drafts 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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 As someone who actually tries to provide some cross-review, the biggest problem I run into is knowing when a draft is in a state for this to be useful. I usually pick out one or two of the announcements not in my WGs, but often all I can say after reading them is "get back to me after you actually think about this" and even more often "this is obviously far enough along that I need to spend hours to understand it enough to comment", and I much less often find one at the stage where I can do a useful cross-review. This could be helped a lot if there was something in the I-D ACTION message which indicated this. Without ANY changes to the tools, a first cut at this could be done by the draft authors by a sentence at the start of the Abstract. That might be good enough to get some initial test feedback, get a few authors to start trying that and see if they get more feedback from more IETFers (although that might be hard to measure, so we'd have to rely on anecdotal evidence). Longer term, a good technology might be having a token in the draft that the I-D ACTION posting could extract. We can discuss the best way to present it. At first impression I'd like it in the message's subject so scans of headers could show it, but the subject lines are already pretty crowded, but maybe that should also be addressed. -MAP _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Tue Dec 16 07:20:39 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12808 for ; Tue, 16 Dec 2003 07:20:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWEBN-00080S-7p for icar-archive@odin.ietf.org; Tue, 16 Dec 2003 07:20:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGCK9NW030772 for icar-archive@odin.ietf.org; Tue, 16 Dec 2003 07:20:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWEBN-00080F-0T for icar-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 07:20:09 -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 HAA12789 for ; Tue, 16 Dec 2003 07:20:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWEBM-00076O-00 for icar-web-archive@ietf.org; Tue, 16 Dec 2003 07:20:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWEBL-00076H-00 for icar-web-archive@ietf.org; Tue, 16 Dec 2003 07:20:08 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWEBL-00076E-00 for icar-web-archive@ietf.org; Tue, 16 Dec 2003 07:20:07 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWEBJ-0007zZ-Al; Tue, 16 Dec 2003 07:20:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWEAJ-0007yL-6T for icar@optimus.ietf.org; Tue, 16 Dec 2003 07:19:10 -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 HAA12764 for ; Tue, 16 Dec 2003 07:19:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWEAB-000732-00 for icar@ietf.org; Tue, 16 Dec 2003 07:18:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWE9l-00072b-00 for icar@ietf.org; Tue, 16 Dec 2003 07:18:30 -0500 Received: from auemail1.lucent.com ([192.11.223.161] helo=auemail1.firewall.lucent.com) by ietf-mx with esmtp (Exim 4.12) id 1AWE9k-000723-00 for icar@ietf.org; Tue, 16 Dec 2003 07:18:28 -0500 Received: from nl0006exch001h.wins.lucent.com (h135-85-76-62.lucent.com [135.85.76.62]) by auemail1.firewall.lucent.com (Switch-2.2.8/Switch-2.2.0) with ESMTP id hBGCHQB12961 for ; Tue, 16 Dec 2003 06:17:27 -0600 (CST) Received: by nl0006exch001h.nl.lucent.com with Internet Mail Service (5.5.2656.59) id ; Tue, 16 Dec 2003 13:17:24 +0100 Message-ID: <7D5D48D2CAA3D84C813F5B154F43B155032D949F@nl0006exch001u.nl.lucent.com> From: "Wijnen, Bert (Bert)" To: "Michael A. Patton" , icar@ietf.org Subject: RE: [Icar] Tagging drafts Date: Tue, 16 Dec 2003 13:17:17 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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 sort of like thsi idea... however, if it is just something the author/editor can put in the draft, then there is potential of mis-use by individuals who just want their document to get wider attention. Should it be WG chairs that request such specific cross-area review? Or should they approve such requests? Another idea could be a generic mailing list where WG chairs can do a call for CrossArea review? Thanks, Bert > -----Original Message----- > From: Michael A. Patton [mailto:MAP@MAP-NE.com] > Sent: dinsdag 16 december 2003 3:16 > To: icar@ietf.org > Subject: [Icar] Tagging drafts > > > As someone who actually tries to provide some cross-review, the > biggest problem I run into is knowing when a draft is in a state for > this to be useful. I usually pick out one or two of the announcements > not in my WGs, but often all I can say after reading them is "get back > to me after you actually think about this" and even more > often "this is > obviously far enough along that I need to spend hours to understand it > enough to comment", and I much less often find one at the stage where > I can do a useful cross-review. > > This could be helped a lot if there was something in the I-D ACTION > message which indicated this. Without ANY changes to the tools, a > first cut at this could be done by the draft authors by a sentence at > the start of the Abstract. That might be good enough to get some > initial test feedback, get a few authors to start trying that and see > if they get more feedback from more IETFers (although that might be > hard to measure, so we'd have to rely on anecdotal evidence). > > Longer term, a good technology might be having a token in the draft > that the I-D ACTION posting could extract. We can discuss the best > way to present it. At first impression I'd like it in the message's > subject so scans of headers could show it, but the subject lines are > already pretty crowded, but maybe that should also be addressed. > > -MAP > > _______________________________________________ > Icar mailing list > Icar@ietf.org > https://www1.ietf.org/mailman/listinfo/icar > _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Tue Dec 16 07:47:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13385 for ; Tue, 16 Dec 2003 07:47:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWEbP-0000KX-2O for icar-archive@odin.ietf.org; Tue, 16 Dec 2003 07:47:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGCl3aT001263 for icar-archive@odin.ietf.org; Tue, 16 Dec 2003 07:47:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWEbO-0000KI-Rq for icar-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 07:47:02 -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 HAA13368 for ; Tue, 16 Dec 2003 07:47:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWEbO-0000DI-00 for icar-web-archive@ietf.org; Tue, 16 Dec 2003 07:47:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWEbM-0000DA-00 for icar-web-archive@ietf.org; Tue, 16 Dec 2003 07:47:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWEbM-0000D6-00 for icar-web-archive@ietf.org; Tue, 16 Dec 2003 07:47:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWEbM-0000Je-Rg; Tue, 16 Dec 2003 07:47:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWEar-0000J2-UO for icar@optimus.ietf.org; Tue, 16 Dec 2003 07:46:29 -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 HAA13351 for ; Tue, 16 Dec 2003 07:46:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWEar-0000AR-00 for icar@ietf.org; Tue, 16 Dec 2003 07:46:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWEap-00009z-00 for icar@ietf.org; Tue, 16 Dec 2003 07:46:28 -0500 Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx with esmtp (Exim 4.12) id 1AWEap-00009E-00 for icar@ietf.org; Tue, 16 Dec 2003 07:46:27 -0500 Received: from dfnjgl21 (c-24-1-97-129.client.comcast.net[24.1.97.129]) by comcast.net (sccrmhc13) with SMTP id <2003121612455201600rlfpae> (Authid: sdawkins@comcast.net); Tue, 16 Dec 2003 12:45:53 +0000 Message-ID: <016a01c3c3d2$8b773620$0400a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: Cc: "Ted Hardie" References: <7D5D48D2CAA3D84C813F5B154F43B155032D949F@nl0006exch001u.nl.lucent.com> Subject: Re: [Icar] Tagging drafts Date: Tue, 16 Dec 2003 06:45:54 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I agree with Michael that knowing that a draft is somewhat stable helps a lot (I tend to review for lots of editorial nits, and providing lots of editorial nits for the previous version of a draft isn't effective). My impression is that we're trying to minimize new work for the secretariat in standards production, so one advantage of Michael's proposal was that no one but the author needed to do anything, and the secretariat might not even notice that we've adopted this procedure. If we can't trust document authors to ask for cross-area review, that's not a good sign. Can we just try the "un-moderated" version of requesting first, and see if there's a problem? Current practice seems to be authors/editors announcing the draft on mailing lists of other groups ("you might want to look at this"), with no control (except that many of our WG mailing lists are now member-only posting, so it takes a little more effort to do the announcements). There are 200 or so WG chairs. Who checks that the person requesting cross-area review is a WG chair? Who checks that a WG chair approved a request? In a perfect world, I could imagine monthly e-mails from each (pair of) AD(s) saying "these drafts are ready for early/late cross-area review", and that might scale pretty well, but I am loathe to suggest more work for ADs that doesn't replace other work. SIR was an unofficial experiment, but even that limited experience seemed (to me) to indicate that requesting reviews from specific reviewers was a lot more effective than broadcasting SIR review requests on the SIRs mailing list. I believe Ted Hardie's plenary presentation made this point as well ("general calls for help don't generate a lot of help"). I've learned to ignore Jim Fleming's "advertisements" for post-IPv6 networking protocols. Maybe that's the best we can do with cross-area review requests ("look at ME!", "no, look at ME!"). Spencer ----- Original Message ----- From: "Wijnen, Bert (Bert)" To: "Michael A. Patton" ; Sent: Tuesday, December 16, 2003 6:17 AM Subject: RE: [Icar] Tagging drafts > I sort of like thsi idea... however, if it is just something the > author/editor can put in the draft, then there is potential of mis-use > by individuals who just want their document to get wider attention. > > Should it be WG chairs that request such specific cross-area review? > Or should they approve such requests? > > Another idea could be a generic mailing list where WG chairs can do > a call for CrossArea review? > > Thanks, > Bert > > > -----Original Message----- > > From: Michael A. Patton [mailto:MAP@MAP-NE.com] > > Sent: dinsdag 16 december 2003 3:16 > > To: icar@ietf.org > > Subject: [Icar] Tagging drafts > > > > > > As someone who actually tries to provide some cross-review, the > > biggest problem I run into is knowing when a draft is in a state for > > this to be useful. I usually pick out one or two of the announcements > > not in my WGs, but often all I can say after reading them is "get back > > to me after you actually think about this" and even more > > often "this is > > obviously far enough along that I need to spend hours to understand it > > enough to comment", and I much less often find one at the stage where > > I can do a useful cross-review. > > > > This could be helped a lot if there was something in the I-D ACTION > > message which indicated this. Without ANY changes to the tools, a > > first cut at this could be done by the draft authors by a sentence at > > the start of the Abstract. That might be good enough to get some > > initial test feedback, get a few authors to start trying that and see > > if they get more feedback from more IETFers (although that might be > > hard to measure, so we'd have to rely on anecdotal evidence). > > > > Longer term, a good technology might be having a token in the draft > > that the I-D ACTION posting could extract. We can discuss the best > > way to present it. At first impression I'd like it in the message's > > subject so scans of headers could show it, but the subject lines are > > already pretty crowded, but maybe that should also be addressed. > > > > -MAP _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Tue Dec 16 16:10:47 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05391 for ; Tue, 16 Dec 2003 16:10:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWMSR-0006V8-7Q for icar-archive@odin.ietf.org; Tue, 16 Dec 2003 16:10:19 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGLAJmh024984 for icar-archive@odin.ietf.org; Tue, 16 Dec 2003 16:10:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWMSQ-0006Ut-Qh for icar-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 16:10:19 -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 QAA05276 for ; Tue, 16 Dec 2003 16:10:16 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWMSP-00039e-00 for icar-web-archive@ietf.org; Tue, 16 Dec 2003 16:10:17 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWMSD-000381-00 for icar-web-archive@ietf.org; Tue, 16 Dec 2003 16:10:15 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWMSC-00037o-00 for icar-web-archive@ietf.org; Tue, 16 Dec 2003 16:10:04 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWMSA-0006Se-Pb; Tue, 16 Dec 2003 16:10:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWLpf-0003io-9K for icar@optimus.ietf.org; Tue, 16 Dec 2003 15:30:15 -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 PAA02158 for ; Tue, 16 Dec 2003 15:30:13 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWLpY-0001CJ-00 for icar@ietf.org; Tue, 16 Dec 2003 15:30:09 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWLp7-0001BZ-00 for icar@ietf.org; Tue, 16 Dec 2003 15:29:43 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AWLp7-0001A3-00 for icar@ietf.org; Tue, 16 Dec 2003 15:29:41 -0500 Received: from localhost (klutz.cs.utk.edu [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id 6C617AFD56 for ; Tue, 16 Dec 2003 15:29:12 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01735-06; Tue, 16 Dec 2003 15:29:11 -0500 (EST) Received: from astro.cs.utk.edu (astro.cs.utk.edu [160.36.58.43]) by smtp.cs.utk.edu (Postfix) with ESMTP id 66E7FAFD31; Tue, 16 Dec 2003 15:29:11 -0500 (EST) Date: Tue, 16 Dec 2003 15:29:11 -0500 From: Keith Moore To: icar@ietf.org Cc: moore@cs.utk.edu Subject: re: [Icar] Moving on with ICAR: WG formation and charter Message-Id: <20031216152911.299412db.moore@cs.utk.edu> X-Mailer: Sylpheed version 0.9.7 (GTK+ 1.2.10; i386--netbsdelf) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit I am highly dubious that a separate WG for cross-functional review would be desirable. Cross-functional review is certainly necessary; however, I don't think that a WG focused on looking just at cross-functional review in isolation from the rest of the WG process is likely to produce very useful output. IMHO we need to be thinking about how WGs should be doing protocol engineering, and we should consider such questions as how to do cross-functional review, and how to shift responsibility between IESG and WGs, in the context of a discussion about how we should do engineering. More generally, I think that having lots of separate WGs each looking at different aspects of WG operation is likely to fragment the discussion in an unproductive way, and also limit those who see things from a broader perspective from providing much useful input, by forcing them to keep track of discussion in multiple WGs. And I think that especially in these kinds of dicussions that have broad effects, IETF badly needs more input from people with "big picture" views. Keith _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Tue Dec 16 17:36:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11621 for ; Tue, 16 Dec 2003 17:36:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWNnS-0001Nz-2j for icar-archive@odin.ietf.org; Tue, 16 Dec 2003 17:36:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGMa6Rv005321 for icar-archive@odin.ietf.org; Tue, 16 Dec 2003 17:36:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWNnR-0001Nk-UJ for icar-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 17:36:05 -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 RAA11594 for ; Tue, 16 Dec 2003 17:36:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWNnP-0000XE-00 for icar-web-archive@ietf.org; Tue, 16 Dec 2003 17:36:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWNnO-0000X7-00 for icar-web-archive@ietf.org; Tue, 16 Dec 2003 17:36:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWNnO-0000X4-00 for icar-web-archive@ietf.org; Tue, 16 Dec 2003 17:36:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWNnN-0001Mn-RG; Tue, 16 Dec 2003 17:36:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWNn3-0001Lx-KX for icar@optimus.ietf.org; Tue, 16 Dec 2003 17:35:41 -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 RAA11591 for ; Tue, 16 Dec 2003 17:35:37 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWNn1-0000WY-00 for icar@ietf.org; Tue, 16 Dec 2003 17:35:39 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWNn0-0000WQ-00 for icar@ietf.org; Tue, 16 Dec 2003 17:35:38 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AWNn0-0000WM-00 for icar@ietf.org; Tue, 16 Dec 2003 17:35:38 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AWNmz-000K8u-Ko; Tue, 16 Dec 2003 22:35:37 +0000 Date: Tue, 16 Dec 2003 14:34:31 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <27100647563.20031216143431@psg.com> To: "Michael A. Patton" CC: icar@ietf.org, Spencer Dawkins Subject: Re: [Icar] Tagging drafts In-Reply-To: <20031216021612.E3B0A3F746@Mail.MAP-NE.com> References: <20031216021612.E3B0A3F746@Mail.MAP-NE.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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.3 required=5.0 tests=RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Michael, Spencer- If we say that the IETF LC is the means for soliciting "late" cross-area review, can we have a similar notion for early review? Let's call it "Call for Review". Using this analogy, figuring if a document is sufficiently mature would equal to checking if the review call has been initiated for it, or, in other words, the review call would be an implicit indication of the transition to a mature state. Requests for early review should be initiated by the WG chairs, I believe. Having ADs do that would introduce an unnecessary level of indirection and state to be maintained--the ADs would still need to get the recommendations from the WG chairs. Also, someone needs to keep track of the comments and how they are resolved, and this scales better if pushed closer to the edge (WGs). Finally, to put this all in perspective, this would address the "unstructured" type of review, as I call it. Here, I don't think we can get rid of the "general appeal" problem as long as we want to preserve openness of the process in general, and subscription to the review request mailing list in particular. More targeted review requests would need more structure, such as directorates or area review teams, I believe. -- Alex http://www.psg.com/~zinin/ Monday, December 15, 2003, 6:16:12 PM, Michael A. Patton wrote: > As someone who actually tries to provide some cross-review, the > biggest problem I run into is knowing when a draft is in a state for > this to be useful. I usually pick out one or two of the announcements > not in my WGs, but often all I can say after reading them is "get back > to me after you actually think about this" and even more often "this is > obviously far enough along that I need to spend hours to understand it > enough to comment", and I much less often find one at the stage where > I can do a useful cross-review. > This could be helped a lot if there was something in the I-D ACTION > message which indicated this. Without ANY changes to the tools, a > first cut at this could be done by the draft authors by a sentence at > the start of the Abstract. That might be good enough to get some > initial test feedback, get a few authors to start trying that and see > if they get more feedback from more IETFers (although that might be > hard to measure, so we'd have to rely on anecdotal evidence). > Longer term, a good technology might be having a token in the draft > that the I-D ACTION posting could extract. We can discuss the best > way to present it. At first impression I'd like it in the message's > subject so scans of headers could show it, but the subject lines are > already pretty crowded, but maybe that should also be addressed. > -MAP > _______________________________________________ > Icar mailing list > Icar@ietf.org > https://www1.ietf.org/mailman/listinfo/icar _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Tue Dec 16 17:44:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11825 for ; Tue, 16 Dec 2003 17:44:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWNv8-0001t8-V0 for icar-archive@odin.ietf.org; Tue, 16 Dec 2003 17:44:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGMi2nE007257 for icar-archive@odin.ietf.org; Tue, 16 Dec 2003 17:44:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWNv8-0001sy-Pv for icar-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 17:44:02 -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 RAA11818 for ; Tue, 16 Dec 2003 17:43:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWNv6-0000nw-00 for icar-web-archive@ietf.org; Tue, 16 Dec 2003 17:44:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWNv5-0000no-00 for icar-web-archive@ietf.org; Tue, 16 Dec 2003 17:44:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWNv5-0000nl-00 for icar-web-archive@ietf.org; Tue, 16 Dec 2003 17:43:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWNv7-0001sI-10; Tue, 16 Dec 2003 17:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWNuN-0001rc-Hj for icar@optimus.ietf.org; Tue, 16 Dec 2003 17:43:15 -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 RAA11809 for ; Tue, 16 Dec 2003 17:43:11 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWNuL-0000m9-00 for icar@ietf.org; Tue, 16 Dec 2003 17:43:13 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWNuK-0000m2-00 for icar@ietf.org; Tue, 16 Dec 2003 17:43:12 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AWNuJ-0000ly-00 for icar@ietf.org; Tue, 16 Dec 2003 17:43:12 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD 4.9) id 1AWNuJ-000Ktn-6e; Tue, 16 Dec 2003 22:43:11 +0000 Date: Tue, 16 Dec 2003 14:42:04 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <153101100604.20031216144204@psg.com> To: "Wijnen, Bert (Bert)" CC: "Michael A. Patton" , icar@ietf.org Subject: Re: [Icar] Tagging drafts In-Reply-To: <7D5D48D2CAA3D84C813F5B154F43B155032D949F@nl0006exch001u.nl.lucent.com> References: <7D5D48D2CAA3D84C813F5B154F43B155032D949F@nl0006exch001u.nl.lucent.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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.3 required=5.0 tests=RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Bert, Tuesday, December 16, 2003, 4:17:17 AM, Wijnen, Bert (Bert) wrote: > I sort of like thsi idea... however, if it is just something the > author/editor can put in the draft, then there is potential of mis-use > by individuals who just want their document to get wider attention. I'm trying to decide if it's bad or good :) At the end of the day we want wider cross-functional review for more documents and more attention seems to be good. The irony is, of course, that putting the "sure we are ready for x-func review" label on every other document could be as bad as not putting it at all > Should it be WG chairs that request such specific cross-area review? > Or should they approve such requests? WG chairs doing that would seem reasonable to me. > Another idea could be a generic mailing list where WG chairs can do > a call for CrossArea review? Yep, see my previous message. Alex > Thanks, > Bert >> -----Original Message----- >> From: Michael A. Patton [mailto:MAP@MAP-NE.com] >> Sent: dinsdag 16 december 2003 3:16 >> To: icar@ietf.org >> Subject: [Icar] Tagging drafts >> >> >> As someone who actually tries to provide some cross-review, the >> biggest problem I run into is knowing when a draft is in a state for >> this to be useful. I usually pick out one or two of the announcements >> not in my WGs, but often all I can say after reading them is "get back >> to me after you actually think about this" and even more >> often "this is >> obviously far enough along that I need to spend hours to understand it >> enough to comment", and I much less often find one at the stage where >> I can do a useful cross-review. >> >> This could be helped a lot if there was something in the I-D ACTION >> message which indicated this. Without ANY changes to the tools, a >> first cut at this could be done by the draft authors by a sentence at >> the start of the Abstract. That might be good enough to get some >> initial test feedback, get a few authors to start trying that and see >> if they get more feedback from more IETFers (although that might be >> hard to measure, so we'd have to rely on anecdotal evidence). >> >> Longer term, a good technology might be having a token in the draft >> that the I-D ACTION posting could extract. We can discuss the best >> way to present it. At first impression I'd like it in the message's >> subject so scans of headers could show it, but the subject lines are >> already pretty crowded, but maybe that should also be addressed. >> >> -MAP >> >> _______________________________________________ >> Icar mailing list >> Icar@ietf.org >> https://www1.ietf.org/mailman/listinfo/icar >> > _______________________________________________ > Icar mailing list > Icar@ietf.org > https://www1.ietf.org/mailman/listinfo/icar _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Tue Dec 16 17:59:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12250 for ; Tue, 16 Dec 2003 17:59:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWO9e-0002ZX-UW for icar-archive@odin.ietf.org; Tue, 16 Dec 2003 17:59:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGMx2HN009881 for icar-archive@odin.ietf.org; Tue, 16 Dec 2003 17:59:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWO9e-0002ZI-QM for icar-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 17:59:02 -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 RAA12247 for ; Tue, 16 Dec 2003 17:58:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWO9c-0001E3-00 for icar-web-archive@ietf.org; Tue, 16 Dec 2003 17:59:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWO9b-0001Dw-00 for icar-web-archive@ietf.org; Tue, 16 Dec 2003 17:58:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWO9b-0001Dt-00 for icar-web-archive@ietf.org; Tue, 16 Dec 2003 17:58:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWO9d-0002Yv-3g; Tue, 16 Dec 2003 17:59:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWO9Y-0002Yj-I9 for icar@optimus.ietf.org; Tue, 16 Dec 2003 17:58:56 -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 RAA12244 for ; Tue, 16 Dec 2003 17:58:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWO9V-0001Dq-00 for icar@ietf.org; Tue, 16 Dec 2003 17:58:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWO9V-0001Dj-00 for icar@ietf.org; Tue, 16 Dec 2003 17:58:53 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AWO9U-0001Dg-00 for icar@ietf.org; Tue, 16 Dec 2003 17:58:52 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AWO9U-0005BW-H8; Tue, 16 Dec 2003 22:58:52 +0000 Date: Tue, 16 Dec 2003 14:57:46 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <80102041748.20031216145746@psg.com> To: Keith Moore CC: icar@ietf.org Subject: Re: [Icar] Moving on with ICAR: WG formation and charter In-Reply-To: <20031216152911.299412db.moore@cs.utk.edu> References: <20031216152911.299412db.moore@cs.utk.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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.3 required=5.0 tests=RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Keith, I don't think putting a specific topic in a separate WG means it will work in isolation from others. I hope we're better than that. To me, it's a question of whether a specific issue is sufficiently big, separateable and independent from the rest to benefit from dedicated process bandwidth, plus how complex the inter-WG IPC is likely to be. It seems that we need to improve cross-functional review within the IETF anyways, whether we shift the responsibility between the IESG and WGs or not. This is not to say that we should not work on the bigger picture, we certainly should. Did you have a suggestion in mind, by the way? Thanks -- Alex http://www.psg.com/~zinin/ Tuesday, December 16, 2003, 12:29:11 PM, Keith Moore wrote: > I am highly dubious that a separate WG for cross-functional review > would be desirable. Cross-functional review is certainly necessary; > however, I don't think that a WG focused on looking just at > cross-functional review in isolation from the rest of the WG process is > likely to produce very useful output. > IMHO we need to be thinking about how WGs should be doing protocol > engineering, and we should consider such questions as how to do > cross-functional review, and how to shift responsibility between IESG and > WGs, in the context of a discussion about how we should do engineering. > More generally, I think that having lots of separate WGs each looking at > different aspects of WG operation is likely to fragment the discussion > in an unproductive way, and also limit those who see things from a > broader perspective from providing much useful input, by forcing them to > keep track of discussion in multiple WGs. And I think that especially > in these kinds of dicussions that have broad effects, IETF badly > needs more input from people with "big picture" views. > Keith > _______________________________________________ > Icar mailing list > Icar@ietf.org > https://www1.ietf.org/mailman/listinfo/icar _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Tue Dec 16 18:39:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14838 for ; Tue, 16 Dec 2003 18:39:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWOmQ-0004mu-6n for icar-archive@odin.ietf.org; Tue, 16 Dec 2003 18:39:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGNd65r018400 for icar-archive@odin.ietf.org; Tue, 16 Dec 2003 18:39:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWOmQ-0004mK-0D for icar-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 18:39:06 -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 SAA14822 for ; Tue, 16 Dec 2003 18:38:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWOmK-0002Uo-00 for icar-web-archive@ietf.org; Tue, 16 Dec 2003 18:39:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWOmJ-0002Uf-00 for icar-web-archive@ietf.org; Tue, 16 Dec 2003 18:38:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWOmJ-0002Uc-00 for icar-web-archive@ietf.org; Tue, 16 Dec 2003 18:38:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWOmL-0004lt-9T; Tue, 16 Dec 2003 18:39:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWOap-0003jy-Ns for icar@optimus.ietf.org; Tue, 16 Dec 2003 18:27:07 -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 SAA14248 for ; Tue, 16 Dec 2003 18:27:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWOam-00020E-00 for icar@ietf.org; Tue, 16 Dec 2003 18:27:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWOal-000205-00 for icar@ietf.org; Tue, 16 Dec 2003 18:27:04 -0500 Received: from klutz.cs.utk.edu ([160.36.56.50]) by ietf-mx with esmtp (Exim 4.12) id 1AWOal-0001zy-00 for icar@ietf.org; Tue, 16 Dec 2003 18:27:03 -0500 Received: from localhost (klutz.cs.utk.edu [127.0.0.1]) by smtp.cs.utk.edu (Postfix) with ESMTP id ED178AFDD8; Tue, 16 Dec 2003 18:27:02 -0500 (EST) Received: from klutz.cs.utk.edu ([127.0.0.1]) by localhost (klutz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 27005-01; Tue, 16 Dec 2003 18:27:01 -0500 (EST) Received: from [192.168.0.4] (user-119b1dm.biz.mindspring.com [66.149.133.182]) by smtp.cs.utk.edu (Postfix) with ESMTP id 78ECAAFC21; Tue, 16 Dec 2003 18:27:01 -0500 (EST) In-Reply-To: <80102041748.20031216145746@psg.com> References: <20031216152911.299412db.moore@cs.utk.edu> <80102041748.20031216145746@psg.com> Mime-Version: 1.0 (Apple Message framework v606) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <78635541-301F-11D8-97F7-000393DB5366@cs.utk.edu> Content-Transfer-Encoding: 7bit Cc: Keith Moore , icar@ietf.org From: Keith Moore Subject: Re: [Icar] Moving on with ICAR: WG formation and charter Date: Tue, 16 Dec 2003 18:27:52 -0500 To: Alex Zinin X-Mailer: Apple Mail (2.606) X-Virus-Scanned: by amavisd-new and ClamAV at cs.utk.edu Content-Transfer-Encoding: 7bit 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit > I don't think putting a specific topic in a separate WG means it > will work in isolation from others. I hope we're better than that. I don't think such a WG is likely to work in total isolation from the others, but I doubt it could be tightly coupled enough with the several other fragmented WGs that have been proposed to have confidence in the coherence in the collected output of these groups. > To me, it's a question of whether a specific issue is sufficiently > big, separateable and independent from the rest to benefit from > dedicated process bandwidth, I think it's a question of misplaced focus -- paying too little attention to improving the quality of the original work and too much attention to improving the feedback loop. I'm reminded of the guy who was looking for his lost keys outside his house, even though they were inside the house when he last saw them. His reason? "The light is better out here." > It seems that we need to improve cross-functional review within the > IETF anyways, whether we shift the responsibility between the IESG > and WGs or not. This is not to say that we should not work on the > bigger picture, we certainly should. I believe that having a separate group working on cross-area review in the near future would distract attention from work on the bigger picture, and that the former work would be in danger of being irrelevant if not informed by the big picture work. So I think the work on the bigger picture needs to precede the detailed work on cross-area review, even if the latter is eventually done by a separate WG. > Did you have a suggestion in mind, by the way? I think we need to define the process known as Internet protocol engineering - i.e., the process we expect WGs (as well as individuals, for individual submissions) to follow in producing protocol specifications. This process needs to include cross-area review, but it needs to include lots of other things also. I think we need to invite proposals for what this process should look like, and have some informal public discussion and refinement of those proposals, before we try to form a WG to sort it out. I think we need to try the new process in a small number of working groups, and get feedback from WG participants and other parties, before we try to adopt it on a widespread basis. _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Tue Dec 16 18:58:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA15510 for ; Tue, 16 Dec 2003 18:58:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWP4l-000669-H2 for icar-archive@odin.ietf.org; Tue, 16 Dec 2003 18:58:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBGNw3ff023435 for icar-archive@odin.ietf.org; Tue, 16 Dec 2003 18:58:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWP4l-00065u-Cy for icar-web-archive@optimus.ietf.org; Tue, 16 Dec 2003 18:58:03 -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 SAA15503 for ; Tue, 16 Dec 2003 18:57:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWP4i-000323-00 for icar-web-archive@ietf.org; Tue, 16 Dec 2003 18:58:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWP4h-00031w-00 for icar-web-archive@ietf.org; Tue, 16 Dec 2003 18:57:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWP4h-00031t-00 for icar-web-archive@ietf.org; Tue, 16 Dec 2003 18:57:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWP4j-00065K-EP; Tue, 16 Dec 2003 18:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWP4T-00063H-1L for icar@optimus.ietf.org; Tue, 16 Dec 2003 18:57:45 -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 SAA15485 for ; Tue, 16 Dec 2003 18:57:40 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWP4P-000314-00 for icar@ietf.org; Tue, 16 Dec 2003 18:57:41 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWP4O-00030x-00 for icar@ietf.org; Tue, 16 Dec 2003 18:57:41 -0500 Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AWP4O-00030K-00 for icar@ietf.org; Tue, 16 Dec 2003 18:57:40 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 16 Dec 2003 16:00:33 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-2.cisco.com (8.12.9/8.12.6) with ESMTP id hBGNv7BN003590; Tue, 16 Dec 2003 15:57:08 -0800 (PST) Received: from cisco.com ([10.25.65.180]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id APE58455; Tue, 16 Dec 2003 15:57:06 -0800 (PST) Date: Tue, 16 Dec 2003 18:57:02 -0500 Subject: Re: [Icar] Moving on with ICAR: WG formation and charter Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: icar@ietf.org To: Alex Zinin From: Melinda Shore In-Reply-To: <80102041748.20031216145746@psg.com> Message-Id: <8B5C8BAB-3023-11D8-B7AE-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 7bit 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Tuesday, December 16, 2003, at 05:57 PM, Alex Zinin wrote: > To me, it's a question of whether a specific issue is sufficiently > big, separateable and independent from the rest to benefit from > dedicated process bandwidth, plus how complex the inter-WG IPC is > likely to be. To be honest, I'm not completely clear on what the subject is, or at least not clear enough to be able to answer the questions you ask. We've actually got several review problems. One is early review and another is cross-area review (there are others, but I think these are the most pressing). Failures in these areas have overlapping but somewhat different results, in that early review (i.e. review against the charter, or review for quality within the charter) failures tend to allow the working group to produce bad results while cross-area review failures can lead to work that's incoherent in the broader context, work that's substantially the same as work in another area, and so on. Some of what's been discussed or experimented with already, like SIRS, has tended to focus on the early review problem, but I'm inclined to think that can be solved with a bigger hammer (making better use of WG technical advisors, for example). The cross-area review problem is a structural/scaling problem and one that I think may require process or structural changes. That's actually a pretty big deal and might have broader implications for the kind of organization we are, whether we're bottom-up/volunteer/etc. or we're more top-down/authoritarian. This discussion needs to continue to involve the entire organization (or those who are interested, anyway). I'm not sure that we can talk about this in isolation from questions about area boards, etc. At the same time, in watching some of the debates that we're having about organizational change it looks to me like there's a tendency to deadlock over issues like making sure that we've got authority structures that match our responsibility structures, and it's interfering with our ability to make progress. At some point we have to rely on the good will of the participants, and if we don't have that we're hosed, anyway. I'm not opposed to the creation of a working group but I think that if one is created (and this is true of other "improvement" efforts, as well) 1) the partipants, or at the very least the chairs and the responsible AD, need to be committed to the possibility that the outcome might be to maintain the status quo, and 2) we may need to be a little non-traditional about how we ratify its output, which is something that needs a lot of further discussion. A nit on the specific proposal: it's not clear to me that "peer-to- peer" reviews are the right answer, and in the context of the IETF I'm not even sure what "peer" means. More generally, I think I'd be happy never to see the phrase "peer to peer" again. Let's try to figure out what the actual review problem(s) is/are that need to be addressed and use words that describe those. Melinda _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Wed Dec 17 07:19:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05241 for ; Wed, 17 Dec 2003 07:19:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWadr-0008FL-2r for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 07:19:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHCJ3cN031695 for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 07:19:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWadq-0008F8-TV for icar-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 07:19:02 -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 HAA05229 for ; Wed, 17 Dec 2003 07:19:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWadq-0001EJ-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 07:19:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWadp-0001EB-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 07:19:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWadp-0001E8-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 07:19:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWado-0008Ej-Vk; Wed, 17 Dec 2003 07:19:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWadJ-0008ER-Lj for icar@optimus.ietf.org; Wed, 17 Dec 2003 07:18:29 -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 HAA05221 for ; Wed, 17 Dec 2003 07:18:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWadJ-0001D2-00 for icar@ietf.org; Wed, 17 Dec 2003 07:18:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWadH-0001Cv-00 for icar@ietf.org; Wed, 17 Dec 2003 07:18:28 -0500 Received: from sccrmhc13.comcast.net ([204.127.202.64]) by ietf-mx with esmtp (Exim 4.12) id 1AWadH-0001CJ-00 for icar@ietf.org; Wed, 17 Dec 2003 07:18:27 -0500 Received: from dfnjgl21 (c-24-1-97-129.client.comcast.net[24.1.97.129]) by comcast.net (sccrmhc13) with SMTP id <2003121712175601600rlqpge> (Authid: sdawkins@comcast.net); Wed, 17 Dec 2003 12:17:56 +0000 Message-ID: <026f01c3c497$cf935170$0400a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: References: <5991801693.20031209162550@psg.com> Subject: Re: [Icar] Moving on with ICAR: WG formation and charter Date: Wed, 17 Dec 2003 06:17:59 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit My replies inline... Spencer ----- Original Message ----- From: "Alex Zinin" To: Sent: Tuesday, December 09, 2003 6:25 PM Subject: [Icar] Moving on with ICAR: WG formation and charter > > 1. Do you believe that a WG should be formed to work on improving > IETF cross-functional review (see IESG message [Ref1] for more > detail)? Well... I think cross-functional review is a good thing (duh), but am confused about the relationship between icar and other review improvements (SIR/CARD, AIR/CREW, ART, 2-LEVEL ...). The things that worry me are: - fragmentation of efforts to improve reviews (early, late, cross-area, peer-to-peer vs formal approval, etc.). I think there is enough energy in the IETF to improve the way we do reviews, but not enough to do a bunch of parallel discussion ("you are in a maze of twisty passages, all alike"). I'm also curious about interactions between proposals these efforts put forward. - I thought Ted Hardie's description of the "Ambulance Syndrome" in http://www.alvestrand.no/ietf/nov2003-minneapolis/iesg-overview.pdf was a critical problem to solve, and didn't see this addressed in icar yet (or anywhere else). Not to be blunt, but I can take more "sponsored" time to contribute solicited reviews in a SIR/CARD or AIR/CREW framework than just replying to a general call for cross-area review on a mailing list. > > If so: > > 2. Would you be willing to actively participate in this WG (by > contributing to or reviewing the documents, participating > in the discussions, etc.)? Sure, but this is competing for my time and energy with at least newtrk and mpowr, at least for me. I'll probably contribute to the efforts that seem to be moving forward. Progress is good. > > 3. Please review the part in [Ref1] that provides a preliminary > description of the WG and send your comments. The text in the > message is likely to be used for the WG charter if there's > sufficient support to form the WG. "Peer-to-peer" isn't described anywhere, so you're counting on everyone having the same understanding of what you're thinking. It's probably good to be clear about what icar is picking up, and not picking up, from the proposals listed as references. Is improved review as part of the standard approval process in scope or not, for instance? Is 2-LEVEL in scope? Is there any formal role for IAB here? Especially if you're looking for architectural fit as part of early review? I know Alex is the routing AD - are we trying to move from a broadcast LAN in a working group to a routed network of reviewers? I've been following manet for a while, and think self-organizing routed networks is still a research topic :-} Actually, if this is what you are trying to do, it's worth saying so explicitly, because if this is what you're trying to do, we tend to rely on hierarchies for scalability :-{ Spencer > > Please send your replies to the ICAR mailing list (icar@ietf.org). _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Wed Dec 17 08:50:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07394 for ; Wed, 17 Dec 2003 08:50:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWc3w-0002qo-ID for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 08:50:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHDo4JB010952 for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 08:50:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWc3w-0002qZ-4j for icar-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 08:50:04 -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 IAA07361 for ; Wed, 17 Dec 2003 08:50:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWc3u-0003W7-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 08:50:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWc3t-0003W0-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 08:50:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWc3t-0003Vx-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 08:50:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWc3t-0002py-0B; Wed, 17 Dec 2003 08:50:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWc3Z-0002p1-Js for icar@optimus.ietf.org; Wed, 17 Dec 2003 08:49:41 -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 IAA07336 for ; Wed, 17 Dec 2003 08:49:39 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWc3Y-0003UR-00 for icar@ietf.org; Wed, 17 Dec 2003 08:49:40 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWc3W-0003U9-00 for icar@ietf.org; Wed, 17 Dec 2003 08:49:39 -0500 Received: from colt-na165.alcatel.fr ([62.23.212.165] helo=smail.alcatel.fr) by ietf-mx with esmtp (Exim 4.12) id 1AWc3V-0003U6-00 for icar@ietf.org; Wed, 17 Dec 2003 08:49:37 -0500 Received: from bemail05.netfr.alcatel.fr (bemail05.netfr.alcatel.fr [155.132.251.11]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id hBHDnGZq029396; Wed, 17 Dec 2003 14:49:16 +0100 Received: from alcatel.be ([138.203.137.5]) by bemail05.netfr.alcatel.fr (Lotus Domino Release 5.0.11) with ESMTP id 2003121714491364:4087 ; Wed, 17 Dec 2003 14:49:13 +0100 Message-ID: <3FE05F15.8040701@alcatel.be> Date: Wed, 17 Dec 2003 14:50:13 +0100 From: Dimitri.Papadimitriou@alcatel.be User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.5) Gecko/20030925 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin CC: icar@ietf.org Subject: Re: [Icar] Moving on with ICAR: WG formation and charter References: <5991801693.20031209162550@psg.com> In-Reply-To: <5991801693.20031209162550@psg.com> X-MIMETrack: Itemize by SMTP Server on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 12/17/2003 14:49:13, Serialize by Router on BEMAIL05/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 12/17/2003 14:49:15, Serialize complete at 12/17/2003 14:49:15 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii; format=flowed X-Alcanet-MTA-scanned-and-authorized: yes Content-Transfer-Encoding: 7bit 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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.3 required=5.0 tests=NO_REAL_NAME autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit hi, Alex Zinin wrote: > Folks- > > Steven Belovin and I will be taking care of the pre-WG discussion on > ICAR for the IESG. > > Before we go any further, I would like to solicit feedback from the > community on the following points: > > 1. Do you believe that a WG should be formed to work on improving > IETF cross-functional review (see IESG message [Ref1] for more > detail)? yes - and there are some areas where such cross-reviews are becoming of major importance, in particular due to the fact the some wg's are focusing on protocols (ospf, is-is, etc.) vs approaches (mpls, ccamp, pwe3, l2/l3vpn, etc.) wg which themselves gave rise to protocols (to name a few ldp, lmp, etc.) - one can also distinguish two cases here multiple wg's w/i same area and cross-area (w/ multiple wg's) > If so: > > 2. Would you be willing to actively participate in this WG (by > contributing to or reviewing the documents, participating > in the discussions, etc.)? yes > 3. Please review the part in [Ref1] that provides a preliminary > description of the WG and send your comments. The text in the > message is likely to be used for the WG charter if there's > sufficient support to form the WG. what's the scope of the "architectural" problems to be early catched ? are these networking or protocol interaction related, or both and/or any combination ? thanks, - dimitri. > Please send your replies to the ICAR mailing list (icar@ietf.org). > > Thank you. > > Alex Zinin > > ---- > [Ref1] The IESG, "Improving IETF review - further work", 05 Dec 2003 > http://www1.ietf.org/mail-archive/ietf-announce/Current/msg27596.html > > > _______________________________________________ > Icar mailing list > Icar@ietf.org > https://www1.ietf.org/mailman/listinfo/icar -- Papadimitriou Dimitri E-mail : dimitri.papadimitriou@alcatel.be E-mail : dpapadimitriou@psg.com Webpage: http://psg.com/~dpapadimitriou/ Address: Fr. Wellesplein 1, B-2018 Antwerpen, Belgium Phone : +32 3 240-8491 _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Wed Dec 17 09:43:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09318 for ; Wed, 17 Dec 2003 09:43:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWctE-0004Sr-H5 for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 09:43:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHEh4de017155 for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 09:43:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWctE-0004Sc-BA for icar-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 09:43:04 -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 JAA09309 for ; Wed, 17 Dec 2003 09:43:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWctC-00055g-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 09:43:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWctA-00055O-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 09:43:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWctA-00055J-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 09: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 1AWctB-0004Rs-A5; Wed, 17 Dec 2003 09: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 1AWct5-0004Re-Nx for icar@optimus.ietf.org; Wed, 17 Dec 2003 09:42:55 -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 JAA09302 for ; Wed, 17 Dec 2003 09:42:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWct3-00054k-00 for icar@ietf.org; Wed, 17 Dec 2003 09:42:53 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWct2-00054d-00 for icar@ietf.org; Wed, 17 Dec 2003 09:42:52 -0500 Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx with esmtp (Exim 4.12) id 1AWct2-00051s-00 for icar@ietf.org; Wed, 17 Dec 2003 09:42:52 -0500 Received: by newdev.harvard.edu (Postfix, from userid 501) id 3D567A7994; Wed, 17 Dec 2003 09:42:22 -0500 (EST) To: icar@ietf.org Subject: Re: [Icar] Moving on with ICAR: WG formation and charter Message-Id: <20031217144222.3D567A7994@newdev.harvard.edu> Date: Wed, 17 Dec 2003 09:42:22 -0500 (EST) From: sob@harvard.edu (Scott Bradner) 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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 > Steven Belovin and I will be taking care of the pre-WG discussion on > ICAR for the IESG. > > Before we go any further, I would like to solicit feedback from the > community on the following points: > > 1. Do you believe that a WG should be formed to work on improving > IETF cross-functional review (see IESG message [Ref1] for more > detail)? 1/ imho the cross-functional review is one of the main things that makes the IETF "standards" get the industry support that they do- it is a critical part of the IETF process 2/ leaving this review to the IESG-review stage has occasionally meant that major issues show up very late in the game, sometimes after products based on the IDs have begun to ship and produced great annoyance in working groups 3/ thus it would be good to figure out a way to get at least some of the cross-functional review earlier in the development process 4/ working groups have been the traditional way that the IETF has discussed issues of this type 5/ working groups tend to subset the relevent people so that the discussion does not involve all the IETF participants that it should 6/ any work on this topic relates closely to other efforts to rethink parts of the IETF process (changing the WG chair role, newtrk etc) it would seem to be hard to talk about this topic in isolation 7/ a working group might be a reasonable way to proceed as long as the working group had a mandate to work closely with other process change efforts but coordinating the various disussions may be a hard thing to do if they are in seperate WGs 8/ creating a WG to explore this area would not be the worst way to proceed but maybe it would be better to have more of an umbrella WG that deals with all of the change-process topics in one place (like poission used to do) 9/ any working group dealing with the process change issues should not be chaired by an IESG or IAB member anyone who is generally identified by the community as being associated with a particular strong position on the issues > If so: > > 2. Would you be willing to actively participate in this WG (by > contributing to or reviewing the documents, participating > in the discussions, etc.)? yes > 3. Please review the part in [Ref1] that provides a preliminary > description of the WG and send your comments. The text in the > message is likely to be used for the WG charter if there's > sufficient support to form the WG. the text looks fine to me Scott _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Wed Dec 17 12:08:30 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20689 for ; Wed, 17 Dec 2003 12:08:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWf9X-0004t4-1e for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 12:08:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHH83Wk018780 for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 12:08:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWf9W-0004sp-Tm for icar-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 12:08:02 -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 MAA20682 for ; Wed, 17 Dec 2003 12:07:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWf9V-00074Y-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 12:08:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWf9T-00074M-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 12:08:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWf9T-00074E-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 12:07:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWf9U-0004rz-9E; Wed, 17 Dec 2003 12:08:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWf9P-0004rf-CF for icar@optimus.ietf.org; Wed, 17 Dec 2003 12:07:55 -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 MAA20676 for ; Wed, 17 Dec 2003 12:07:52 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWf9O-000749-00 for icar@ietf.org; Wed, 17 Dec 2003 12:07:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWf9N-000742-00 for icar@ietf.org; Wed, 17 Dec 2003 12:07:53 -0500 Received: from measurement-factory.com ([206.168.0.5]) by ietf-mx with esmtp (Exim 4.12) id 1AWf9M-00073z-00 for icar@ietf.org; Wed, 17 Dec 2003 12:07:52 -0500 Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hBHH7qk3007305 for ; Wed, 17 Dec 2003 10:07:52 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hBHH7q9b007304; Wed, 17 Dec 2003 10:07:52 -0700 (MST) (envelope-from rousskov) Date: Wed, 17 Dec 2003 10:07:52 -0700 (MST) From: Alex Rousskov To: icar@ietf.org Subject: Re: [Icar] Moving on with ICAR: WG formation and charter In-Reply-To: <20031216014335.12C943F746@Mail.MAP-NE.com> Message-ID: References: <5991801693.20031209162550@psg.com> <20031216014335.12C943F746@Mail.MAP-NE.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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 On Mon, 15 Dec 2003, Michael A. Patton wrote: > 1. Do you believe that a WG should be formed to work on > improving IETF cross-functional review? No, such a WG should not be formed. Or, at least, such a WG should not be formed now. We might need a WG to improve IETF reviews and review process. Such a WG can only succeed if it has clear understanding of what existing roles and rules it can change as a part of its "review improvement" proposals. At this time, there is no sufficient agreement with regard to Big Picture solutions to provide such a clear understanding in ICAR charter. If chartered, the WG will either waste time on micro-level solutions that are likely to conflict with some Big Picture changes OR will immediately stumble on Big Picture questions such as "how we can enforce early reviews", "how we can make intermediate reviews consistent with the IESG final review without removing IESG from the final review loop", "who has the authority to resolve review conflicts". If the WG is to assume that there are no Big Picture changes, I question the ability of such WG to produce good solutions; many drafts quoted in the proposed charter imply Big Picture changes. Once/if the Big Picture becomes a bit more clear, we can come back and write a good ICAR charter within that Big Picture. [If we want a formal WG now, we can charter a Big Picture WG that will include review improvement as a possible motivation for the big changes. The purpose of that WG would be to engineer IETF Core changes or to conclude that no Core changes are needed.] > 2. Would you be willing to actively participate in this WG (by > contributing to or reviewing the documents, participating in the > discussions, etc.)? Yes, but given the above arguments, I suspect my contribution would be limited to a rather negative review/comments and, hence, may be perceived as unproductive by those who already decided on Big Picture changes or their absence. > 3. Please review the part in [Ref1] that provides a preliminary > description of the WG and send your comments. a) The scope of the WG is unclear or wrong. "Cross-area" scope is too narrow (assuming formal IETF areas are implied). "Cross-functional" scope is undefined in the proposed charter. It is not clear whether "cross-functional" predicate eliminates something useful. b) The playing space for the WG is undefined: it is not clear whether the WG is allowed to propose changes to core IETF processes, rules, and roles and, if yes, which processes/rules/roles are in change scope. c) The charter assumes that "IESG review function" remains mostly unchanged. There is currently no IETF consensus whether that function needs to change, IMO. Even some of the quoted drafts seem to imply significant changes to IESG review function. d) The implied difference between "peer" and "structural" is unclear to me. Define and contrast both terms better since your milestones depend on the difference. Furthermore, an a priory assumption of separation between "peer" and "structural" review may hinder WG creativity. HTH, Alex. P.S. Note that rejection of ICAR WG does not imply that SIR and similar trials should be killed. In fact, IESG should promote and publicize such trials as hard as it can. _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Wed Dec 17 13:21:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24478 for ; Wed, 17 Dec 2003 13:21:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWgID-0000Gx-CI for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 13:21:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHIL5Hv001044 for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 13:21:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWgID-0000Gl-6w for icar-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 13:21:05 -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 NAA24470 for ; Wed, 17 Dec 2003 13:20:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWgI9-0002LE-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 13:21:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWgI8-0002L7-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 13:21:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWgI8-0002L4-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 13:21:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWgI9-0000Fu-0E; Wed, 17 Dec 2003 13:21:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWgHL-0000FF-Uj for icar@optimus.ietf.org; Wed, 17 Dec 2003 13:20:12 -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 NAA24445 for ; Wed, 17 Dec 2003 13:20:05 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWgHH-0002Jh-00 for icar@ietf.org; Wed, 17 Dec 2003 13:20:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWgHG-0002Ja-00 for icar@ietf.org; Wed, 17 Dec 2003 13:20:06 -0500 Received: from measurement-factory.com ([206.168.0.5]) by ietf-mx with esmtp (Exim 4.12) id 1AWgHF-0002JV-00 for icar@ietf.org; Wed, 17 Dec 2003 13:20:05 -0500 Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hBHIK3k3010216; Wed, 17 Dec 2003 11:20:03 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hBHIK3mH010215; Wed, 17 Dec 2003 11:20:03 -0700 (MST) (envelope-from rousskov) Date: Wed, 17 Dec 2003 11:20:03 -0700 (MST) From: Alex Rousskov To: Alex Zinin cc: icar@ietf.org Subject: Re: [Icar] Tagging drafts In-Reply-To: <27100647563.20031216143431@psg.com> Message-ID: References: <20031216021612.E3B0A3F746@Mail.MAP-NE.com> <27100647563.20031216143431@psg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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 On Tue, 16 Dec 2003, Alex Zinin wrote: > Requests for early review should be initiated by the WG chairs, I > believe. Despite the recent trend to make Chairs responsible for everything, I believe that such review requests should be initiated by a document author/editor. The working group must be informed and can object, of course. Document authors/editors must represent WG consensus, not their own will (on any non-editorial issue). The author is the right person to provide additional information and clarifications to reviewers. S/he is also the right person to manage pending issues and inform WG of progress. This approach also solves a problem for documents that do not have a WG and, hence, do not have a WG Chair. We do not need any special exceptions for such documents because they always have authors or editors. Alex. _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Wed Dec 17 14:08:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26872 for ; Wed, 17 Dec 2003 14:08:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWh1g-0002KZ-Qz for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 14:08:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHJ84k2008944 for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 14:08:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWh1f-0002Jv-Gq for icar-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 14:08:03 -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 OAA26860 for ; Wed, 17 Dec 2003 14:08:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWh1d-0004Eu-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 14:08:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWh1c-0004En-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 14:08:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWh1b-0004Ek-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 14:07:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWh1d-0002JF-DE; Wed, 17 Dec 2003 14:08:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWh0o-00026w-Qu for icar@optimus.ietf.org; Wed, 17 Dec 2003 14:07:10 -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 OAA26820 for ; Wed, 17 Dec 2003 14:07:07 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWh0m-0004Cu-00 for icar@ietf.org; Wed, 17 Dec 2003 14:07:08 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWh0k-0004Ci-00 for icar@ietf.org; Wed, 17 Dec 2003 14:07:08 -0500 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 1AWh0k-0004C2-00 for icar@ietf.org; Wed, 17 Dec 2003 14:07:06 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5991338 for icar@ietf.org; Wed, 17 Dec 2003 14:07:02 -0500 Message-Id: <5.1.0.14.0.20031217140123.019a1208@localhost> X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 17 Dec 2003 14:06:57 -0500 To: icar@ietf.org From: "Joel M. Halpern" Subject: Re: [Icar] Tagging drafts In-Reply-To: References: <27100647563.20031216143431@psg.com> <20031216021612.E3B0A3F746@Mail.MAP-NE.com> <27100647563.20031216143431@psg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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 For individual documents, clearly the author is the person who is best able to determine when a review would be helpful. It would seem that for working group documents, the chair is in the best position to state what portions of the document (structure, core ideas and approaches, basic protocol mechanisms, bits on the wire, whole document) reflect working group consensus and should be reviewed. It may even be useful to request a review of something that does not reflect working group consensus (or review of several competing proposals). Even then, it would seem to help the reviewer and the working group if there was a clear and accurate statement of the current status. Another way of looking at this is to ask for whom the review is being done. For working group documents, the review is for the benefit of the working group rather than the benefit of the individual author. One would expect to see reviews requested at times (in terms of process and state of agreement) that will help the working group. The chair ought to be in a good position to make that judgement. And if we can define ways to make it easy for chairs to ask for and receive useful reviews this becomes practical. Yours, Joel M. Halpern At 11:20 AM 12/17/2003 -0700, Alex Rousskov wrote: >On Tue, 16 Dec 2003, Alex Zinin wrote: > > > Requests for early review should be initiated by the WG chairs, I > > believe. > >Despite the recent trend to make Chairs responsible for everything, I >believe that such review requests should be initiated by a document >author/editor. The working group must be informed and can object, of >course. Document authors/editors must represent WG consensus, not >their own will (on any non-editorial issue). > >The author is the right person to provide additional information and >clarifications to reviewers. S/he is also the right person to manage >pending issues and inform WG of progress. > >This approach also solves a problem for documents that do not have a >WG and, hence, do not have a WG Chair. We do not need any special >exceptions for such documents because they always have authors or >editors. > >Alex. > > >_______________________________________________ >Icar mailing list >Icar@ietf.org >https://www1.ietf.org/mailman/listinfo/icar _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Wed Dec 17 15:18:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01352 for ; Wed, 17 Dec 2003 15:18:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWi7P-0005Nb-7z for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 15:18:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHKI3Hw020651 for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 15:18:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWi7P-0005Mx-0M for icar-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 15:18:03 -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 PAA01291 for ; Wed, 17 Dec 2003 15:18:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWi7N-00071M-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 15:18:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWi7M-000716-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 15:18:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWi7M-000713-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 15:18:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWi7M-0005MY-Ie; Wed, 17 Dec 2003 15:18:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWi6f-0005M0-6r for icar@optimus.ietf.org; Wed, 17 Dec 2003 15:17:17 -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 PAA01178 for ; Wed, 17 Dec 2003 15:17:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWi6d-0006wy-00 for icar@ietf.org; Wed, 17 Dec 2003 15:17:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWi6d-0006wr-00 for icar@ietf.org; Wed, 17 Dec 2003 15:17:15 -0500 Received: from measurement-factory.com ([206.168.0.5]) by ietf-mx with esmtp (Exim 4.12) id 1AWi6c-0006wo-00 for icar@ietf.org; Wed, 17 Dec 2003 15:17:14 -0500 Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hBHKHEk3016438; Wed, 17 Dec 2003 13:17:14 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hBHKHEhD016437; Wed, 17 Dec 2003 13:17:14 -0700 (MST) (envelope-from rousskov) Date: Wed, 17 Dec 2003 13:17:14 -0700 (MST) From: Alex Rousskov To: "Joel M. Halpern" cc: icar@ietf.org Subject: Re: [Icar] Tagging drafts In-Reply-To: <5.1.0.14.0.20031217140123.019a1208@localhost> Message-ID: References: <27100647563.20031216143431@psg.com> <20031216021612.E3B0A3F746@Mail.MAP-NE.com> <27100647563.20031216143431@psg.com> <5.1.0.14.0.20031217140123.019a1208@localhost> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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 On Wed, 17 Dec 2003, Joel M. Halpern wrote: > It would seem that for working group documents, the chair is in the > best position to state what portions of the document (structure, > core ideas and approaches, basic protocol mechanisms, bits on the > wire, whole document) reflect working group consensus and should be > reviewed. Many reviews should be solicited when there is no working group consensus. When there is consensus, the author/editor should be able to state it or it she should not be authoring/editing the document. > ... it would seem to help the reviewer and the working group if > there was a clear and accurate statement of the current status. The author/editor should be able to state the current status of his document or he should not be authoring/editing the document. > Another way of looking at this is to ask for whom the review is > being done. For working group documents, the review is for the > benefit of the working group rather than the benefit of the > individual author. One would expect to see reviews requested at > times (in terms of process and state of agreement) that will help > the working group. The chair ought to be in a good position to make > that judgement. The working group, including the chair, can decide that it is time for a review and the author/editor will naturally follow that consensus with a request for review. It is a simple/basic design principle: if the reviewer reviews a document, let the person responsible for that document (author/editor) represent the document. The Chair oversees the whole working group output, the per-document work is (should be) author responsibility. But if we cannot agree on this, we can probably agree that there should be a single point of contact for each document/review. A WG can decide who that point of contact will be. The WG mailing list can always be used if a reviewer wants more exposure/overheads, of course. Alex. P.S. Note that for groups with relatively large number of documents (compared to Chair's spare time), the Chair will easily become a bottleneck if he has to be in the loop for every little action on a document OR the Chair will do a sloppy job on many little actions. _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Wed Dec 17 15:48:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03858 for ; Wed, 17 Dec 2003 15:48:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWiaS-0006S6-RD for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 15:48:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHKm45A024796 for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 15:48:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWiaS-0006RD-Mq for icar-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 15:48:04 -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 PAA03787 for ; Wed, 17 Dec 2003 15:48:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWiaR-000194-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 15:48:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWiaO-00018p-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 15:48:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWiaO-00018h-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 15:48:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWiaP-0006Q1-0L; Wed, 17 Dec 2003 15:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWiaC-0006Pc-1e for icar@optimus.ietf.org; Wed, 17 Dec 2003 15:47:48 -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 PAA03767 for ; Wed, 17 Dec 2003 15:47:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWiaA-00017k-00 for icar@ietf.org; Wed, 17 Dec 2003 15:47:46 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWia9-00017d-00 for icar@ietf.org; Wed, 17 Dec 2003 15:47:46 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AWia9-00017a-00 for icar@ietf.org; Wed, 17 Dec 2003 15:47:45 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AWia8-0002vo-28; Wed, 17 Dec 2003 20:47:44 +0000 Date: Wed, 17 Dec 2003 12:46:15 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <11571753696.20031217124615@psg.com> To: Melinda Shore CC: icar@ietf.org Subject: Re: [Icar] Moving on with ICAR: WG formation and charter In-Reply-To: <8B5C8BAB-3023-11D8-B7AE-000A95E35274@cisco.com> References: <8B5C8BAB-3023-11D8-B7AE-000A95E35274@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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.3 required=5.0 tests=RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Melinda, Tuesday, December 16, 2003, 3:57:02 PM, Melinda Shore wrote: > On Tuesday, December 16, 2003, at 05:57 PM, Alex Zinin wrote: >> To me, it's a question of whether a specific issue is sufficiently >> big, separateable and independent from the rest to benefit from >> dedicated process bandwidth, plus how complex the inter-WG IPC is >> likely to be. > To be honest, I'm not completely clear on what the subject is, or > at least not clear enough to be able to answer the questions you > ask. We've actually got several review problems. I don't think I agree with your categorization of review types, but it's a topic of it's own, so I'm taking this to a separate thread. > ... The cross-area review problem > is a structural/scaling problem and one that I think may > require process or structural changes. That's actually a pretty > big deal and might have broader implications for the kind of > organization we are, whether we're bottom-up/volunteer/etc. or > we're more top-down/authoritarian. This discussion needs to > continue to involve the entire organization (or those who are > interested, anyway). I'm not sure that we can talk about this in > isolation from questions about area boards, etc. My understanding is that questions like "area boards" would be exactly within the scope of ICAR. On the issue of "isolation". Creating a WG helps scoping the discussion, setting focused goals, etc., but it does not lock out the rest of the organization. In other words, we would not be creating a closed group of people to discuss a problem without paying attention to the rest of the issues, but rather providing a forum for the community to discuss a subset of issues. If it turns out that process or structural changes are needed, we could represent them in the form of recommendations that would then be discussed within the context of a bigger picture. > At the same time, in watching some of the debates that we're having > about organizational change it looks to me like there's a tendency > to deadlock over issues like making sure that we've got authority > structures that match our responsibility structures, and it's > interfering with our ability to make progress. At some point we have > to rely on the good will of the participants, and if we don't have > that we're hosed, anyway. I'm not opposed to the creation of a > working group but I think that if one is created (and this is true > of other "improvement" efforts, as well) 1) the partipants, or at the > very least the chairs and the responsible AD, need to be committed to > the possibility that the outcome might be to maintain the status quo, > and 2) we may need to be a little non-traditional about how we ratify > its output, which is something that needs a lot of further discussion. I think this is reasonable, though I personally think it's unlikely that the output will be something like "we're fine here, no changes needed". I do see how the existing process could remain unchanged and some clarifications and suggestions made to improve it within the current framework. > A nit on the specific proposal: it's not clear to me that "peer-to- > peer" reviews are the right answer, and in the context of the IETF I'm > not even sure what "peer" means. More generally, I think I'd be happy > never to see the phrase "peer to peer" again. Let's try to figure out > what the actual review problem(s) is/are that need to be addressed and > use words that describe those. OK, let's take this to the other thread I'll start. Thanks. Alex _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Wed Dec 17 15:48:38 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03889 for ; Wed, 17 Dec 2003 15:48:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWiaY-0006SX-4D for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 15:48:10 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHKmAA8024823 for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 15:48:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWiaY-0006SI-0U for icar-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 15:48:10 -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 PAA03785 for ; Wed, 17 Dec 2003 15:48:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWiaQ-000191-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 15:48:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWiaO-00018k-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 15:48:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWiaO-00018g-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 15:48:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWiaP-0006QB-5W; Wed, 17 Dec 2003 15:48:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWiaK-0006Ph-TV for icar@optimus.ietf.org; Wed, 17 Dec 2003 15:47:56 -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 PAA03778 for ; Wed, 17 Dec 2003 15:47:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWiaJ-00018R-00 for icar@ietf.org; Wed, 17 Dec 2003 15:47:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWiaI-00018J-00 for icar@ietf.org; Wed, 17 Dec 2003 15:47:55 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AWiaI-00018E-00 for icar@ietf.org; Wed, 17 Dec 2003 15:47:54 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AWiaH-0002wc-Js for icar@ietf.org; Wed, 17 Dec 2003 20:47:53 +0000 Date: Wed, 17 Dec 2003 12:46:24 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <13271763570.20031217124624@psg.com> To: icar@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Subject: [Icar] Review types and associated issues 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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.3 required=5.0 tests=RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Tuesday, December 16, 2003, 3:57:02 PM, Melinda Shore wrote: > To be honest, I'm not completely clear on what the subject is, or > at least not clear enough to be able to answer the questions you > ask. We've actually got several review problems. One is early > review and another is cross-area review (there are others, but > I think these are the most pressing). We might disagree on specific terms while agreeing on the substance, but here's the dimensions along which the reviews are separated within the IETF, I believe: 1. Whom it is performed by and why: I think we have two types here: a) individuals, reviewing documents not because they have an obligation within the IETF structure to do so, but because they are interested in this. In other words, this is a good-will type of review, which is what I called "unstructured" or "peer-to-peer". b) ADs (with directorates), IESG reviewing documents because they are held responsible within the IETF to review the documents in a timely manner. This review happens as a result of a formal IETF standards procedure and there is a structured process around it. This is what I call "structured" review. 2. When it is performed: a) Late--happening at the end of the life-cycle of the document, essentially what we have as the IESG review today. b) Early--happening before the ideas are crystallized or at least before the WG is finished with the doc. This is what we have happening in the WGs today. 3. Technology coverage: a) Functional--covering the primary technology, without paying a lot of attention to affects on other pieces of the system or other aspects such as security. Unfortunately, this is often what happens within the WG. b) Cross-functional--covering a wide spectrum of technologies and keeping in mind their interactions. IESG review would be an example. So we have at least 3 dimensions here. Currently, the IETF review is focused around two spots: 1. {unstructured, early, functional} 2. {structured, late, x-func}. My thinking is that we need to improve both such that we have: 1. {unstructured, early, func | x-func} 2. {structured, early | late, x-func} in other words, we should encourage early cross-functional review by individuals, plus we should improve structured review so that requesting it early in the process scales well. I am open to other models, but this seems to reflect the reality as I see it today. > Failures in these areas have > overlapping but somewhat different results, in that early review > (i.e. review against the charter, or review for quality within the > charter) failures tend to allow the working group to produce bad results > while cross-area review failures can lead to work that's incoherent > in the broader context, work that's substantially the same as > work in another area, and so on. > > Some of what's been discussed or experimented with already, like > SIRS, has tended to focus on the early review problem, but I'm inclined > to think that can be solved with a bigger hammer (making better use of > WG > technical advisors, for example). It seems that SIRS falls under {unstruct, early, x-func} category, while use of TAs is a more structured process. I.e., these are different types of review, and it seems that one should not preclude the other. -- Alex http://www.psg.com/~zinin/ _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Wed Dec 17 15:59:57 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04965 for ; Wed, 17 Dec 2003 15:59:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWilS-0006xc-Db for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 15:59:26 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHKxQf5026750 for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 15:59:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWilS-0006xN-7c for icar-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 15:59:26 -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 PAA04894 for ; Wed, 17 Dec 2003 15:59:23 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWilQ-0001we-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 15:59:24 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWilN-0001vk-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 15:59:24 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AWilM-0001va-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 15:59:21 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AWik5-0004YJ-Hx for icar-web-archive@ietf.org; Wed, 17 Dec 2003 15:58:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWik5-0006vT-4q; Wed, 17 Dec 2003 15:58:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWiju-0006vF-Jr for icar@optimus.ietf.org; Wed, 17 Dec 2003 15:57:51 -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 PAA04818 for ; Wed, 17 Dec 2003 15:57:48 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWijt-0001tF-00 for icar@ietf.org; Wed, 17 Dec 2003 15:57:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWijr-0001t0-00 for icar@ietf.org; Wed, 17 Dec 2003 15:57:48 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AWijr-0001ss-00 for icar@ietf.org; Wed, 17 Dec 2003 15:57:47 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AWijq-0004fi-VM; Wed, 17 Dec 2003 20:57:47 +0000 Date: Wed, 17 Dec 2003 12:56:16 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <3272354950.20031217125616@psg.com> To: "Spencer Dawkins" CC: icar@ietf.org Subject: Re: [Icar] Moving on with ICAR: WG formation and charter In-Reply-To: <026f01c3c497$cf935170$0400a8c0@DFNJGL21> References: <5991801693.20031209162550@psg.com> <026f01c3c497$cf935170$0400a8c0@DFNJGL21> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Spencer, >> 1. Do you believe that a WG should be formed to work on improving >> IETF cross-functional review (see IESG message [Ref1] for more >> detail)? > Well... I think cross-functional review is a good thing (duh), but am > confused about the relationship between icar and other review > improvements (SIR/CARD, AIR/CREW, ART, 2-LEVEL ...). The things that > worry me are: > - fragmentation of efforts to improve reviews (early, late, > cross-area, peer-to-peer vs formal approval, etc.). I think there is > enough energy in the IETF to improve the way we do reviews, but not > enough to do a bunch of parallel discussion ("you are in a maze of > twisty passages, all alike"). I'm also curious about interactions > between proposals these efforts put forward. > - I thought Ted Hardie's description of the "Ambulance Syndrome" in > http://www.alvestrand.no/ietf/nov2003-minneapolis/iesg-overview.pdf > was a critical problem to solve, and didn't see this addressed in icar > yet (or anywhere else). Not to be blunt, but I can take more > "sponsored" time to contribute solicited reviews in a SIR/CARD or > AIR/CREW framework than just replying to a general call for cross-area > review on a mailing list. OK, I sense some confusion here. The idea is not that ICAR would actually _perform_ cross-functional reviews, thus improving document quality. ICAR would be the place to discuss _how_ to improve it, including the discussion of those many proposals we have (SIR, CREW, ART, etc.), as well as the ambulance syndrome. >> If so: >> >> 2. Would you be willing to actively participate in this WG (by >> contributing to or reviewing the documents, participating >> in the discussions, etc.)? > Sure, but this is competing for my time and energy with at least > newtrk and mpowr, at least for me. Duh! :) > I'll probably contribute to the > efforts that seem to be moving forward. Progress is good. >> >> 3. Please review the part in [Ref1] that provides a preliminary >> description of the WG and send your comments. The text in the >> message is likely to be used for the WG charter if there's >> sufficient support to form the WG. > "Peer-to-peer" isn't described anywhere, so you're counting on > everyone having the same understanding of what you're thinking. ok, my bad. see the new thread I started, it should help explain my terminology. > It's probably good to be clear about what icar is picking up, and not > picking up, from the proposals listed as references. Is improved > review as part of the standard approval process in scope or not, for > instance? Is 2-LEVEL in scope? I think at this stage we should be open for any proposals > Is there any formal role for IAB here? Especially if you're looking > for architectural fit as part of early review? Formal role within the WG or as part of the improved review process? I'm not aware of any as far as the former is concerned. > I know Alex is the routing AD - are we trying to move from a broadcast > LAN in a working group to a routed network of reviewers? I've been > following manet for a while, and think self-organizing routed networks > is still a research topic :-} Actually, if this is what you are trying > to do, it's worth saying so explicitly, because if this is what you're > trying to do, we tend to rely on hierarchies for scalability :-{ Nice one ;) Again, seems the new thread on review types should help. Using your analogy though, I think the goal should be to encourage paying more attention to the traffic on the broadcast segment, AND improve scalability of the router network so we can push more traffic through it. My frank opinion regarding improving the former (broadcast or unstructured review) is that it cuts into the area of motivation and incentive, and we as the organization can only do so much here by making sure people find required information easier, maybe give more credits, etc. I personally do not know how to make sure more people "care about the Internet" more... Alex _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Wed Dec 17 16:01:37 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05092 for ; Wed, 17 Dec 2003 16:01:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWin7-0007Ae-4Q for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 16:01:09 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHL18mQ027558 for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 16:01:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWin6-0007AP-MQ for icar-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 16:01:08 -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 QAA05080 for ; Wed, 17 Dec 2003 16:01:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWin5-00021S-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:01:07 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWin4-00021L-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:01:06 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AWin3-00021I-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:01:06 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AWin4-0004cC-2k for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:01:06 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWin1-00079Y-Qz; Wed, 17 Dec 2003 16:01:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWims-00078c-Aj for icar@optimus.ietf.org; Wed, 17 Dec 2003 16:00:54 -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 QAA05040 for ; Wed, 17 Dec 2003 16:00:47 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWiml-000211-00 for icar@ietf.org; Wed, 17 Dec 2003 16:00:48 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWiml-00020u-00 for icar@ietf.org; Wed, 17 Dec 2003 16:00:47 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AWimk-00020r-00 for icar@ietf.org; Wed, 17 Dec 2003 16:00:47 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AWimk-0005Md-Gt; Wed, 17 Dec 2003 21:00:46 +0000 Date: Wed, 17 Dec 2003 12:59:15 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <5372533748.20031217125915@psg.com> To: Dimitri.Papadimitriou@alcatel.be CC: icar@ietf.org Subject: Re: [Icar] Moving on with ICAR: WG formation and charter In-Reply-To: <3FE05F15.8040701@alcatel.be> References: <5991801693.20031209162550@psg.com> <3FE05F15.8040701@alcatel.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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.3 required=5.0 tests=RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Dimitri, Thanks for your input. Answer below. Wednesday, December 17, 2003, 5:50:13 AM, Dimitri.Papadimitriou@alcatel.be wrote: [...] > what's the scope of the "architectural" problems to be early catched ? > are these networking or protocol interaction related, or both and/or > any combination ? This is a broad term that we probably want to leave undefined, but that implies effects on and interactions between different parts of the Internet or mechanisms/protocols used in IP networks, scalability, stability, security characteristics, etc. Alex _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Wed Dec 17 16:02:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05130 for ; Wed, 17 Dec 2003 16:02:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWio2-0007Cp-4w for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 16:02:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHL26fm027693 for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 16:02:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWio2-0007Ca-0I for icar-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 16:02:06 -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 QAA05120 for ; Wed, 17 Dec 2003 16:02:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWio0-00023q-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:02:04 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWinz-00023j-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:02:04 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AWinz-00023g-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:02:03 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AWinz-0004dj-6y for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:02:03 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWinx-0007C0-Mn; Wed, 17 Dec 2003 16:02:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWins-0007Bh-9B for icar@optimus.ietf.org; Wed, 17 Dec 2003 16:01:56 -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 QAA05111 for ; Wed, 17 Dec 2003 16:01:53 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWinq-00023Q-00 for icar@ietf.org; Wed, 17 Dec 2003 16:01:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWinp-00023I-00 for icar@ietf.org; Wed, 17 Dec 2003 16:01:54 -0500 Received: from measurement-factory.com ([206.168.0.5]) by ietf-mx with esmtp (Exim 4.12) id 1AWinp-00023F-00 for icar@ietf.org; Wed, 17 Dec 2003 16:01:53 -0500 Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hBHL1rk3018457; Wed, 17 Dec 2003 14:01:53 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hBHL1rKJ018456; Wed, 17 Dec 2003 14:01:53 -0700 (MST) (envelope-from rousskov) Date: Wed, 17 Dec 2003 14:01:53 -0700 (MST) From: Alex Rousskov To: Alex Zinin cc: icar@ietf.org Subject: Re: [Icar] Review types and associated issues In-Reply-To: <13271763570.20031217124624@psg.com> Message-ID: References: <13271763570.20031217124624@psg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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 On Wed, 17 Dec 2003, Alex Zinin wrote: > It seems that SIRS falls under {unstruct, early, x-func} category Since SIRs are elected with a specific mandate and responsibility to review documents, would not they be categorized as "structured"? Or do we need a third category? Thanks for the definitions! Please copy them to the charter, if any. Alex. -- a) individuals, reviewing documents not because they have an obligation within the IETF structure to do so, but because they are interested in this. In other words, this is a good-will type of review, which is what I called "unstructured" or "peer-to-peer". b) ADs (with directorates), IESG reviewing documents because they are held responsible within the IETF to review the documents in a timely manner. This review happens as a result of a formal IETF standards procedure and there is a structured process around it. This is what I call "structured" review. _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Wed Dec 17 16:04:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05195 for ; Wed, 17 Dec 2003 16:04:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWipv-0007Fh-5L for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 16:04:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHL43I6027871 for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 16:04:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWipv-0007FS-1P for icar-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 16:04:03 -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 QAA05186 for ; Wed, 17 Dec 2003 16:04:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWipt-00026c-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:04:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWips-00026T-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:04:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWips-00026Q-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:04:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWipt-0007Ej-4b; Wed, 17 Dec 2003 16:04:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWipM-0007DW-4T for icar@optimus.ietf.org; Wed, 17 Dec 2003 16:03:28 -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 QAA05171 for ; Wed, 17 Dec 2003 16:03:25 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWipK-00025g-00 for icar@ietf.org; Wed, 17 Dec 2003 16:03:26 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWipJ-00025Z-00 for icar@ietf.org; Wed, 17 Dec 2003 16:03:26 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AWipJ-00025W-00 for icar@ietf.org; Wed, 17 Dec 2003 16:03:25 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AWipI-0005u4-NL; Wed, 17 Dec 2003 21:03:24 +0000 Date: Wed, 17 Dec 2003 13:01:53 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <15072691845.20031217130153@psg.com> To: sob@harvard.edu (Scott Bradner) CC: icar@ietf.org Subject: Re: [Icar] Moving on with ICAR: WG formation and charter In-Reply-To: <20031217144222.3D567A7994@newdev.harvard.edu> References: <20031217144222.3D567A7994@newdev.harvard.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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.3 required=5.0 tests=RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Scott, Thanks for the input. BTW, you are the second person whom I hear from about some sort of coordination/umbrella group to tie the pieces together. Do you think something like a directorate be a good idea, or do we also need a "bigger picture" WG? -- Alex http://www.psg.com/~zinin/ Wednesday, December 17, 2003, 6:42:22 AM, Scott Bradner wrote: >> Steven Belovin and I will be taking care of the pre-WG discussion on >> ICAR for the IESG. >> >> Before we go any further, I would like to solicit feedback from the >> community on the following points: >> >> 1. Do you believe that a WG should be formed to work on improving >> IETF cross-functional review (see IESG message [Ref1] for more >> detail)? > 1/ imho the cross-functional review is one of the main things that > makes the IETF "standards" get the industry support that they do- > it is a critical part of the IETF process > 2/ leaving this review to the IESG-review stage has occasionally meant > that major issues show up very late in the game, sometimes after > products based on the IDs have begun to ship and produced great > annoyance in working groups > 3/ thus it would be good to figure out a way to get at least some of > the cross-functional review earlier in the development process > 4/ working groups have been the traditional way that the IETF has > discussed issues of this type > 5/ working groups tend to subset the relevent people so that the > discussion does not involve all the IETF participants that it should > 6/ any work on this topic relates closely to other efforts to rethink > parts of the IETF process (changing the WG chair role, newtrk etc) > it would seem to be hard to talk about this topic in isolation > 7/ a working group might be a reasonable way to proceed as long as > the working group had a mandate to work closely with other > process change efforts but coordinating the various disussions > may be a hard thing to do if they are in seperate WGs > 8/ creating a WG to explore this area would not be the worst way > to proceed but maybe it would be better to have more of an > umbrella WG that deals with all of the change-process topics > in one place (like poission used to do) > 9/ any working group dealing with the process change issues should > not be chaired by > an IESG or IAB member > anyone who is generally identified by the community as being > associated with a particular strong position on the issues >> If so: >> >> 2. Would you be willing to actively participate in this WG (by >> contributing to or reviewing the documents, participating >> in the discussions, etc.)? > yes >> 3. Please review the part in [Ref1] that provides a preliminary >> description of the WG and send your comments. The text in the >> message is likely to be used for the WG charter if there's >> sufficient support to form the WG. > the text looks fine to me > Scott > _______________________________________________ > Icar mailing list > Icar@ietf.org > https://www1.ietf.org/mailman/listinfo/icar _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Wed Dec 17 16:13:12 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05682 for ; Wed, 17 Dec 2003 16:13:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWiyK-0007m0-7W for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 16:12:44 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHLCiqU029879 for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 16:12:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWiyK-0007lq-3U for icar-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 16:12:44 -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 QAA05638 for ; Wed, 17 Dec 2003 16:12:41 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWiyI-0002TK-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:12:42 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWiyC-0002SW-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:12:41 -0500 Received: from [65.246.255.50] (helo=manatick) by ietf-mx with esmtp (Exim 4.12) id 1AWilZ-0001va-01 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 15:59:33 -0500 Received: from optimus22.ietf.org ([132.151.6.22] helo=optimus.ietf.org) by manatick with esmtp (Exim 4.24) id 1AWibV-0004Sr-8i for icar-web-archive@ietf.org; Wed, 17 Dec 2003 15:49:20 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWibM-0006Tm-IZ; Wed, 17 Dec 2003 15:49:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWib4-0006Sl-2I for icar@optimus.ietf.org; Wed, 17 Dec 2003 15:48:42 -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 PAA03883 for ; Wed, 17 Dec 2003 15:48:35 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWiax-0001Bz-00 for icar@ietf.org; Wed, 17 Dec 2003 15:48:35 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWial-0001Au-00 for icar@ietf.org; Wed, 17 Dec 2003 15:48:31 -0500 Received: from f070.brocade.com ([66.243.153.70] helo=blasphemy.brocade.com) by ietf-mx with esmtp (Exim 4.12) id 1AWiak-00017y-00 for icar@ietf.org; Wed, 17 Dec 2003 15:48:22 -0500 Received: from hq-ex-3.corp.brocade.com (hq-ex-3 [192.168.38.35]) by blasphemy.brocade.com (Postfix) with ESMTP id 9D02814171; Wed, 17 Dec 2003 12:47:50 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C3C4DF.08F93CEE" Subject: RE: [Icar] Moving on with ICAR: WG formation and charter Date: Wed, 17 Dec 2003 12:47:50 -0800 Message-ID: X-MS-Has-Attach: yes Thread-Topic: [Icar] Moving on with ICAR: WG formation and charter Thread-Index: AcPEwGCivkktispKSkq4zdFavsufHgAHJ15A From: "Robert Snively" To: "Alex Rousskov" , 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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 This is a multi-part message in MIME format. ------_=_NextPart_001_01C3C4DF.08F93CEE Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I second Alex's concerns. Given a separation of technical review and process review and the formalization of a self-consistent and monitored process like those I have suggested in previous mails, the cross-functional review is trivial and built in. Without some sort of Big Picture changes, cross-functional review will at best be spotty and will probably overwhelm some sub-set of the participants. Since ICAR has not yet seen my suggestions, I am enclosing the most specific of them for you to target as you choose. Bob Snively 408-333-8135 > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] > Sent: Wednesday, December 17, 2003 9:08 AM > To: icar@ietf.org > Subject: Re: [Icar] Moving on with ICAR: WG formation and charter >=20 >=20 > On Mon, 15 Dec 2003, Michael A. Patton wrote: >=20 > > 1. Do you believe that a WG should be formed to work on > > improving IETF cross-functional review? >=20 > No, such a WG should not be formed. > Or, at least, such a WG should not be formed now. >=20 > We might need a WG to improve IETF reviews and review process. Such a > WG can only succeed if it has clear understanding of what existing > roles and rules it can change as a part of its "review improvement" > proposals. At this time, there is no sufficient agreement with regard > to Big Picture solutions to provide such a clear understanding in ICAR > charter. >=20 > If chartered, the WG will either waste time on micro-level solutions > that are likely to conflict with some Big Picture changes OR will > immediately stumble on Big Picture questions such as "how we can > enforce early reviews", "how we can make intermediate reviews > consistent with the IESG final review without removing IESG from the > final review loop", "who has the authority to resolve review > conflicts". If the WG is to assume that there are no Big Picture > changes, I question the ability of such WG to produce good solutions; > many drafts quoted in the proposed charter imply Big Picture changes. >=20 > Once/if the Big Picture becomes a bit more clear, we can come back and > write a good ICAR charter within that Big Picture. >=20 > [If we want a formal WG now, we can charter a Big Picture WG that will > include review improvement as a possible motivation for the big > changes. The purpose of that WG would be to engineer IETF Core changes > or to conclude that no Core changes are needed.] >=20 > > 2. Would you be willing to actively participate in this WG (by > > contributing to or reviewing the documents, participating in the > > discussions, etc.)? >=20 > Yes, but given the above arguments, I suspect my contribution would be > limited to a rather negative review/comments and, hence, may be > perceived as unproductive by those who already decided on Big Picture > changes or their absence. >=20 > > 3. Please review the part in [Ref1] that provides a preliminary > > description of the WG and send your comments. >=20 > a) The scope of the WG is unclear or wrong. "Cross-area" scope is too > narrow (assuming formal IETF areas are implied). "Cross-functional" > scope is undefined in the proposed charter. It is not clear > whether "cross-functional" predicate eliminates something useful. >=20 > b) The playing space for the WG is undefined: it is not clear whether > the WG is allowed to propose changes to core IETF processes, rules, > and roles and, if yes, which processes/rules/roles are in change > scope. >=20 > c) The charter assumes that "IESG review function" remains mostly > unchanged. There is currently no IETF consensus whether that > function needs to change, IMO. Even some of the quoted drafts > seem to imply significant changes to IESG review function. >=20 > d) The implied difference between "peer" and "structural" is unclear > to me. Define and contrast both terms better since your milestones > depend on the difference. Furthermore, an a priory assumption of > separation between "peer" and "structural" review may hinder WG > creativity. >=20 > HTH, >=20 > Alex. >=20 > P.S. Note that rejection of ICAR WG does not imply that SIR and > similar trials should be killed. In fact, IESG should promote > and publicize such trials as hard as it can. >=20 > _______________________________________________ > Icar mailing list > Icar@ietf.org > https://www1.ietf.org/mailman/listinfo/icar >=20 >=20 ------_=_NextPart_001_01C3C4DF.08F93CEE Content-Type: message/rfc822 X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: RE: [Solutions] lets back up a step Date: Wed, 26 Nov 2003 09:47:27 -0800 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Solutions] lets back up a step Thread-Index: AcOz+M4lcto7t3x/SCq7o5thwKt31AAQBm3A From: "Robert Snively" To: "Keith Moore" , "Alex Rousskov" , "Pekka Savola" Cc: , "Robert Snively" Content-Transfer-Encoding: quoted-printable Keith and Alex, Your thoughts are right on target. One possible approach to this is to have a well understood process executed by the working group during their=20 collaboration. Such a process should have clearly defined and mandatory check points, with clear requirements to be=20 met at each checkpoint. At the same time it should allow a maximum of flexibility in the development process and working group culture, including the choice of guided or unguided e-mail discussions, phone and video conferences, and interim=20 face-to-face meetings. Public archival of agendas, minutes,=20 and talking-paper proposals not mature enough (or perhaps=20 not in the right format) for internet drafts is also=20 necessary. As a possible example: 1) Proposal for project: Collaborate to specify a project proposal that clearly scopes the activity and defines the external points of contact and expert liaison that must be achieved to complete the project. It also defines the compliance points that must be verified, including security and proper architectural layering with related documents. The proposal itself should be consented to in a manner similar to 3 below, so that everyone knows what is being worked on and agrees to it. =20 2) Develop the draft The working group should have great flexibility, facilitated by the wg chair, to develop this. Since the expert liaison and external points of contact have been identified and warned that such a project is going on, they are likely to provide at least some support during this development process. The chair may have to add additional interaction points as the draft develops. 3) Poll the working group and liaisons for consensus The last call process is kind of a pass at this, but there are often dozens of folks who participated in the development, but do not respond to last call. This may be because they trust that others will do it, or it may because their mailboxes were full that week. There should be some kind of mechanism (some would call it "membership") that requires a response, like a balloting pool. The personal responsibility for responding focuses attention on the document in a very constructive manner. This is really just formalizing the last call process. 4) Resolve comments This is really a continuation of the development collaboration, but with the certainty that every known liaison and balloting pool member has done a useful review of the document. This may take as long as the original document development. 5) Approve the resolutions This is in the nature of a recirculation ballot. It may point to the need to go back and resolve more comments, but usually not. The recirculation process should be similar to step 3. Perhaps restricting the ballot pool to those who responded in step 3 would provide motivation for more complete review at step 3. At this point, you should have a pretty good document, one that the IESG or AD could probably not improve on. If they were able to improve on it and were interested in the subject, they should have been part of the liaison and balloting pool. 6) Wide-spread review process At this point another widely announced review process run by the central authority is useful, since the project=20 proposal's scope may have missed some interactions with=20 nominally unrelated technologies. This should be announced widely (say in one of the Standards journals). My experience is that comments at this stage are very unusual, but when they occur, they are almost always extremely important. This is the point at which the AD or IESG can say "halt, go back" if real technical issues have crept through both the liaison and review processes. They would be just=20 another of the public reviewers. The corrections of course would go back to step 4 in the working group, causing great embarrassment to the chair :-) 7) Procedural review in parallel with public review process The central authority in parallel can go through the check boxes and if necessary the document archives (including documented comment resolutions and perhaps other documents) and see=20 that the process was completed correctly. =20 Then presto, you have a fully collaborative and flexible development and review environment and at the same time a well understood and rigorous set of check points that force early and wide oversight of the documents resulting in excellent standards. Well, mostly, since stuff still happens. What does this do for rough consensus and running code? Running code often begins before the first balloting check point, so problems discovered are fed back in that time frame. Those few comments identified during the central authority's public review process are also often part of the running code verification. People often do not identify all the=20 weaknesses in a document's language until they do try to implement it.=20 The rough consensus is really made a bit stronger than before,=20 since the flexible collaboration is performed within the skeleton of formal review checkpoints with rigorous requirements.=20 And of course, for any widely used document, new interpretations and functions will be desired, so revisions will flow naturally as new projects. This process would produce nice clean standards track RFC's=20 and provide a solid basis for their promotion to internet standards. Weaker procedures for other types of documents could be created. Bob Snively rsnively@brocade.com 408-333-8135 > -----Original Message----- > From: Alex Rousskov [mailto:rousskov@measurement-factory.com] >... > I suspect that we cannot delete or move the function of a top-level > enforcer. There has to be some external control and it has to come > from the top level. However, we can probably make it so that it takes > relatively little effort and time for the top-level authority to make > a determination: >=20 > - The Authority must not review documents; instead, > it must make sure submitted documents have received > sufficient number of quality external reviews. >=20 > - The Authority must not negotiate how reviewer > comments can be addressed; instead, it must check > how they were addressed. >=20 > - The Authority must not spend endless cycles requesting > additional reviews and clarifications; instead, > it should reject any partial submission (i.e., submission > without sufficient number of quality external reviews or > without an easy-to-digest list of reviewer-identified > issues, how they were addressed by the WG, and what the > reviewer final reaction was after the WG addressed the > issues). >=20 > - The Authority has a well-defined limit on the amount of > time it spends making a decision. >=20 > - The Working Group is responsible for soliciting external > reviews and addressing reviewer comments, all prior to the final > submission to the Authority. >=20 > - IETF provides tools and mechanisms to efficiently > solicit external reviews and track issues, among other > things. >=20 > In short, a working group does all the work, while the Authority has a > straightforward function of looking at vital checkboxes and issuing a > verdict. The Authority has a veto, but it is mostly a procedural-based > veto; virtually all technical work is done before the Authority gets > the document. > -----Original Message----- > From: Keith Moore [mailto:moore@cs.utk.edu] > .... > We also need for such reviews to be made in a timely fashion=20 > - i.e. well > before the design is frozen. >=20 > > Today, IESG/ADs essentially decide what external (including=20 > their own) > > comments are valid and enforce their application. It often takes a > > long time for IESG/ADs to review, negotiate, and to issue a verdict. > > This creates a bottleneck and causes both WGs and IESG/ADs to be > > sloppy. >=20 > Looking deeper, often the "bottleneck" results, at least=20 > partially, from > IESG trying to fix serious problems with a protocol so late in the > process. In some sense this could be viewed as trying to use the wrong > tool for the job. Right now, IESG's main tool for=20 > encouraging sanity is > withholding final approval of the document. This works okay if only > small changes are needed to the protocol or the text, but often IESG > ends up trying to fix big problems with small changes. Even worse, > often the AD is expected to specify those changes - so the AD ends up > having to second-guess large chunks of the design. It's no surprise > that this takes a long time, but somehow I doubt that giving WGs more > autonomy is the answer. Insisting that WGs do development in stages, > and that they solicit and respond to widespread review (including from > IESG) at several of those stages, might help. =20 > ...... > >=20 > > - The Authority must not review documents; instead, > > it must make sure submitted documents have received > > sufficient number of quality external reviews. >=20 > I strongly disagree. We will still need a way to fix bad designs that > manage to get through the process. Our goal needs to be to=20 > minimize the > number of bad designs that get to the final approval stage=20 > (i.e. to fix > them sooner) - or to put it another way, to ensure that when documents > get to the final approval stage there is already a high level of > confidence in those documents both inside and outside the WG. >=20 > > - The Authority must not spend endless cycles requesting > > additional reviews and clarifications; instead, > > it should reject any partial submission (i.e., submission > > without sufficient number of quality external reviews or > > without an easy-to-digest list of reviewer-identified > > issues, how they were addressed by the WG, and what the > > reviewer final reaction was after the WG addressed the > > issues). >=20 > I certainly think that IESG should summarily reject any document that=20 > doesn't have the required documentation, and that there should be=20 > clear (or at least pre-established) criteria for such summary=20 > rejection. > On the other hand, if IESG identifies a problem at a late=20 > date, it still > has a duty to investigate that problem via additional reviews or=20 > clarifications if necessary. >=20 > > - The Authority has a well-defined limit on the amount of > > time it spends making a decision. >=20 > This is pretty much the case already. The problem is, people=20 > want IESG > to decide "yes" within that amount of time (or at worst, "yes if you > make these minor changes that we specify completely"), and that's not=20 > always realistic. =20 >=20 > > In short, a working group does all the work, while the=20 > Authority has a > > straightforward function of looking at vital checkboxes and=20 > issuing a > > verdict. The Authority has a veto, but it is mostly a=20 > procedural-based > > veto; virtually all technical work is done before the Authority gets > > the document. >=20 > I'd certainly like to see things get to the point that "virtually all > technical work is done before the Authority gets the=20 > document" for final > approval, but the IESG still must be able to reject or remand=20 > documents > on technical grounds, rather than merely procedural grounds. =20 >=20 > As a practical matter it's already very difficult for the IESG to push > back significantly on a WG effort; an effort with additional support=20 > in the form of reviews and responses would make such pushback even > more difficult. That's fine. I also believe that if such reviews > became commonplace, in the (hopefully rare) occassion that IESG did=20 > see the need to push back, it would be easier to "fix" the=20 > protocol than > it often is now, because the protocol would have been more thoroughly > sanity-checked and less likely to completely overlook some important > consideration. >=20 >=20 ------_=_NextPart_001_01C3C4DF.08F93CEE-- _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Wed Dec 17 16:14:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05752 for ; Wed, 17 Dec 2003 16:14:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWizb-0007oM-Rn for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 16:14:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHLE35Y030020 for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 16:14:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWizb-0007o7-NT for icar-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 16:14:03 -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 QAA05743 for ; Wed, 17 Dec 2003 16:14:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWiza-0002Ya-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:14:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWizY-0002YP-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:14:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWizY-0002YM-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:14:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWizZ-0007nO-FB; Wed, 17 Dec 2003 16:14:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWiz8-0007mv-Ao for icar@optimus.ietf.org; Wed, 17 Dec 2003 16:13:34 -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 QAA05714 for ; Wed, 17 Dec 2003 16:13:31 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWiz6-0002WW-00 for icar@ietf.org; Wed, 17 Dec 2003 16:13:32 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWiz5-0002WP-00 for icar@ietf.org; Wed, 17 Dec 2003 16:13:32 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AWiz5-0002WK-00 for icar@ietf.org; Wed, 17 Dec 2003 16:13:31 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AWiz4-0006lo-AI; Wed, 17 Dec 2003 21:13:30 +0000 Date: Wed, 17 Dec 2003 13:11:56 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <2473295463.20031217131156@psg.com> To: Alex Rousskov CC: "Joel M. Halpern" , icar@ietf.org Subject: Re: [Icar] Tagging drafts In-Reply-To: References: <27100647563.20031216143431@psg.com> <20031216021612.E3B0A3F746@Mail.MAP-NE.com> <27100647563.20031216143431@psg.com> <5.1.0.14.0.20031217140123.019a1208@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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.3 required=5.0 tests=RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alex, Joel- Do we have two issues mixed up here? It seems that theres is a question of who makes the call that the document is ready for the x-func review, and a question of who keeps track of the issues, etc. I think it would be reasonable to have the WG chairs do the former (it is their job to detect consensus on specific subjects), and have the authors/editors do the latter. -- Alex http://www.psg.com/~zinin/ Wednesday, December 17, 2003, 12:17:14 PM, Alex Rousskov wrote: > On Wed, 17 Dec 2003, Joel M. Halpern wrote: >> It would seem that for working group documents, the chair is in the >> best position to state what portions of the document (structure, >> core ideas and approaches, basic protocol mechanisms, bits on the >> wire, whole document) reflect working group consensus and should be >> reviewed. > Many reviews should be solicited when there is no working group > consensus. When there is consensus, the author/editor should be able > to state it or it she should not be authoring/editing the document. >> ... it would seem to help the reviewer and the working group if >> there was a clear and accurate statement of the current status. > The author/editor should be able to state the current status of his > document or he should not be authoring/editing the document. >> Another way of looking at this is to ask for whom the review is >> being done. For working group documents, the review is for the >> benefit of the working group rather than the benefit of the >> individual author. One would expect to see reviews requested at >> times (in terms of process and state of agreement) that will help >> the working group. The chair ought to be in a good position to make >> that judgement. > The working group, including the chair, can decide that it is time for > a review and the author/editor will naturally follow that consensus > with a request for review. > It is a simple/basic design principle: if the reviewer reviews a > document, let the person responsible for that document (author/editor) > represent the document. The Chair oversees the whole working group > output, the per-document work is (should be) author responsibility. > But if we cannot agree on this, we can probably agree that there > should be a single point of contact for each document/review. A WG can > decide who that point of contact will be. The WG mailing list can > always be used if a reviewer wants more exposure/overheads, of course. > Alex. > P.S. Note that for groups with relatively large number of documents > (compared to Chair's spare time), the Chair will easily become a > bottleneck if he has to be in the loop for every little action on > a document OR the Chair will do a sloppy job on many little > actions. > _______________________________________________ > Icar mailing list > Icar@ietf.org > https://www1.ietf.org/mailman/listinfo/icar _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Wed Dec 17 16:22:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06006 for ; Wed, 17 Dec 2003 16:22:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWj7L-0007xO-HJ for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 16:22:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHLM3H2030580 for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 16:22:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWj7K-0007x9-J8 for icar-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 16:22:02 -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 QAA05973 for ; Wed, 17 Dec 2003 16:21:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWj7I-0002ms-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:22:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWj7H-0002ml-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:22:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWj7H-0002mi-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:21:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWj7I-0007wD-7l; Wed, 17 Dec 2003 16:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWj6X-0007vm-97 for icar@optimus.ietf.org; Wed, 17 Dec 2003 16:21:13 -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 QAA05937 for ; Wed, 17 Dec 2003 16:21:10 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWj6V-0002kp-00 for icar@ietf.org; Wed, 17 Dec 2003 16:21:11 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWj6T-0002ka-00 for icar@ietf.org; Wed, 17 Dec 2003 16:21:11 -0500 Received: from measurement-factory.com ([206.168.0.5]) by ietf-mx with esmtp (Exim 4.12) id 1AWj6T-0002kX-00 for icar@ietf.org; Wed, 17 Dec 2003 16:21:09 -0500 Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hBHLL9k3019382; Wed, 17 Dec 2003 14:21:09 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hBHLL9xX019381; Wed, 17 Dec 2003 14:21:09 -0700 (MST) (envelope-from rousskov) Date: Wed, 17 Dec 2003 14:21:09 -0700 (MST) From: Alex Rousskov To: Alex Zinin cc: "Joel M. Halpern" , icar@ietf.org Subject: Re: [Icar] Tagging drafts In-Reply-To: <2473295463.20031217131156@psg.com> Message-ID: References: <27100647563.20031216143431@psg.com> <20031216021612.E3B0A3F746@Mail.MAP-NE.com> <27100647563.20031216143431@psg.com> <5.1.0.14.0.20031217140123.019a1208@localhost> <2473295463.20031217131156@psg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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 agree that there can be a separation of roles here. I suggest that the authors are in better position to do both. Hmm... This may be an example of Big Picture issues in the way. If IETF has just a few document management steps like it has today, then WG Chair can call the document "ready" without much problems. If we adopt a more dynamic/flexible model with many semi-formal steps, it would be wise to offload a lot of *per-document* functions to authors/editors/designated-persons to avoid the Chair bottleneck. You may have the few-rigid-steps model in mind. That is why tasking the Chair sounds more reasonable to you. Alex. On Wed, 17 Dec 2003, Alex Zinin wrote: > Alex, Joel- > > Do we have two issues mixed up here? > > It seems that theres is a question of who makes the call that the > document is ready for the x-func review, and a question of who keeps > track of the issues, etc. I think it would be reasonable to have the > WG chairs do the former (it is their job to detect consensus on > specific subjects), and have the authors/editors do the latter. > > -- > Alex > http://www.psg.com/~zinin/ > > Wednesday, December 17, 2003, 12:17:14 PM, Alex Rousskov wrote: > > > On Wed, 17 Dec 2003, Joel M. Halpern wrote: > > >> It would seem that for working group documents, the chair is in the > >> best position to state what portions of the document (structure, > >> core ideas and approaches, basic protocol mechanisms, bits on the > >> wire, whole document) reflect working group consensus and should be > >> reviewed. > > > Many reviews should be solicited when there is no working group > > consensus. When there is consensus, the author/editor should be able > > to state it or it she should not be authoring/editing the document. > > >> ... it would seem to help the reviewer and the working group if > >> there was a clear and accurate statement of the current status. > > > The author/editor should be able to state the current status of his > > document or he should not be authoring/editing the document. > > >> Another way of looking at this is to ask for whom the review is > >> being done. For working group documents, the review is for the > >> benefit of the working group rather than the benefit of the > >> individual author. One would expect to see reviews requested at > >> times (in terms of process and state of agreement) that will help > >> the working group. The chair ought to be in a good position to make > >> that judgement. > > > The working group, including the chair, can decide that it is time for > > a review and the author/editor will naturally follow that consensus > > with a request for review. > > > It is a simple/basic design principle: if the reviewer reviews a > > document, let the person responsible for that document (author/editor) > > represent the document. The Chair oversees the whole working group > > output, the per-document work is (should be) author responsibility. > > > But if we cannot agree on this, we can probably agree that there > > should be a single point of contact for each document/review. A WG can > > decide who that point of contact will be. The WG mailing list can > > always be used if a reviewer wants more exposure/overheads, of course. > > > Alex. > > > P.S. Note that for groups with relatively large number of documents > > (compared to Chair's spare time), the Chair will easily become a > > bottleneck if he has to be in the loop for every little action on > > a document OR the Chair will do a sloppy job on many little > > actions. > > > _______________________________________________ > > Icar mailing list > > Icar@ietf.org > > https://www1.ietf.org/mailman/listinfo/icar > > _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Wed Dec 17 16:24:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06195 for ; Wed, 17 Dec 2003 16:24:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWj9H-000887-N6 for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 16:24:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHLO3HE031245 for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 16:24:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWj9H-00087s-Jb for icar-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 16:24:03 -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 QAA06153 for ; Wed, 17 Dec 2003 16:24:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWj9F-0002vC-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:24:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWj9E-0002uy-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:24:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWj9E-0002uv-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:24:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWj9F-000878-6T; Wed, 17 Dec 2003 16:24:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWj8a-00086S-Ic for icar@optimus.ietf.org; Wed, 17 Dec 2003 16:23:20 -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 QAA06122 for ; Wed, 17 Dec 2003 16:23:17 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWj8Y-0002tw-00 for icar@ietf.org; Wed, 17 Dec 2003 16:23:18 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWj8X-0002tp-00 for icar@ietf.org; Wed, 17 Dec 2003 16:23:18 -0500 Received: from ns.execdsl.net ([208.184.15.238] helo=EXECDSL.COM) by ietf-mx with esmtp (Exim 4.12) id 1AWj8X-0002tl-00 for icar@ietf.org; Wed, 17 Dec 2003 16:23:17 -0500 Received: from [64.254.114.114] (HELO JLaptop.stevecrocker.com) by EXECDSL.COM (CommuniGate Pro SMTP 3.3) with ESMTP id 5991826 for icar@ietf.org; Wed, 17 Dec 2003 16:23:17 -0500 Message-Id: <5.1.0.14.0.20031217162219.01ab7008@localhost> X-Sender: joel@stevecrocker.com@localhost X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 17 Dec 2003 16:23:11 -0500 To: icar@ietf.org From: "Joel M. Halpern" Subject: Re: [Icar] Tagging drafts In-Reply-To: <2473295463.20031217131156@psg.com> References: <27100647563.20031216143431@psg.com> <20031216021612.E3B0A3F746@Mail.MAP-NE.com> <27100647563.20031216143431@psg.com> <5.1.0.14.0.20031217140123.019a1208@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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 That would seem to be a reasonable split / assignment to me. Joel At 01:11 PM 12/17/2003 -0800, Alex Zinin wrote: >Alex, Joel- > > Do we have two issues mixed up here? > > It seems that theres is a question of who makes the call that the > document is ready for the x-func review, and a question of who keeps > track of the issues, etc. I think it would be reasonable to have the > WG chairs do the former (it is their job to detect consensus on > specific subjects), and have the authors/editors do the latter. > >-- >Alex >http://www.psg.com/~zinin/ > >Wednesday, December 17, 2003, 12:17:14 PM, Alex Rousskov wrote: > > > On Wed, 17 Dec 2003, Joel M. Halpern wrote: > > >> It would seem that for working group documents, the chair is in the > >> best position to state what portions of the document (structure, > >> core ideas and approaches, basic protocol mechanisms, bits on the > >> wire, whole document) reflect working group consensus and should be > >> reviewed. > > > Many reviews should be solicited when there is no working group > > consensus. When there is consensus, the author/editor should be able > > to state it or it she should not be authoring/editing the document. > > >> ... it would seem to help the reviewer and the working group if > >> there was a clear and accurate statement of the current status. > > > The author/editor should be able to state the current status of his > > document or he should not be authoring/editing the document. > > >> Another way of looking at this is to ask for whom the review is > >> being done. For working group documents, the review is for the > >> benefit of the working group rather than the benefit of the > >> individual author. One would expect to see reviews requested at > >> times (in terms of process and state of agreement) that will help > >> the working group. The chair ought to be in a good position to make > >> that judgement. > > > The working group, including the chair, can decide that it is time for > > a review and the author/editor will naturally follow that consensus > > with a request for review. > > > It is a simple/basic design principle: if the reviewer reviews a > > document, let the person responsible for that document (author/editor) > > represent the document. The Chair oversees the whole working group > > output, the per-document work is (should be) author responsibility. > > > But if we cannot agree on this, we can probably agree that there > > should be a single point of contact for each document/review. A WG can > > decide who that point of contact will be. The WG mailing list can > > always be used if a reviewer wants more exposure/overheads, of course. > > > Alex. > > > P.S. Note that for groups with relatively large number of documents > > (compared to Chair's spare time), the Chair will easily become a > > bottleneck if he has to be in the loop for every little action on > > a document OR the Chair will do a sloppy job on many little > > actions. > > > _______________________________________________ > > Icar mailing list > > Icar@ietf.org > > https://www1.ietf.org/mailman/listinfo/icar _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Wed Dec 17 16:26:03 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06232 for ; Wed, 17 Dec 2003 16:26:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjAl-0008AH-RJ for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 16:25:35 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHLPZWn031379 for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 16:25:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjAl-0008A1-Lw for icar-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 16:25:35 -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 QAA06214 for ; Wed, 17 Dec 2003 16:25:32 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWjAe-0002yJ-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:25:29 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWjAE-0002xw-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:25:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWjAE-0002xp-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:25:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjAF-00089F-Bz; Wed, 17 Dec 2003 16:25:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWj9j-00088L-MR for icar@optimus.ietf.org; Wed, 17 Dec 2003 16:24:31 -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 QAA06193 for ; Wed, 17 Dec 2003 16:24:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWj9h-0002xL-00 for icar@ietf.org; Wed, 17 Dec 2003 16:24:30 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWj9h-0002xC-00 for icar@ietf.org; Wed, 17 Dec 2003 16:24:29 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AWj9g-0002x6-00 for icar@ietf.org; Wed, 17 Dec 2003 16:24:28 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AWj9g-0007hS-Ub; Wed, 17 Dec 2003 21:24:29 +0000 Date: Wed, 17 Dec 2003 13:22:53 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <15673952257.20031217132253@psg.com> To: Alex Rousskov CC: icar@ietf.org Subject: Re: [Icar] Review types and associated issues In-Reply-To: References: <13271763570.20031217124624@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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.3 required=5.0 tests=RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alex, >> It seems that SIRS falls under {unstruct, early, x-func} category > Since SIRs are elected with a specific mandate and responsibility to > review documents, would not they be categorized as "structured"? Or do > we need a third category? I knew that was coming ;) I guess the exact definition would be recruiting individuals at large who perform unstruct review into a new structure that gives them responsibility and credits. I.e. SIRS changes the struct/unstruct property, which is fine as long as reviews happen. > Thanks for the definitions! Please copy them to the charter, if any. Or maybe someone with English better than mine could come up with terms that are intuitively understood, so we don't have to inflate the charter to the size of a tutorial. Alex _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Wed Dec 17 16:36:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06821 for ; Wed, 17 Dec 2003 16:36:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjKv-0008Ta-Kz for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 16:36:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHLa5lQ032576 for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 16:36:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjKv-0008TL-GV for icar-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 16:36:05 -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 QAA06759 for ; Wed, 17 Dec 2003 16:36:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWjKt-0003Ij-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:36:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWjKs-0003IT-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:36:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWjKs-0003IQ-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:36:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjKt-0008SC-7a; Wed, 17 Dec 2003 16:36:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjKL-0008Ql-IB for icar@optimus.ietf.org; Wed, 17 Dec 2003 16:35:29 -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 QAA06701 for ; Wed, 17 Dec 2003 16:35:26 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWjKJ-0003GL-00 for icar@ietf.org; Wed, 17 Dec 2003 16:35:27 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWjKI-0003GE-00 for icar@ietf.org; Wed, 17 Dec 2003 16:35:27 -0500 Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1AWjKI-0003GB-00 for icar@ietf.org; Wed, 17 Dec 2003 16:35:26 -0500 Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.24; FreeBSD) id 1AWjKH-0009FD-Ph; Wed, 17 Dec 2003 21:35:25 +0000 Date: Wed, 17 Dec 2003 13:33:48 -0800 From: Alex Zinin X-Mailer: The Bat! (v1.62i) Personal Reply-To: Alex Zinin X-Priority: 3 (Normal) Message-ID: <5474606788.20031217133348@psg.com> To: Alex Rousskov CC: "Joel M. Halpern" , icar@ietf.org Subject: Re: [Icar] Tagging drafts In-Reply-To: References: <27100647563.20031216143431@psg.com> <20031216021612.E3B0A3F746@Mail.MAP-NE.com> <27100647563.20031216143431@psg.com> <5.1.0.14.0.20031217140123.019a1208@localhost> <2473295463.20031217131156@psg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alex, > I agree that there can be a separation of roles here. > I suggest that the authors are in better position to do both. I think the question of "who gauges consensus" would inevitably get in the way then... > Hmm... This may be an example of Big Picture issues in the way. If > IETF has just a few document management steps like it has today, then > WG Chair can call the document "ready" without much problems. If we > adopt a more dynamic/flexible model with many semi-formal steps, it > would be wise to offload a lot of *per-document* functions to > authors/editors/designated-persons to avoid the Chair bottleneck. > You may have the few-rigid-steps model in mind. That is why tasking > the Chair sounds more reasonable to you. May I suggest that we start approaching the problem with the current snapshot of reality as given? As ideas on changes within the WGs crystallize, we will resync as necessary. My gut feeling is that the substance of how to improve the reviews will remain the same and changing the interfaces shouldn't be very painful. Alex _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Wed Dec 17 16:37:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA06947 for ; Wed, 17 Dec 2003 16:37:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjLu-00007a-Lq for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 16:37:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHLb5Gc000460 for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 16:37:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjLt-00007L-IX for icar-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 16:37:05 -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 QAA06905 for ; Wed, 17 Dec 2003 16:37:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWjLr-0003OJ-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:37:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWjLo-0003Nx-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:37:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWjLo-0003Nu-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:37:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjLp-00005m-O4; Wed, 17 Dec 2003 16:37:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjLK-0008Ud-CS for icar@optimus.ietf.org; Wed, 17 Dec 2003 16:36:30 -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 QAA06815 for ; Wed, 17 Dec 2003 16:36:27 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWjLI-0003Ku-00 for icar@ietf.org; Wed, 17 Dec 2003 16:36:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWjLH-0003Ke-00 for icar@ietf.org; Wed, 17 Dec 2003 16:36:28 -0500 Received: from adsl-68-76-113-50.dsl.bcvloh.ameritech.net ([68.76.113.50] helo=guns.icir.org) by ietf-mx with esmtp (Exim 4.12) id 1AWjLG-0003Hx-00 for icar@ietf.org; Wed, 17 Dec 2003 16:36:27 -0500 Received: from guns.icir.org (localhost [127.0.0.1]) by guns.icir.org (Postfix) with ESMTP id 7492C77A704; Wed, 17 Dec 2003 16:35:55 -0500 (EST) To: Alex Zinin From: Mark Allman Reply-To: mallman@icir.org Cc: Alex Rousskov , "Joel M. Halpern" , icar@ietf.org Subject: Re: [Icar] Tagging drafts In-Reply-To: <2473295463.20031217131156@psg.com> Organization: ICSI Center for Internet Research (ICIR) Song-of-the-Day: Whole Lotta Love Date: Wed, 17 Dec 2003 16:35:55 -0500 Message-Id: <20031217213555.7492C77A704@guns.icir.org> 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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 Alex**2- > It seems that theres is a question of who makes the call that the > document is ready for the x-func review, and a question of who keeps > track of the issues, etc. I think it would be reasonable to have the > WG chairs do the former (it is their job to detect consensus on > specific subjects), and have the authors/editors do the latter. Isn't this a whole ton of quibbling? I would think the editors and chairs should be in pretty good agreement about when something needs some particular kind of review. And, I would think that editors need to keep close track of comments. But, chairs also need to keep track of the issues to judge consensus and keep an idea about what sorts of outstanding issues are hanging around. And, it seems to me if the editors and the chairs need to keep roughly on the same page then who cares who tags the draft or the email or whatever? Aren't there bigger fish to fry? allman -- Mark Allman -- ICIR -- http://www.icir.org/mallman/ _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Wed Dec 17 16:55:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA07731 for ; Wed, 17 Dec 2003 16:55:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjdI-0000vD-Ui for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 16:55:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBHLt4Of003537 for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 16:55:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjdI-0000uy-QM for icar-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 16:55:04 -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 QAA07682 for ; Wed, 17 Dec 2003 16:55:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWjdG-000431-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:55:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWjdF-00042Z-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:55:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWjdF-00042W-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 16:55:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjdG-0000ts-2V; Wed, 17 Dec 2003 16:55:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWjcY-0000sa-Mi for icar@optimus.ietf.org; Wed, 17 Dec 2003 16:54:18 -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 QAA07601 for ; Wed, 17 Dec 2003 16:54:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWjcW-0003zE-00 for icar@ietf.org; Wed, 17 Dec 2003 16:54:16 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWjcV-0003z7-00 for icar@ietf.org; Wed, 17 Dec 2003 16:54:16 -0500 Received: from measurement-factory.com ([206.168.0.5]) by ietf-mx with esmtp (Exim 4.12) id 1AWjcV-0003z4-00 for icar@ietf.org; Wed, 17 Dec 2003 16:54:15 -0500 Received: from measurement-factory.com (localhost [127.0.0.1]) by measurement-factory.com (8.12.9/8.12.9) with ESMTP id hBHLsFk3020763; Wed, 17 Dec 2003 14:54:15 -0700 (MST) (envelope-from rousskov@measurement-factory.com) Received: (from rousskov@localhost) by measurement-factory.com (8.12.9/8.12.9/Submit) id hBHLsFhe020762; Wed, 17 Dec 2003 14:54:15 -0700 (MST) (envelope-from rousskov) Date: Wed, 17 Dec 2003 14:54:15 -0700 (MST) From: Alex Rousskov To: Alex Zinin cc: "Joel M. Halpern" , icar@ietf.org Subject: Re: [Icar] Tagging drafts In-Reply-To: <5474606788.20031217133348@psg.com> Message-ID: References: <27100647563.20031216143431@psg.com> <20031216021612.E3B0A3F746@Mail.MAP-NE.com> <27100647563.20031216143431@psg.com> <5.1.0.14.0.20031217140123.019a1208@localhost> <2473295463.20031217131156@psg.com> <5474606788.20031217133348@psg.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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 On Wed, 17 Dec 2003, Alex Zinin wrote: > May I suggest that we start approaching the problem with the current > snapshot of reality as given? As ideas on changes within the WGs > crystallize, we will resync as necessary. If the rough consensus is that the reality is unlikely to change much, we should indeed start approaching the problem with the current reality as given. If the rough consensus is that the reality needs to change significantly, we will be wasting our time solving problems with the wrong assumptions in mind. I do not know whether there is rough consensus regarding _probability_ of Big Picture changes at this point. And I am guessing we have no Chair to gauge it, since we have no Big Picture WG. > My gut feeling is that the substance of how to improve the reviews > will remain the same and changing the interfaces shouldn't be very > painful. I agree that the substance (if I am guessing what you mean by that correctly) is unlikely to change, but I am afraid that the devil (and 80% of the work) is in the enforcement and procedural details (i.e., interfaces and roles). Alex. _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Wed Dec 17 19:42:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16198 for ; Wed, 17 Dec 2003 19:42:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWmEu-0007Dg-Ed for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 19:42:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBI0g4JK027746 for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 19:42:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWmEu-0007DR-0l for icar-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 19:42:04 -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 TAA16180 for ; Wed, 17 Dec 2003 19:42:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWmEs-0002bM-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 19:42:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWmEq-0002b5-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 19:42:02 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWmEq-0002b2-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 19:42:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWmEq-0007D2-RG; Wed, 17 Dec 2003 19:42:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWmED-0007Cg-QV for icar@optimus.ietf.org; Wed, 17 Dec 2003 19:41:21 -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 TAA16176 for ; Wed, 17 Dec 2003 19:41:18 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWmEC-0002a5-00 for icar@ietf.org; Wed, 17 Dec 2003 19:41:20 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWmEB-0002Zy-00 for icar@ietf.org; Wed, 17 Dec 2003 19:41:19 -0500 Received: from transfire.txc.com ([208.5.237.254] helo=pguin2.txc.com) by ietf-mx with esmtp (Exim 4.12) id 1AWmEA-0002Zv-00 for icar@ietf.org; Wed, 17 Dec 2003 19:41:18 -0500 Received: from txc.com ([172.17.0.134]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id hBI0fF014837; Wed, 17 Dec 2003 19:41:15 -0500 Message-ID: <3FE0F7AA.1090006@txc.com> Date: Wed, 17 Dec 2003 19:41:14 -0500 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Alex Zinin CC: Alex Rousskov , "Joel M. Halpern" , icar@ietf.org Subject: Re: [Icar] Tagging drafts References: <27100647563.20031216143431@psg.com> <20031216021612.E3B0A3F746@Mail.MAP-NE.com> <27100647563.20031216143431@psg.com> <5.1.0.14.0.20031217140123.019a1208@localhost> <2473295463.20031217131156@psg.com> In-Reply-To: <2473295463.20031217131156@psg.com> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms000100000503000209020206" 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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 This is a cryptographically signed message in MIME format. --------------ms000100000503000209020206 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit I think it is also important to make a separation between technical aspects and managerial aspects of the WG chair role in regards to the document reviewing. I think it is the latter that should be considered, while the former should be prohibited, in the current situation, where I think there is a serious mixup and problem in IETF - one can say direct violation of RFC 2418 - with WG chairs being also involved with WG document editing. Regards, Alex C. Alex Zinin wrote: > Alex, Joel- > > Do we have two issues mixed up here? > > It seems that theres is a question of who makes the call that the > document is ready for the x-func review, and a question of who keeps > track of the issues, etc. I think it would be reasonable to have the > WG chairs do the former (it is their job to detect consensus on > specific subjects), and have the authors/editors do the latter. > --------------ms000100000503000209020206 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINqDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBR0wggSGoAMCAQICEAxYaM16ATcjBamVuftCOMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMxMDA3MDAw MDAwWhcNMDQxMDA2MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKQWxleCBDb250YTEdMBsGCSqGSIb3 DQEJARYOYWNvbnRhQHR4Yy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4 Ft6Hpfel8VTHHZ+/IL7CrN4JZuNiEG0jbHIdZ6p4fIhVYpLiSK57oEE8WooVkMCwJxbd1kja BR8eLKwmMatpnaW661HjOjZaZaWHuj1k+/I7ZKcPKHHk2V++wAz5lIrJEYXm5Swbqq+wz3Xu zBt1K3gRU+5AIeBbxD1H5yOShhuS8KMD3xh7XIpNu8KufVCzWAbLcto/oBAaXH9iXrdZ/fRZ ibQhNldCYSHv8zHt8uYMUs5AlL8TTEsEsx+Zrfhr4/dZWmnCBVLyMxFX3apwUq4onjmAeDmn MOzxlqp5kO/FJlUK5KHPvNYMnkA75zLGfONTZmnsc7nybpMta3YVAgMBAAGjggE4MIIBNDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMAYKYIZIAYb4RQEG BwQiFiAyNTMxNjE3MDc0YTVhNTU3OTNjN2U4NDI2NjEyNTAyNjAzBgNVHR8ELDAqMCigJqAk hiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GB ALIvzgvKUG1MgnjGt+pKACDHwud9y2gSne3lNmmfl9wzLNsSH+32cSUyVgKoQQ0hxKslfgQd xiJQ5PAQPCc2bA6SKJTYiaBE0aWnqGpLTNN4OUKTX3KXEBsxrCP2Tzjj6cm1ghHl12Z8IF1n VRdwTiGeuDVhv0bHVRJkJyFt0tFOMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjAN BgkqhkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZDAeFw0wMzEwMDcwMDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIu TFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGln aXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4 IENvbnRhMR0wGwYJKoZIhvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJI rnugQTxaihWQwLAnFt3WSNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77A DPmUiskRheblLBuqr7DPde7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNY Bsty2j+gEBpcf2Jet1n99FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIF UvIzEVfdqnBSriieOYB4Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1r dhUCAwEAAaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEH AQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYB BQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAu IGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQE AwIHgDAwBgpghkgBhvhFAQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2 MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww DQYJKoZIhvcNAQEEBQADgYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf 7fZxJTJWAqhBDSHEqyV+BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGs I/ZPOOPpybWCEeXXZnwgXWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4xggSqMIIEpgIBATCB4TCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQDFhozXoBNyMF qZW5+0I4wjAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMzEyMTgwMDQxMTRaMCMGCSqGSIb3DQEJBDEWBBRAOWoZeJYwsQycDTl2 ExJcfiULeTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJKwYBBAGCNxAEMYHk MIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJ bmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3Mg MSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjN egE3IwWplbn7QjjCMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3 dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFRE KGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3Jp YmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0B AQEFAASCAQBEuJAAHEs10dFk8azZAa0VaXs8AJNqKFB4qgunpjHO4rYSpGSrT5OkVuwXMwYx HnbTyNMegr75xW2IDDXYzRLAsupKLvNdKsiSEVeny67qxwY2zLc5PnOXV8bSi0Y3PruuFXC/ KZ9nTpsC7Cbysn6K0hUJDxnXYPK4Z0zEM4xx0M6sBIB0xAkPBNLzebM4akJHRQYMFaSyvliM uCU5VjWWfnykgv9L+NFJcavgjOgWsg2ZP0dFqzAryBSvmoyMAmkZE7Evl7YDdpVVDTdlN2Qy +g4RnugOt+qtvaIyIVu1S4S8Ai9F0DCzBuqlotQw43eiOmcDttGlRFYA3k0XcWfWAAAAAAAA --------------ms000100000503000209020206-- _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Wed Dec 17 19:58:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16614 for ; Wed, 17 Dec 2003 19:58:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWmUM-0007WF-Aa for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 19:58:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBI0w2A1028897 for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 19:58:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWmUM-0007W0-3O for icar-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 19:58:02 -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 TAA16607 for ; Wed, 17 Dec 2003 19:58:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWmUK-0002xg-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 19:58:00 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWmUJ-0002xZ-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 19:57:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWmUJ-0002xW-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 19:57:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWmUK-0007Vc-Bw; Wed, 17 Dec 2003 19:58:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWmTd-0007VF-Ad for icar@optimus.ietf.org; Wed, 17 Dec 2003 19:57:17 -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 TAA16599 for ; Wed, 17 Dec 2003 19:57:15 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWmTb-0002x0-00 for icar@ietf.org; Wed, 17 Dec 2003 19:57:15 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWmTa-0002wt-00 for icar@ietf.org; Wed, 17 Dec 2003 19:57:15 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1AWmTa-0002wA-00 for icar@ietf.org; Wed, 17 Dec 2003 19:57:14 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.10/8.12.10) with ESMTP id hBI0uiIx024068; Wed, 17 Dec 2003 16:56:44 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.12.10/8.12.8/Submit) id hBI0uiGw024067; Wed, 17 Dec 2003 16:56:44 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Wed, 17 Dec 2003 16:56:44 -0800 From: David Meyer To: Alex Conta Cc: Alex Zinin , Alex Rousskov , "Joel M. Halpern" , icar@ietf.org Subject: Re: [Icar] Tagging drafts Message-ID: <20031218005644.GA24014@1-4-5.net> References: <27100647563.20031216143431@psg.com> <20031216021612.E3B0A3F746@Mail.MAP-NE.com> <27100647563.20031216143431@psg.com> <5.1.0.14.0.20031217140123.019a1208@localhost> <2473295463.20031217131156@psg.com> <3FE0F7AA.1090006@txc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FE0F7AA.1090006@txc.com> User-Agent: Mutt/1.4i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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 Alex, On Wed, Dec 17, 2003 at 07:41:14PM -0500, Alex Conta wrote: >> I think it is also important to make a separation between technical >> aspects and managerial aspects of the WG chair role in regards to the >> document reviewing. >> >> I think it is the latter that should be considered, while the former >> should be prohibited, in the current situation, where I think there is a >> serious mixup and problem in IETF - one can say direct violation of RFC >> 2418 - with WG chairs being also involved with WG document editing. Is this really a direct violation of 2418? Section 6.3 (Document Editor) says: As a general practice, the Working Group Chair and Document Editor positions are filled by different individuals to help ensure that the resulting documents accurately reflect the consensus of the working group and that all processes are followed. While the spirit of section 6.3 seems clear enough, it does not (apparently) mandate that the positions be filled by different people. Rather, it seems to say that it would be "better" if it were possible to fill the positions with different individuals (my words). Or is there a different section of 2418 that you are referring to? Thanks, Dave _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Wed Dec 17 21:15:34 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18376 for ; Wed, 17 Dec 2003 21:15:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWngw-0001Hm-8X for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 21:15:06 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBI2F6ff004936 for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 21:15:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWngw-0001HX-1i for icar-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 21:15:06 -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 VAA18369 for ; Wed, 17 Dec 2003 21:15:03 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWngt-0004Zh-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 21:15:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWngs-0004Za-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 21:15:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWngs-0004ZX-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 21:15:02 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWngt-0001H6-2e; Wed, 17 Dec 2003 21:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWngM-0001GX-Vg for icar@optimus.ietf.org; Wed, 17 Dec 2003 21:14:30 -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 VAA18360 for ; Wed, 17 Dec 2003 21:14:28 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWngK-0004Z2-00 for icar@ietf.org; Wed, 17 Dec 2003 21:14:28 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWngJ-0004Yv-00 for icar@ietf.org; Wed, 17 Dec 2003 21:14:27 -0500 Received: from sccrmhc11.comcast.net ([204.127.202.55]) by ietf-mx with esmtp (Exim 4.12) id 1AWngJ-0004YS-00 for icar@ietf.org; Wed, 17 Dec 2003 21:14:27 -0500 Received: from dfnjgl21 (c-24-1-97-129.client.comcast.net[24.1.97.129]) by comcast.net (sccrmhc11) with SMTP id <2003121802135501100il0f6e> (Authid: sdawkins@comcast.net); Thu, 18 Dec 2003 02:13:55 +0000 Message-ID: <031001c3c50c$99131570$0400a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: References: <5991801693.20031209162550@psg.com> <026f01c3c497$cf935170$0400a8c0@DFNJGL21> <3272354950.20031217125616@psg.com> Subject: Re: [Icar] Moving on with ICAR: WG formation and charter Date: Wed, 17 Dec 2003 20:13:58 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Alex, My bad, also. What I actually meant to say was "between anything icar PROPOSES and other review improvements", but you couldn't tell that from the way my fingers betrayed me on the keyboard ("really, I'm much smarter than my e-mail would lead you to believe ..."). Spencer ----- Original Message ----- > > >> 1. Do you believe that a WG should be formed to work on improving > >> IETF cross-functional review (see IESG message [Ref1] for more > >> detail)? > > > Well... I think cross-functional review is a good thing (duh), but am > > confused about the relationship between icar and other review > > improvements (SIR/CARD, AIR/CREW, ART, 2-LEVEL ...). The things that > > worry me are: > > OK, I sense some confusion here. > > The idea is not that ICAR would actually _perform_ cross-functional > reviews, thus improving document quality. ICAR would be the place > to discuss _how_ to improve it, including the discussion of those > many proposals we have (SIR, CREW, ART, etc.), as well as the > ambulance syndrome. If icar owns the ambulance syndrome problem, please include this in the charter. It is not a small consideration. Thanks, Spencer _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Wed Dec 17 22:22:29 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA20158 for ; Wed, 17 Dec 2003 22:22:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWoji-0003P5-Jf for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 22:22:02 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBI3M2wR013077 for icar-archive@odin.ietf.org; Wed, 17 Dec 2003 22:22:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWoji-0003Oq-Fl for icar-web-archive@optimus.ietf.org; Wed, 17 Dec 2003 22:22:02 -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 WAA20151 for ; Wed, 17 Dec 2003 22:21:58 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWojf-00064U-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 22:21:59 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWoje-00064N-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 22:21:59 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWoje-00064K-00 for icar-web-archive@ietf.org; Wed, 17 Dec 2003 22:21:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWojg-0003Of-KP; Wed, 17 Dec 2003 22:22:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWojV-0003OS-IH for icar@optimus.ietf.org; Wed, 17 Dec 2003 22:21:49 -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 WAA20147 for ; Wed, 17 Dec 2003 22:21:44 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWojR-00064G-00 for icar@ietf.org; Wed, 17 Dec 2003 22:21:45 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWojQ-000649-00 for icar@ietf.org; Wed, 17 Dec 2003 22:21:44 -0500 Received: from sccrmhc12.comcast.net ([204.127.202.56]) by ietf-mx with esmtp (Exim 4.12) id 1AWojQ-00063g-00 for icar@ietf.org; Wed, 17 Dec 2003 22:21:44 -0500 Received: from dfnjgl21 (c-24-1-97-129.client.comcast.net[24.1.97.129]) by comcast.net (sccrmhc12) with SMTP id <2003121803211301200r6tg0e> (Authid: sdawkins@comcast.net); Thu, 18 Dec 2003 03:21:13 +0000 Message-ID: <04cc01c3c515$ffdc2b30$0400a8c0@DFNJGL21> Reply-To: "Spencer Dawkins" From: "Spencer Dawkins" To: References: <20031217144222.3D567A7994@newdev.harvard.edu> <15072691845.20031217130153@psg.com> Subject: Re: [Icar] Moving on with ICAR: WG formation and charter Date: Wed, 17 Dec 2003 21:21:16 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Content-Transfer-Encoding: 7bit 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit ----- Original Message ----- From: "Alex Zinin" To: "Scott Bradner" Cc: Sent: Wednesday, December 17, 2003 3:01 PM Subject: Re: [Icar] Moving on with ICAR: WG formation and charter > > BTW, you are the second person whom I hear from about some > sort of coordination/umbrella group to tie the pieces together. > Do you think something like a directorate be a good idea, or > do we also need a "bigger picture" WG? I am not Scott Bradner, and I do not think I am channeling him, but ... I am also worried about the coordination issue. A working group to watch other working groups doesn't seem like a working group to me. It may be a well-kept secret, but there is a General Directorate already in place (see http://www.alvestrand.no/ietf/gen/directorate.html for details). It could be used to keep the many pieces straight, but is currently working to keep Harald Alvestrand straight, and that's a full-time job already ... Seriously - directorates are officially creatures serving an AD, not performing a function. We could create a Process Directorate, but it would be more straightforward to call it something else, if it's actually supposed to do things like summarize and rationalize multiple efforts. Spencer _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Thu Dec 18 09:23:35 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA23070 for ; Thu, 18 Dec 2003 09:23:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWz3Q-0004P3-5D for icar-archive@odin.ietf.org; Thu, 18 Dec 2003 09:23:07 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIEN4jq016919 for icar-archive@odin.ietf.org; Thu, 18 Dec 2003 09:23:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWz3P-0004Oo-Ug for icar-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 09:23:04 -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 JAA23016 for ; Thu, 18 Dec 2003 09:23:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWz3O-0003Q1-00 for icar-web-archive@ietf.org; Thu, 18 Dec 2003 09:23:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWz3M-0003Pm-00 for icar-web-archive@ietf.org; Thu, 18 Dec 2003 09:23:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWz3M-0003Pj-00 for icar-web-archive@ietf.org; Thu, 18 Dec 2003 09:23:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWz3N-0004Nm-9Z; Thu, 18 Dec 2003 09:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWz2n-0004NL-82 for icar@optimus.ietf.org; Thu, 18 Dec 2003 09:22:25 -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 JAA23002 for ; Thu, 18 Dec 2003 09:22:22 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWz2l-0003Od-00 for icar@ietf.org; Thu, 18 Dec 2003 09:22:23 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWz2k-0003OV-00 for icar@ietf.org; Thu, 18 Dec 2003 09:22:23 -0500 Received: from transfire.txc.com ([208.5.237.254] helo=pguin2.txc.com) by ietf-mx with esmtp (Exim 4.12) id 1AWz2j-0003OJ-00 for icar@ietf.org; Thu, 18 Dec 2003 09:22:21 -0500 Received: from txc.com ([172.17.0.134]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id hBIEMG023246; Thu, 18 Dec 2003 09:22:16 -0500 Message-ID: <3FE1B817.3040707@txc.com> Date: Thu, 18 Dec 2003 09:22:15 -0500 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Meyer CC: Alex Zinin , Alex Rousskov , "Joel M. Halpern" , icar@ietf.org Subject: Re: [Icar] Tagging drafts References: <27100647563.20031216143431@psg.com> <20031216021612.E3B0A3F746@Mail.MAP-NE.com> <27100647563.20031216143431@psg.com> <5.1.0.14.0.20031217140123.019a1208@localhost> <2473295463.20031217131156@psg.com> <3FE0F7AA.1090006@txc.com> <20031218005644.GA24014@1-4-5.net> In-Reply-To: <20031218005644.GA24014@1-4-5.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020501010202040100050201" 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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 This is a cryptographically signed message in MIME format. --------------ms020501010202040100050201 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dave, In the second paragraph in 2418 Section 6.3, which you mentioned, the text is straight forward: ...the Working Group Chair and Document Editor positions are filled by different individuals.... Regards, Alex David Meyer wrote: > Alex, > > On Wed, Dec 17, 2003 at 07:41:14PM -0500, Alex Conta wrote: > >>>I think it is also important to make a separation between technical >>>aspects and managerial aspects of the WG chair role in regards to the >>>document reviewing. >>> >>>I think it is the latter that should be considered, while the former >>>should be prohibited, in the current situation, where I think there is a >>>serious mixup and problem in IETF - one can say direct violation of RFC >>>2418 - with WG chairs being also involved with WG document editing. > > > Is this really a direct violation of 2418? Section 6.3 > (Document Editor) says: > > As a general practice, the Working Group Chair and > Document Editor positions are filled by different > individuals to help ensure that the resulting documents > accurately reflect the consensus of the working group > and that all processes are followed. > > While the spirit of section 6.3 seems clear enough, it > does not (apparently) mandate that the positions be > filled by different people. Rather, it seems to say that > it would be "better" if it were possible to fill the > positions with different individuals (my words). Or is > there a different section of 2418 that you are referring > to? > > Thanks, > > Dave --------------ms020501010202040100050201 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINqDCC A2IwggLLoAMCAQICEAvaCxfBP4mOqwl0erTOLjMwDQYJKoZIhvcNAQECBQAwXzELMAkGA1UE BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMTcwNQYDVQQLEy5DbGFzcyAxIFB1Ymxp YyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9yaXR5MB4XDTk4MDUxMjAwMDAwMFoXDTA4 MDUxMjIzNTk1OVowgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp U2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRv cnkvUlBBIEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2ln biBDbGFzcyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0 ZWQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALtaRIoEFrtV/QN6ii2UTxV4NrgNSrJv nFS/vOh3Kp258Gi7ldkxQXB6gUu5SBNWLccI4YRCq8CikqtEXKpC8IIOAukv+8I7u77JJwpd trA2QjO1blSIT4dKvxna+RXoD4e2HOPMxpqOf2okkuP84GW6p7F+78nbN2rISsgJBuSZAgMB AAGjgbAwga0wDwYDVR0TBAgwBgEB/wIBADBHBgNVHSAEQDA+MDwGC2CGSAGG+EUBBwEBMC0w KwYIKwYBBQUHAgEWH3d3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEwMQYDVR0fBCow KDAmoCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwCwYDVR0PBAQDAgEG MBEGCWCGSAGG+EIBAQQEAwIBBjANBgkqhkiG9w0BAQIFAAOBgQACfZ5vRUs4oLje6VNkIbzk TCuPHv6SQKzYCjlqoTIhLAebq1n+0mIafVU4sDdz3PQHZmNiveFTcFKH56jYUulbLarh3s+s MVTUixnI2COo7wQrMn0sGBzIfImoLnfyRNFlCk10te7TG5JzdC6JOzUTcudAMZrTssSr51a+ i+P7FTCCBR0wggSGoAMCAQICEAxYaM16ATcjBamVuftCOMIwDQYJKoZIhvcNAQEEBQAwgcwx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3 b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4g QnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFzcyAxIENBIElu ZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQwHhcNMDMxMDA3MDAw MDAwWhcNMDQxMDA2MjM1OTU5WjCCAQsxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29t L3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFCLkxURChjKTk4MR4wHAYDVQQL ExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxMzAxBgNVBAsTKkRpZ2l0YWwgSUQgQ2xhc3MgMSAt IE5ldHNjYXBlIEZ1bGwgU2VydmljZTETMBEGA1UEAxQKQWxleCBDb250YTEdMBsGCSqGSIb3 DQEJARYOYWNvbnRhQHR4Yy5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4 Ft6Hpfel8VTHHZ+/IL7CrN4JZuNiEG0jbHIdZ6p4fIhVYpLiSK57oEE8WooVkMCwJxbd1kja BR8eLKwmMatpnaW661HjOjZaZaWHuj1k+/I7ZKcPKHHk2V++wAz5lIrJEYXm5Swbqq+wz3Xu zBt1K3gRU+5AIeBbxD1H5yOShhuS8KMD3xh7XIpNu8KufVCzWAbLcto/oBAaXH9iXrdZ/fRZ ibQhNldCYSHv8zHt8uYMUs5AlL8TTEsEsx+Zrfhr4/dZWmnCBVLyMxFX3apwUq4onjmAeDmn MOzxlqp5kO/FJlUK5KHPvNYMnkA75zLGfONTZmnsc7nybpMta3YVAgMBAAGjggE4MIIBNDAJ BgNVHRMEAjAAMIGsBgNVHSAEgaQwgaEwgZ4GC2CGSAGG+EUBBwEBMIGOMCgGCCsGAQUFBwIB FhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vQ1BTMGIGCCsGAQUFBwICMFYwFRYOVmVyaVNp Z24sIEluYy4wAwIBARo9VmVyaVNpZ24ncyBDUFMgaW5jb3JwLiBieSByZWZlcmVuY2UgbGlh Yi4gbHRkLiAoYyk5NyBWZXJpU2lnbjARBglghkgBhvhCAQEEBAMCB4AwMAYKYIZIAYb4RQEG BwQiFiAyNTMxNjE3MDc0YTVhNTU3OTNjN2U4NDI2NjEyNTAyNjAzBgNVHR8ELDAqMCigJqAk hiJodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9jbGFzczEuY3JsMA0GCSqGSIb3DQEBBAUAA4GB ALIvzgvKUG1MgnjGt+pKACDHwud9y2gSne3lNmmfl9wzLNsSH+32cSUyVgKoQQ0hxKslfgQd xiJQ5PAQPCc2bA6SKJTYiaBE0aWnqGpLTNN4OUKTX3KXEBsxrCP2Tzjj6cm1ghHl12Z8IF1n VRdwTiGeuDVhv0bHVRJkJyFt0tFOMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjAN BgkqhkiG9w0BAQQFADCBzDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZl cmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3Np dG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlT aWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlk YXRlZDAeFw0wMzEwMDcwMDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVy aVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsT PXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIu TFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGln aXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4 IENvbnRhMR0wGwYJKoZIhvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEB BQADggEPADCCAQoCggEBALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJI rnugQTxaihWQwLAnFt3WSNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77A DPmUiskRheblLBuqr7DPde7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNY Bsty2j+gEBpcf2Jet1n99FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIF UvIzEVfdqnBSriieOYB4Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1r dhUCAwEAAaOCATgwggE0MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEH AQEwgY4wKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYB BQUHAgIwVjAVFg5WZXJpU2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAu IGJ5IHJlZmVyZW5jZSBsaWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQE AwIHgDAwBgpghkgBhvhFAQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2 MDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmww DQYJKoZIhvcNAQEEBQADgYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf 7fZxJTJWAqhBDSHEqyV+BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGs I/ZPOOPpybWCEeXXZnwgXWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4xggSqMIIEpgIBATCB4TCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQDFhozXoBNyMF qZW5+0I4wjAJBgUrDgMCGgUAoIICnTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wMzEyMTgxNDIyMTVaMCMGCSqGSIb3DQEJBDEWBBQvlM/b1ZxcyZPsoWJN ktdSx0m5QTBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB8gYJKwYBBAGCNxAEMYHk MIHhMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1 c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJ bmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3Mg MSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjN egE3IwWplbn7QjjCMIH0BgsqhkiG9w0BCRACCzGB5KCB4TCBzDEXMBUGA1UEChMOVmVyaVNp Z24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3 dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBCeSBSZWYuLExJQUIuTFRE KGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0EgSW5kaXZpZHVhbCBTdWJzY3Jp YmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZAIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0B AQEFAASCAQAMiPpGZee5PdJuwMBMn3ZRh33PzWFGiq77Tn6VnVsitpYkhlBuGUnyOxiVyR/k 6dDKmQGMCG9w7H0jL6dXTbHTPUueqkPu7j97O5lWYKVtAgvfsyFElG1NDjCNCd/7fvE9Lypn rBuerVO9y8PIKZE0+FbTB+ApjfS2wd55IjT3KFmU8nFyoxdXbEKeWOypVW0LKkjIus0FnrGW pOLIfN1bipaM7o4Ihe3FqUdO6FQfpsJHSCmdSHjqLf8I95/0teJaS0kOVxpmXbBSoaCowpww jsmv/+TO1hV6ylVuPgxbeEX7dk8tnqqEZcj6pIuexyZLjyEdNOIE5Yy6oS3jjz7GAAAAAAAA --------------ms020501010202040100050201-- _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Thu Dec 18 09:45:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24208 for ; Thu, 18 Dec 2003 09:45:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWzOh-0005fH-Kw for icar-archive@odin.ietf.org; Thu, 18 Dec 2003 09:45:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIEj3i8021769 for icar-archive@odin.ietf.org; Thu, 18 Dec 2003 09:45:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWzOh-0005f2-BN for icar-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 09:45:03 -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 JAA24176 for ; Thu, 18 Dec 2003 09:45:00 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWzOf-0004aL-00 for icar-web-archive@ietf.org; Thu, 18 Dec 2003 09:45:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWzOe-0004aE-00 for icar-web-archive@ietf.org; Thu, 18 Dec 2003 09:45:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AWzOe-0004aA-00 for icar-web-archive@ietf.org; Thu, 18 Dec 2003 09:45:00 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWzOf-0005du-9d; Thu, 18 Dec 2003 09:45:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AWzO7-0005d5-7c for icar@optimus.ietf.org; Thu, 18 Dec 2003 09:44:27 -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 JAA24126 for ; Thu, 18 Dec 2003 09:44:24 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AWzO5-0004Yk-00 for icar@ietf.org; Thu, 18 Dec 2003 09:44:25 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AWzO4-0004Yc-00 for icar@ietf.org; Thu, 18 Dec 2003 09:44:25 -0500 Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx with esmtp (Exim 4.12) id 1AWzO4-0004VI-00 for icar@ietf.org; Thu, 18 Dec 2003 09:44:24 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 18 Dec 2003 06:47:16 +0000 Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-1.cisco.com (8.12.9/8.12.6) with ESMTP id hBIEhpAt025515; Thu, 18 Dec 2003 06:43:51 -0800 (PST) Received: from cisco.com ([10.25.65.180]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with SMTP id APG14394; Thu, 18 Dec 2003 06:43:50 -0800 (PST) Date: Thu, 18 Dec 2003 09:43:47 -0500 Subject: Re: [Icar] Moving on with ICAR: WG formation and charter Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v553) Cc: icar@ietf.org To: Alex Zinin From: Melinda Shore In-Reply-To: <11571753696.20031217124615@psg.com> Message-Id: <9627AE40-3168-11D8-B7AE-000A95E35274@cisco.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.553) Content-Transfer-Encoding: 7bit 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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 Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit On Wednesday, December 17, 2003, at 03:46 PM, Alex Zinin wrote: > My understanding is that questions like "area boards" would be exactly > within the scope of ICAR. But not uniquely within the scope, since the area boards, at least in the proposal we've seen, also have other roles. If they don't have other roles they're not area boards, but some sort of document review board. This ties into your later comments and subsequent posts about how to coordinate changes within the context of the big picture (as well as the problem of how we, as an organization, ratify Big Decisions). Melinda _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Thu Dec 18 11:34:28 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01924 for ; Thu, 18 Dec 2003 11:34:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX166-0002jO-KA for icar-archive@odin.ietf.org; Thu, 18 Dec 2003 11:33:59 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBIGXw8X010497 for icar-archive@odin.ietf.org; Thu, 18 Dec 2003 11:33:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX161-0002jE-CP for icar-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 11:33:58 -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 LAA01907 for ; Thu, 18 Dec 2003 11:33:51 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX15v-0003yz-00 for icar-web-archive@ietf.org; Thu, 18 Dec 2003 11:33:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX15V-0003yi-00 for icar-web-archive@ietf.org; Thu, 18 Dec 2003 11:33:21 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX15V-0003yK-00 for icar-web-archive@ietf.org; Thu, 18 Dec 2003 11:33:21 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX15B-0002i4-7G; Thu, 18 Dec 2003 11:33:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX14M-0002hb-HY for icar@optimus.ietf.org; Thu, 18 Dec 2003 11:32:10 -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 LAA01870 for ; Thu, 18 Dec 2003 11:32:06 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX14E-0003wK-00 for icar@ietf.org; Thu, 18 Dec 2003 11:32:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX13j-0003vt-00 for icar@ietf.org; Thu, 18 Dec 2003 11:31:32 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1AX13j-0003uK-00 for icar@ietf.org; Thu, 18 Dec 2003 11:31:31 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.10/8.12.10) with ESMTP id hBIGUTIx028748; Thu, 18 Dec 2003 08:30:29 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.12.10/8.12.8/Submit) id hBIGUTDd028747; Thu, 18 Dec 2003 08:30:29 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 18 Dec 2003 08:30:28 -0800 From: David Meyer To: Alex Conta Cc: Alex Zinin , Alex Rousskov , "Joel M. Halpern" , icar@ietf.org, sob@harvard.edu Subject: Re: [Icar] Tagging drafts Message-ID: <20031218163028.GA28430@1-4-5.net> References: <27100647563.20031216143431@psg.com> <20031216021612.E3B0A3F746@Mail.MAP-NE.com> <27100647563.20031216143431@psg.com> <5.1.0.14.0.20031217140123.019a1208@localhost> <2473295463.20031217131156@psg.com> <3FE0F7AA.1090006@txc.com> <20031218005644.GA24014@1-4-5.net> <3FE1B817.3040707@txc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FE1B817.3040707@txc.com> User-Agent: Mutt/1.4i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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 Alex, >> In the second paragraph in 2418 Section 6.3, which you mentioned, the >> text is straight forward: >> >> ...the Working Group Chair and Document Editor positions are filled >> by different individuals.... You left off the most important part of the sentence for purposes of this discussion. In particular, what RFC 2418 section 6.3 says is exactly this: As a general practice, the Working Group Chair and Document Editor positions are filled by different individuals to help ensure that the resulting documents accurately reflect the consensus of the working group and that all processes are followed. The key phrase here is "As a general practice" as it describes when the following clause is to be applied. That being the case, one would have a hard time arguing that "As a general practice" means exclusivity (and by "exclusivity" I mean precisely that the positions of Chair and Document Editor, as defined by 2418, can not be filled by the same individual). There are two basic reasons why the exclusivity argument can not be sustained: (i). The definition of "general" includes the meaning that the verb (in this case, the "practice") is "applicable to or characteristic of the majority of individuals involved". That is, common usage is that when we say something "in general", we mean that it covers most cases. This is not only common usage, but it would seem the use intended here. Moreover, there is no text (footnotes, commentary or other) to suggest that anything other than the conventional meaning is what is intended by the text. Basically then, to sustain your point you need to argue that "general practice" means exclusivity, which is at variance with common usage, and is not supported by other text in 2418 (or 2026, or even 2119). (ii). Second, it would be next to impossible to argue that there is ambiguity in the meaning of "general practice" here, as the IETF has a well codified set of key words which (a). Are unambiguously defined for this purpose, namely RFC 2119 (b). Predate RFC 2418 (c). Are both written by the same person (2119 and 2418). So one would need to argue that even though both documents are authored by the same person, that person didn't know how to specify that "...Working Group Chair and Document Editor positions MUST be filled by different individuals..." (alternatively "...MUST NOT be filled by the same individual") Now, I am explicitly not stating a position on section 6.3 (other than to be surprised that I'm in violation of this section if your reading is correct). Perhaps this is text that needs to be changed to reflect your position, if that is consensus on this point (we may again be suffering from a lack of precision in 2418; this is not a criticism of Scott; rather, it seems that things have evolved in way perhaps not envisioned by the original text). What I am stating, however, is that your statement can not be supported by the cited text, common usage, or other RFCs. That is, your position is not supported by the controlling text in this case (section 6.3 for 2418), as common usage of the adjective in question is not to indicate exclusivity. It would also be difficult to argue that there is an ambiguity in the text, and that the intent of the text is to make Chair and Editor exclusive. This argument is not supportable, as we have codified exactly how to specify that something MUST or MUST NOT be done. Finally, the fact that the controlling documents (2119 and 2418) are written by the same person, and that 2119 predates 2418 would seriously weaken this line of reasoning. As it is clear what the meaning of "general practice" means (and indeed, the spirit of section 6.3 is also clear, i.e., that it would be "better" if they weren't the same person, for all the obvious reasons), ancillary arguments such as "the author didn't know how to specify what s/he meant" are untenable. Finally, I think the discussion here is a good one. However, if we don't follow the documents that lay out rules for operation of our own self-governance (probably 2026 and 2418, and possibly 2119 in this case), and if we don't interpret them with consistency and rigor, I'm afraid to say that they are meaningless. Dave _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Thu Dec 18 19:09:31 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA00366 for ; Thu, 18 Dec 2003 19:09:31 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX8CW-0002FF-LK for icar-archive@odin.ietf.org; Thu, 18 Dec 2003 19:09:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJ094Bj008623 for icar-archive@odin.ietf.org; Thu, 18 Dec 2003 19:09:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX8CW-0002F0-FU for icar-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 19:09:04 -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 TAA00356 for ; Thu, 18 Dec 2003 19:08:59 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX8CT-0001vT-00 for icar-web-archive@ietf.org; Thu, 18 Dec 2003 19:09:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX8CR-0001vJ-00 for icar-web-archive@ietf.org; Thu, 18 Dec 2003 19:09:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX8CQ-0001vG-00 for icar-web-archive@ietf.org; Thu, 18 Dec 2003 19:08:58 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX8CT-0002Dr-5I; Thu, 18 Dec 2003 19:09:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX8BV-00026T-Q7 for icar@optimus.ietf.org; Thu, 18 Dec 2003 19:08:07 -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 TAA00331 for ; Thu, 18 Dec 2003 19:07:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX8BP-0001tm-00 for icar@ietf.org; Thu, 18 Dec 2003 19:07:55 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX8BN-0001tf-00 for icar@ietf.org; Thu, 18 Dec 2003 19:07:54 -0500 Received: from transfire.txc.com ([208.5.237.254] helo=pguin2.txc.com) by ietf-mx with esmtp (Exim 4.12) id 1AX8BN-0001tQ-00 for icar@ietf.org; Thu, 18 Dec 2003 19:07:53 -0500 Received: from txc.com ([172.17.0.134]) by pguin2.txc.com (8.11.2/8.11.2) with ESMTP id hBJ07Z032521; Thu, 18 Dec 2003 19:07:36 -0500 Message-ID: <3FE24147.8030103@txc.com> Date: Thu, 18 Dec 2003 19:07:35 -0500 From: Alex Conta User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6b) Gecko/20031208 X-Accept-Language: en-us, en MIME-Version: 1.0 To: David Meyer CC: Alex Zinin , Alex Rousskov , "Joel M. Halpern" , icar@ietf.org, sob@harvard.edu Subject: Re: [Icar] Tagging drafts References: <27100647563.20031216143431@psg.com> <20031216021612.E3B0A3F746@Mail.MAP-NE.com> <27100647563.20031216143431@psg.com> <5.1.0.14.0.20031217140123.019a1208@localhost> <2473295463.20031217131156@psg.com> <3FE0F7AA.1090006@txc.com> <20031218005644.GA24014@1-4-5.net> <3FE1B817.3040707@txc.com> <20031218163028.GA28430@1-4-5.net> In-Reply-To: <20031218163028.GA28430@1-4-5.net> Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms090908080905010808000309" 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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 This is a cryptographically signed message in MIME format. --------------ms090908080905010808000309 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Dave, I think we are closer to agreement on this text: As a general practice, the Working Group Chair and Document Editor positions are filled by different individuals to help ensure that the resulting documents accurately reflect the consensus of the working group and that all processes are followed. It does not have a MUST as it could. As this text was new in RFC 2418 - didn't exist in RFC 1603 - I could speculate on some nervousness to make the text a MUST in 1998. But there is a lot of other text in RFC 2418 that does not have MUSTs. The presence of the paragraph means that there was a concern already prior to 1998 about accurately reflecting the consensus of the WG, and about following the process, in case WG chairs are also WG document editors. It means also that there was an attempt to resolve the concern, and create a rule to help eliminate the concern. The rule is a general rule, so it applies to all possible cases, but it may have exceptions, which we know. As I had fun reading your message, in response I'll do my own dissecting: "As a general practice" (a) is an introductory adverbial element replaceable with "in general". It was chosen perhaps as wording fitting better than "in general" in the context of a "Best Current Practices" document. So together with the main sentence (b), it would be "in general, the Working Group Chair and Document Editor positions are filled by different individuals". The use of the adverb "in general", suggests that this is a general rule applied in all cases. This is equivalent to: "as a general rule, Working Group Chair and Document Editor positions are filled by different individuals". A general rule has exceptions. The last three sentences (c) are together a "complex adverbial clause": (c) (i)to help ensure that (ii) the resulting documents accurately reflect the consensus of the working group and (iii)that all processes are followed In which (ii) and (iii) are individually themselves adverbial clauses. The group (c) provides the clarification to the acceptable exceptions: cases in which "some considerations" are stronger, or more important than those "to help ensure that the resulting documents accurately reflect the consensus of the working group and that all processes are followed". That "accurately reflecting consensus in the WG", and "all processes are followed" are important elements is no need of saying. Helping ensure important elements is an important element in itself. "Stronger considerations" are either better or equal in "helping ensure...", or are simply more important than "helping ensure..."... That is quite a high threshold for exceptions to me.... Regards, Alex David Meyer wrote: > Alex, > > >>>In the second paragraph in 2418 Section 6.3, which you mentioned, the >>>text is straight forward: >>> >>> ...the Working Group Chair and Document Editor positions are filled >>> by different individuals.... > > > You left off the most important part of the sentence for > purposes of this discussion. In particular, what RFC 2418 > section 6.3 says is exactly this: > > As a general practice, the Working Group Chair and > Document Editor positions are filled by different > individuals to help ensure that the resulting > documents accurately reflect the consensus of the > working group and that all processes are followed. > > The key phrase here is "As a general practice" as it > describes when the following clause is to be applied. That > being the case, one would have a hard time arguing that > "As a general practice" means exclusivity (and by > "exclusivity" I mean precisely that the positions of > Chair and Document Editor, as defined by 2418, can not be > filled by the same individual). > > There are two basic reasons why the exclusivity argument > can not be sustained: > > (i). The definition of "general" includes the meaning > that the verb (in this case, the "practice") is > "applicable to or characteristic of the majority > of individuals involved". That is, common usage > is that when we say something "in general", we > mean that it covers most cases. This is not only > common usage, but it would seem the use intended > here. Moreover, there is no text (footnotes, > commentary or other) to suggest that anything > other than the conventional meaning is what is > intended by the text. > > Basically then, to sustain your point you need to > argue that "general practice" means exclusivity, > which is at variance with common usage, and is > not supported by other text in 2418 (or 2026, or > even 2119). > > (ii). Second, it would be next to impossible to argue > that there is ambiguity in the meaning of > "general practice" here, as the IETF has a well > codified set of key words which > > (a). Are unambiguously defined for this > purpose, namely RFC 2119 > > (b). Predate RFC 2418 > > (c). Are both written by the same person (2119 > and 2418). So one would need to argue > that even though both documents are > authored by the same person, that person > didn't know how to specify that > "...Working Group Chair and Document > Editor positions MUST be filled by > different individuals..." (alternatively > "...MUST NOT be filled by the same > individual") > > Now, I am explicitly not stating a position on section > 6.3 (other than to be surprised that I'm in violation of > this section if your reading is correct). Perhaps this is > text that needs to be changed to reflect your position, > if that is consensus on this point (we may again be > suffering from a lack of precision in 2418; this is not a > criticism of Scott; rather, it seems that things have > evolved in way perhaps not envisioned by the original > text). > > What I am stating, however, is that your statement can > not be supported by the cited text, common usage, or > other RFCs. That is, your position is not supported by > the controlling text in this case (section 6.3 for 2418), > as common usage of the adjective in question is not to > indicate exclusivity. > > It would also be difficult to argue that there is an > ambiguity in the text, and that the intent of the text is > to make Chair and Editor exclusive. This argument is not > supportable, as we have codified exactly how to specify > that something MUST or MUST NOT be done. Finally, the > fact that the controlling documents (2119 and 2418) are > written by the same person, and that 2119 predates 2418 > would seriously weaken this line of reasoning. > > As it is clear what the meaning of "general practice" > means (and indeed, the spirit of section 6.3 is also > clear, i.e., that it would be "better" if they weren't > the same person, for all the obvious reasons), ancillary > arguments such as "the author didn't know how to specify > what s/he meant" are untenable. > > Finally, I think the discussion here is a good one. > However, if we don't follow the documents that lay > out rules for operation of our own self-governance > (probably 2026 and 2418, and possibly 2119 in this case), > and if we don't interpret them with consistency and > rigor, I'm afraid to say that they are meaningless. > > Dave > > > > > --------------ms090908080905010808000309 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIINdDCC Ay4wggKXoAMCAQICEQDSdi6NFAw9fbKoJV2v7g11MA0GCSqGSIb3DQEBAgUAMF8xCzAJBgNV BAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQdWJs aWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw05ODA1MTIwMDAwMDBaFw0w ODA1MTIyMzU5NTlaMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVy aVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0 b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNp Z24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRh dGVkMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC7WkSKBBa7Vf0DeootlE8VeDa4DUqy b5xUv7zodyqdufBou5XZMUFweoFLuUgTVi3HCOGEQqvAopKrRFyqQvCCDgLpL/vCO7u+yScK XbawNkIztW5UiE+HSr8Z2vkV6A+HthzjzMaajn9qJJLj/OBluqexfu/J2zdqyErICQbkmQID AQABo3wwejARBglghkgBhvhCAQEEBAMCAQYwRwYDVR0gBEAwPjA8BgtghkgBhvhFAQcBATAt MCsGCCsGAQUFBwIBFh93d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBMA8GA1UdEwQI MAYBAf8CAQAwCwYDVR0PBAQDAgEGMA0GCSqGSIb3DQEBAgUAA4GBAIi4Nzvd2pQ3AK2qn+GB AXEekmptL/bxndPKZDjcG5gMB4ZbhRVqD7lJhaSV8Rd9Z7R/LSzdmkKewz60jqrlCwbe8lYq +jPHvhnXU0zDvcjjF7WkSUJj7MKmFw9dWBpJPJBcVaNlIAD9GCDlX4KmsaiSxVhqwY0DPOvD zQWikK5uMIIFHTCCBIagAwIBAgIQDFhozXoBNyMFqZW5+0I4wjANBgkqhkiG9w0BAQQFADCB zDEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5l dHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9SUEEgSW5jb3Jw LiBCeSBSZWYuLExJQUIuTFREKGMpOTgxSDBGBgNVBAMTP1ZlcmlTaWduIENsYXNzIDEgQ0Eg SW5kaXZpZHVhbCBTdWJzY3JpYmVyLVBlcnNvbmEgTm90IFZhbGlkYXRlZDAeFw0wMzEwMDcw MDAwMDBaFw0wNDEwMDYyMzU5NTlaMIIBCzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAd BgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5j b20vcmVwb3NpdG9yeS9SUEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNV BAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAx IC0gTmV0c2NhcGUgRnVsbCBTZXJ2aWNlMRMwEQYDVQQDFApBbGV4IENvbnRhMR0wGwYJKoZI hvcNAQkBFg5hY29udGFAdHhjLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEB ALgW3oel96XxVMcdn78gvsKs3glm42IQbSNsch1nqnh8iFVikuJIrnugQTxaihWQwLAnFt3W SNoFHx4srCYxq2mdpbrrUeM6NlplpYe6PWT78jtkpw8oceTZX77ADPmUiskRheblLBuqr7DP de7MG3UreBFT7kAh4FvEPUfnI5KGG5LwowPfGHtcik27wq59ULNYBsty2j+gEBpcf2Jet1n9 9FmJtCE2V0JhIe/zMe3y5gxSzkCUvxNMSwSzH5mt+Gvj91laacIFUvIzEVfdqnBSriieOYB4 Oacw7PGWqnmQ78UmVQrkoc+81gyeQDvnMsZ841NmaexzufJuky1rdhUCAwEAAaOCATgwggE0 MAkGA1UdEwQCMAAwgawGA1UdIASBpDCBoTCBngYLYIZIAYb4RQEHAQEwgY4wKAYIKwYBBQUH AgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9DUFMwYgYIKwYBBQUHAgIwVjAVFg5WZXJp U2lnbiwgSW5jLjADAgEBGj1WZXJpU2lnbidzIENQUyBpbmNvcnAuIGJ5IHJlZmVyZW5jZSBs aWFiLiBsdGQuIChjKTk3IFZlcmlTaWduMBEGCWCGSAGG+EIBAQQEAwIHgDAwBgpghkgBhvhF AQYHBCIWIDI1MzE2MTcwNzRhNWE1NTc5M2M3ZTg0MjY2MTI1MDI2MDMGA1UdHwQsMCowKKAm oCSGImh0dHA6Ly9jcmwudmVyaXNpZ24uY29tL2NsYXNzMS5jcmwwDQYJKoZIhvcNAQEEBQAD gYEAsi/OC8pQbUyCeMa36koAIMfC533LaBKd7eU2aZ+X3DMs2xIf7fZxJTJWAqhBDSHEqyV+ BB3GIlDk8BA8JzZsDpIolNiJoETRpaeoaktM03g5QpNfcpcQGzGsI/ZPOOPpybWCEeXXZnwg XWdVF3BOIZ64NWG/RsdVEmQnIW3S0U4wggUdMIIEhqADAgECAhAMWGjNegE3IwWplbn7QjjC MA0GCSqGSIb3DQEBBAUAMIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMW VmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBv c2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVy aVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFs aWRhdGVkMB4XDTAzMTAwNzAwMDAwMFoXDTA0MTAwNjIzNTk1OVowggELMRcwFQYDVQQKEw5W ZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UE CxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIGJ5IFJlZi4sTElB Qi5MVEQoYyk5ODEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTMwMQYDVQQLEypE aWdpdGFsIElEIENsYXNzIDEgLSBOZXRzY2FwZSBGdWxsIFNlcnZpY2UxEzARBgNVBAMUCkFs ZXggQ29udGExHTAbBgkqhkiG9w0BCQEWDmFjb250YUB0eGMuY29tMIIBIjANBgkqhkiG9w0B AQEFAAOCAQ8AMIIBCgKCAQEAuBbeh6X3pfFUxx2fvyC+wqzeCWbjYhBtI2xyHWeqeHyIVWKS 4kiue6BBPFqKFZDAsCcW3dZI2gUfHiysJjGraZ2luutR4zo2WmWlh7o9ZPvyO2SnDyhx5Nlf vsAM+ZSKyRGF5uUsG6qvsM917swbdSt4EVPuQCHgW8Q9R+cjkoYbkvCjA98Ye1yKTbvCrn1Q s1gGy3LaP6AQGlx/Yl63Wf30WYm0ITZXQmEh7/Mx7fLmDFLOQJS/E0xLBLMfma34a+P3WVpp wgVS8jMRV92qcFKuKJ45gHg5pzDs8ZaqeZDvxSZVCuShz7zWDJ5AO+cyxnzjU2Zp7HO58m6T LWt2FQIDAQABo4IBODCCATQwCQYDVR0TBAIwADCBrAYDVR0gBIGkMIGhMIGeBgtghkgBhvhF AQcBATCBjjAoBggrBgEFBQcCARYcaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL0NQUzBiBggr BgEFBQcCAjBWMBUWDlZlcmlTaWduLCBJbmMuMAMCAQEaPVZlcmlTaWduJ3MgQ1BTIGluY29y cC4gYnkgcmVmZXJlbmNlIGxpYWIuIGx0ZC4gKGMpOTcgVmVyaVNpZ24wEQYJYIZIAYb4QgEB BAQDAgeAMDAGCmCGSAGG+EUBBgcEIhYgMjUzMTYxNzA3NGE1YTU1NzkzYzdlODQyNjYxMjUw MjYwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC52ZXJpc2lnbi5jb20vY2xhc3MxLmNy bDANBgkqhkiG9w0BAQQFAAOBgQCyL84LylBtTIJ4xrfqSgAgx8LnfctoEp3t5TZpn5fcMyzb Eh/t9nElMlYCqEENIcSrJX4EHcYiUOTwEDwnNmwOkiiU2ImgRNGlp6hqS0zTeDlCk19ylxAb Mawj9k844+nJtYIR5ddmfCBdZ1UXcE4hnrg1Yb9Gx1USZCchbdLRTjGCBKowggSmAgEBMIHh MIHMMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3Qg TmV0d29yazFGMEQGA1UECxM9d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNv cnAuIEJ5IFJlZi4sTElBQi5MVEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBD QSBJbmRpdmlkdWFsIFN1YnNjcmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3 IwWplbn7QjjCMAkGBSsOAwIaBQCgggKdMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJ KoZIhvcNAQkFMQ8XDTAzMTIxOTAwMDczNVowIwYJKoZIhvcNAQkEMRYEFB+1Ob3ouLFnNto3 zFpxEmCYbkBVMFIGCSqGSIb3DQEJDzFFMEMwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIHyBgkrBgEEAYI3EAQx geQwgeEwgcwxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBU cnVzdCBOZXR3b3JrMUYwRAYDVQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBB IEluY29ycC4gQnkgUmVmLixMSUFCLkxURChjKTk4MUgwRgYDVQQDEz9WZXJpU2lnbiBDbGFz cyAxIENBIEluZGl2aWR1YWwgU3Vic2NyaWJlci1QZXJzb25hIE5vdCBWYWxpZGF0ZWQCEAxY aM16ATcjBamVuftCOMIwgfQGCyqGSIb3DQEJEAILMYHkoIHhMIHMMRcwFQYDVQQKEw5WZXJp U2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29yazFGMEQGA1UECxM9 d3d3LnZlcmlzaWduLmNvbS9yZXBvc2l0b3J5L1JQQSBJbmNvcnAuIEJ5IFJlZi4sTElBQi5M VEQoYyk5ODFIMEYGA1UEAxM/VmVyaVNpZ24gQ2xhc3MgMSBDQSBJbmRpdmlkdWFsIFN1YnNj cmliZXItUGVyc29uYSBOb3QgVmFsaWRhdGVkAhAMWGjNegE3IwWplbn7QjjCMA0GCSqGSIb3 DQEBAQUABIIBAEHxnxmEIJsugEApy+RMznMCdvAkaDdRmYWOf/rqSMoBtI/mS9pZ7lOAvUnY GNvyVrxUt2huK4TfeU2zjbDN4ChWNhrmfi3KhRwHk8ktBrLb2BrGrmMtqq/AfeTMR3SMQuNv eznLqFzR7elqip//lC6FVp/5321oGcEpn1QiYCfYpxe2gbW5RWTX3ltRINcArJpLYKAR6RzC hvPLHWlitsXS4GHcGZPqr77M6PTy2UJUNpSyR71lnINhV2FZj/eYi+SnFhEtcVdKd3WAvGZS +kpddu5Gm5wECrTCKxbxCCFEclAVDxgmx9BgBs53x/mjjdRbWW7WLTbj7dsCdvJrWtAAAAAA AAA= --------------ms090908080905010808000309-- _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Thu Dec 18 19:57:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA03972 for ; Thu, 18 Dec 2003 19:57:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX8wy-0004EB-7b for icar-archive@odin.ietf.org; Thu, 18 Dec 2003 19:57:04 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJ0v41h016245 for icar-archive@odin.ietf.org; Thu, 18 Dec 2003 19:57:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX8wy-0004Dw-27 for icar-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 19:57:04 -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 TAA03958 for ; Thu, 18 Dec 2003 19:57:02 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX8ww-0005VG-00 for icar-web-archive@ietf.org; Thu, 18 Dec 2003 19:57:02 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX8wv-0005V9-00 for icar-web-archive@ietf.org; Thu, 18 Dec 2003 19:57:01 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX8wv-0005V6-00 for icar-web-archive@ietf.org; Thu, 18 Dec 2003 19:57:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX8wv-0004DY-0C; Thu, 18 Dec 2003 19:57:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX8wl-0004DI-Fc for icar@optimus.ietf.org; Thu, 18 Dec 2003 19:56:51 -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 TAA03952 for ; Thu, 18 Dec 2003 19:56:50 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX8wi-0005Ti-00 for icar@ietf.org; Thu, 18 Dec 2003 19:56:49 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX8wh-0005Tb-00 for icar@ietf.org; Thu, 18 Dec 2003 19:56:48 -0500 Received: from m106.maoz.com ([205.167.76.9]) by ietf-mx with esmtp (Exim 4.12) id 1AX8wh-0005SU-00 for icar@ietf.org; Thu, 18 Dec 2003 19:56:47 -0500 Received: from m106.maoz.com (localhost.localdomain [127.0.0.1]) by m106.maoz.com (8.12.10/8.12.10) with ESMTP id hBJ0uFIx019256; Thu, 18 Dec 2003 16:56:15 -0800 Received: (from dmm@localhost) by m106.maoz.com (8.12.10/8.12.8/Submit) id hBJ0uFBx019255; Thu, 18 Dec 2003 16:56:15 -0800 X-Authentication-Warning: m106.maoz.com: dmm set sender to dmm@1-4-5.net using -f Date: Thu, 18 Dec 2003 16:56:15 -0800 From: David Meyer To: Alex Conta Cc: Alex Zinin , Alex Rousskov , "Joel M. Halpern" , icar@ietf.org, sob@harvard.edu Subject: Re: [Icar] Tagging drafts Message-ID: <20031219005615.GA19126@1-4-5.net> References: <20031216021612.E3B0A3F746@Mail.MAP-NE.com> <27100647563.20031216143431@psg.com> <5.1.0.14.0.20031217140123.019a1208@localhost> <2473295463.20031217131156@psg.com> <3FE0F7AA.1090006@txc.com> <20031218005644.GA24014@1-4-5.net> <3FE1B817.3040707@txc.com> <20031218163028.GA28430@1-4-5.net> <3FE24147.8030103@txc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3FE24147.8030103@txc.com> User-Agent: Mutt/1.4i X-public-key: http://www.1-4-5.net/~dmm/public-key.asc X-philosophy: "I just had to let it go" -- John Lennon 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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 On Thu, Dec 18, 2003 at 07:07:35PM -0500, Alex Conta wrote: >> Dave, >> >> I think we are closer to agreement on this text: >> >> As a general practice, the Working Group Chair and >> Document Editor positions are filled by different >> individuals to help ensure that the resulting >> documents accurately reflect the consensus of the >> working group and that all processes are followed. >> >> It does not have a MUST as it could. As this text was new in RFC 2418 - >> didn't exist in RFC 1603 - I could speculate on some nervousness to make >> the text a MUST in 1998. But there is a lot of other text in RFC 2418 >> that does not have MUSTs. What we can say is that section 6.3 of 2418 does not use the term MUST. If something else was intended (e.g. MUST), then the rule may be considered to be miswritten (or at least ambiguous). In addition, the rule has clearly not been applied as you interpret it. In any event, if the consensus is that it is miswritten or ambiguous, then lets fix that. BTW, your statement that "The rule is a general rule, so it applies to all possible cases, but it may have exceptions, which we know." is really difficult to understand. For example, what does "all possible cases" mean (are there impossible cases?), and what does it mean for a "possible case" to have "exceptions"? Are the possible cases those that don't have exceptions? My point here is that our language (and/or the way we use it) is not sufficiently precise to form the basis of a self-governance system (as demonstrated by this and many other discussions), and that is frequently the basis of these disputes. Add to that the fact that we have no case law system (or the like) to disambiguate these cases, and maybe there is an issue here. Finally on all of this, what I disagreed with was your use of the term "direct violation" in the following: >> I think it is the latter that should be considered, while the former >> should be prohibited, in the current situation, where I think there is a >> serious mixup and problem in IETF - one can say direct violation of RFC >> 2418 - with WG chairs being also involved with WG document editing. so can you have an exception to one of the "possible cases" in which the Chair is also the Editor. Is that a "direct violation"? Or is an impossible case? Or ? I think (hope) you see my point. BTW, my sense is that there is an excellent opportunity to clean things like this up in processes such as the one we are engaged in, and I look forward to the continued discussion. Dave _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Thu Dec 18 20:23:32 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04734 for ; Thu, 18 Dec 2003 20:23:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX9M7-0005b4-N0 for icar-archive@odin.ietf.org; Thu, 18 Dec 2003 20:23:03 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBJ1N34B021505 for icar-archive@odin.ietf.org; Thu, 18 Dec 2003 20:23:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX9M7-0005aa-H8 for icar-web-archive@optimus.ietf.org; Thu, 18 Dec 2003 20:23:03 -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 UAA04708 for ; Thu, 18 Dec 2003 20:23:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX9M5-0006El-00 for icar-web-archive@ietf.org; Thu, 18 Dec 2003 20:23:01 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX9M3-0006EZ-00 for icar-web-archive@ietf.org; Thu, 18 Dec 2003 20:23:00 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AX9M3-0006ES-00 for icar-web-archive@ietf.org; Thu, 18 Dec 2003 20:22:59 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX9M5-0005a6-9b; Thu, 18 Dec 2003 20:23:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AX9M0-0005Zp-MI for icar@optimus.ietf.org; Thu, 18 Dec 2003 20:22:56 -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 UAA04698 for ; Thu, 18 Dec 2003 20:22:54 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AX9Ly-0006EL-00 for icar@ietf.org; Thu, 18 Dec 2003 20:22:54 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AX9Lx-0006EE-00 for icar@ietf.org; Thu, 18 Dec 2003 20:22:54 -0500 Received: from newdev.eecs.harvard.edu ([140.247.60.212] helo=newdev.harvard.edu) by ietf-mx with esmtp (Exim 4.12) id 1AX9Lx-0006DE-00 for icar@ietf.org; Thu, 18 Dec 2003 20:22:53 -0500 Received: by newdev.harvard.edu (Postfix, from userid 501) id 69D26AD21A; Thu, 18 Dec 2003 20:22:24 -0500 (EST) To: icar@ietf.org Subject: Re: [icar] Tagging drafts Message-Id: <20031219012224.69D26AD21A@newdev.harvard.edu> Date: Thu, 18 Dec 2003 20:22:24 -0500 (EST) From: sob@harvard.edu (Scott Bradner) 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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 >> It does not have a MUST as it could. As this text was new in RFC 2418 - >> didn't exist in RFC 1603 - I could speculate on some nervousness to make >> the text a MUST in 1998. But there is a lot of other text in RFC 2418 >> that does not have MUSTs. it was not a MUST because the WG did not want to make it a MUST - the feeling was that there were too many examples where things had worked just fine with WG chairs as doc editors and all too many cases where nothing would have happened without that being the case i.e. the text represents what the WG wanted to say at the time in general the feeling in the WG about this (and a number of other issues) was that it was better to write absolute rules - it was better to leave things a bit open (but give a general direction) so that decisions could be made taking the specific situation into account Scott _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar From exim@www1.ietf.org Mon Dec 22 11:22:33 2003 Received: from optimus.ietf.org ([132.151.1.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23908 for ; Mon, 22 Dec 2003 11:22:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYSon-0007MR-43 for icar-archive@odin.ietf.org; Mon, 22 Dec 2003 11:22:05 -0500 Received: (from exim@localhost) by www1.ietf.org (8.12.8/8.12.8/Submit) id hBMGM5ao028294 for icar-archive@odin.ietf.org; Mon, 22 Dec 2003 11:22:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYSom-0007MH-Q5 for icar-web-archive@optimus.ietf.org; Mon, 22 Dec 2003 11:22:04 -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 LAA23893 for ; Mon, 22 Dec 2003 11:22:01 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYSol-000161-00 for icar-web-archive@ietf.org; Mon, 22 Dec 2003 11:22:03 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYSoj-00015s-00 for icar-web-archive@ietf.org; Mon, 22 Dec 2003 11:22:03 -0500 Received: from [132.151.1.19] (helo=optimus.ietf.org) by ietf-mx with esmtp (Exim 4.12) id 1AYSoj-00015m-00 for icar-web-archive@ietf.org; Mon, 22 Dec 2003 11:22:01 -0500 Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYSoj-0007LZ-Ly; Mon, 22 Dec 2003 11:22:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AYSoW-0007L2-Bp for icar@optimus.ietf.org; Mon, 22 Dec 2003 11:21:52 -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 LAA23883 for ; Mon, 22 Dec 2003 11:21:45 -0500 (EST) Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AYSoV-00015Z-00 for icar@ietf.org; Mon, 22 Dec 2003 11:21:47 -0500 Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AYSoT-00015S-00 for icar@ietf.org; Mon, 22 Dec 2003 11:21:47 -0500 Received: from f070.brocade.com ([66.243.153.70] helo=blasphemy.brocade.com) by ietf-mx with esmtp (Exim 4.12) id 1AYSoT-00010R-00 for icar@ietf.org; Mon, 22 Dec 2003 11:21:45 -0500 Received: from hq-ex-3.corp.brocade.com (hq-ex-3 [192.168.38.35]) by blasphemy.brocade.com (Postfix) with ESMTP id 5487814331; Mon, 22 Dec 2003 08:21:13 -0800 (PST) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Icar] Tagging drafts Date: Mon, 22 Dec 2003 08:21:13 -0800 Message-ID: Thread-Topic: [Icar] Tagging drafts Thread-Index: AcPFxFdW2ETScIN6SCyKs3bUvHLUHQC4hwkA From: "Robert Snively" To: "Alex Conta" , "David Meyer" Cc: "Alex Zinin" , "Alex Rousskov" , "Joel M. Halpern" , , Content-Transfer-Encoding: quoted-printable 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: , List-Id: Improved Cross-Area Review List-Post: List-Help: List-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 Content-Transfer-Encoding: quoted-printable Content-Transfer-Encoding: quoted-printable One of the problems raised in the "problem list" was recognition of contributors. I am happy to see the recognition in this text that the person writing the document is really a "document editor" rather than an "author". That allows the formal recognition in the document of the tremendous work and responsibility of the editor as well as the recognition of the=20 work of all the participants and contributors to the document. It lays aside the concept of an "author" who receives sole or principal credit for the document, leaving most contributors unrecognized or at=20 best "acknowledged". Bob +1-408-333-8135 > -----Original Message----- > From: Alex Conta [mailto:aconta@txc.com] > Sent: Thursday, December 18, 2003 4:08 PM > To: David Meyer > Cc: Alex Zinin; Alex Rousskov; Joel M. Halpern; icar@ietf.org; > sob@harvard.edu > Subject: Re: [Icar] Tagging drafts >=20 >=20 > Dave, >=20 > I think we are closer to agreement on this text: >=20 > As a general practice, the Working Group Chair and > Document Editor positions are filled by different > individuals to help ensure that the resulting > documents accurately reflect the consensus of the > working group and that all processes are followed. >=20 > It does not have a MUST as it could. As this text was new in=20 > RFC 2418 -=20 > didn't exist in RFC 1603 - I could speculate on some=20 > nervousness to make=20 > the text a MUST in 1998. But there is a lot of other text in=20 > RFC 2418=20 > that does not have MUSTs. >=20 > The presence of the paragraph means that there was a concern already=20 > prior to 1998 about accurately reflecting the consensus of the WG, and > about following the process, in case WG chairs are also WG document=20 > editors. It means also that there was an attempt to resolve=20 > the concern,=20 > and create a rule to help eliminate the concern. >=20 > The rule is a general rule, so it applies to all possible=20 > cases, but it=20 > may have exceptions, which we know. >=20 > As I had fun reading your message, in response I'll do my own=20 > dissecting: >=20 > "As a general practice" (a) is an introductory adverbial element=20 > replaceable with "in general". It was chosen perhaps as=20 > wording fitting=20 > better than "in general" in the context of a "Best Current Practices"=20 > document. So together with the main sentence (b), it would be "in=20 > general, the Working Group Chair and Document Editor positions are=20 > filled by different individuals". The use of the adverb "in general",=20 > suggests that this is a general rule applied in all cases. This is=20 > equivalent to: >=20 > "as a general rule, Working Group Chair and Document Editor positions=20 > are filled by different individuals". >=20 > A general rule has exceptions. The last three sentences (c)=20 > are together=20 > a "complex adverbial clause": >=20 > (c) (i)to help ensure that > (ii) the resulting documents accurately reflect=20 > the consensus > of the working group and > (iii)that all processes are followed >=20 > In which (ii) and (iii) are individually themselves adverbial clauses. >=20 > The group (c) provides the clarification to the acceptable exceptions: >=20 > cases in which "some considerations" are stronger, or more important=20 > than those "to help ensure that the resulting documents accurately=20 > reflect the consensus of the working group and that all processes are=20 > followed". >=20 > That "accurately reflecting consensus in the WG", and "all=20 > processes are=20 > followed" are important elements is no need of saying. Helping ensure=20 > important elements is an important element in itself. >=20 > "Stronger considerations" are either better or equal in "helping=20 > ensure...", or are simply more important than "helping ensure..."... >=20 > That is quite a high threshold for exceptions to me.... >=20 > Regards, > Alex >=20 > David Meyer wrote: >=20 > > Alex, > >=20 > >=20 > >>>In the second paragraph in 2418 Section 6.3, which you=20 > mentioned, the=20 > >>>text is straight forward: > >>> > >>> ...the Working Group Chair and Document Editor=20 > positions are filled > >>> by different individuals.... > >=20 > >=20 > > You left off the most important part of the sentence for > > purposes of this discussion. In particular, what RFC 2418 > > section 6.3 says is exactly this:=20 > >=20 > > As a general practice, the Working Group Chair and > > Document Editor positions are filled by different > > individuals to help ensure that the resulting > > documents accurately reflect the consensus of the > > working group and that all processes are followed. > >=20 > > The key phrase here is "As a general practice" as it > > describes when the following clause is to be applied. That > > being the case, one would have a hard time arguing that > > "As a general practice" means exclusivity (and by > > "exclusivity" I mean precisely that the positions of > > Chair and Document Editor, as defined by 2418, can not be > > filled by the same individual). =20 > >=20 > > There are two basic reasons why the exclusivity argument > > can not be sustained:=20 > >=20 > > (i). The definition of "general" includes the meaning > > that the verb (in this case, the "practice") is=20 > > "applicable to or characteristic of the majority > > of individuals involved". That is, common usage > > is that when we say something "in general", we > > mean that it covers most cases. This is not only > > common usage, but it would seem the use intended > > here. Moreover, there is no text (footnotes, > > commentary or other) to suggest that anything > > other than the conventional meaning is what is > > intended by the text. > >=20 > > Basically then, to sustain your point you need to > > argue that "general practice" means exclusivity, > > which is at variance with common usage, and is > > not supported by other text in 2418 (or 2026, or > > even 2119).=20 > >=20 > > (ii). Second, it would be next to impossible to argue > > that there is ambiguity in the meaning of > > "general practice" here, as the IETF has a well > > codified set of key words which=20 > >=20 > > (a). Are unambiguously defined for this > > purpose, namely RFC 2119=20 > >=20 > > (b). Predate RFC 2418 > >=20 > > (c). Are both written by the same person (2119 > > and 2418). So one would need to argue > > that even though both documents are > > authored by the same person, that person > > didn't know how to specify that > > "...Working Group Chair and Document > > Editor positions MUST be filled by > > different individuals..." (alternatively > > "...MUST NOT be filled by the same > > individual") > >=20 > > Now, I am explicitly not stating a position on section > > 6.3 (other than to be surprised that I'm in violation of > > this section if your reading is correct). Perhaps this is > > text that needs to be changed to reflect your position, > > if that is consensus on this point (we may again be=20 > > suffering from a lack of precision in 2418; this is not a > > criticism of Scott; rather, it seems that things have > > evolved in way perhaps not envisioned by the original > > text).=20 > >=20 > > What I am stating, however, is that your statement can > > not be supported by the cited text, common usage, or > > other RFCs. That is, your position is not supported by > > the controlling text in this case (section 6.3 for 2418), > > as common usage of the adjective in question is not to=20 > > indicate exclusivity.=20 > >=20 > > It would also be difficult to argue that there is an > > ambiguity in the text, and that the intent of the text is > > to make Chair and Editor exclusive. This argument is not > > supportable, as we have codified exactly how to specify > > that something MUST or MUST NOT be done. Finally, the > > fact that the controlling documents (2119 and 2418) are > > written by the same person, and that 2119 predates 2418 > > would seriously weaken this line of reasoning. > >=20 > > As it is clear what the meaning of "general practice" > > means (and indeed, the spirit of section 6.3 is also > > clear, i.e., that it would be "better" if they weren't > > the same person, for all the obvious reasons), ancillary > > arguments such as "the author didn't know how to specify > > what s/he meant" are untenable. =20 > >=20 > > Finally, I think the discussion here is a good one. > > However, if we don't follow the documents that lay=20 > > out rules for operation of our own self-governance > > (probably 2026 and 2418, and possibly 2119 in this case), > > and if we don't interpret them with consistency and > > rigor, I'm afraid to say that they are meaningless. > >=20 > > Dave > >=20 > > =09 > >=20 > >=20 > >=20 >=20 >=20 _______________________________________________ Icar mailing list Icar@ietf.org https://www1.ietf.org/mailman/listinfo/icar