From rfc-editor-rfi-bounces@ietf.org Mon Jan 5 11:08:00 2009 Return-Path: X-Original-To: rfc-editor-rfi-archive@ietf.org Delivered-To: ietfarch-rfc-editor-rfi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6798C3A69D1; Mon, 5 Jan 2009 11:08:00 -0800 (PST) X-Original-To: rfc-editor-rfi@core3.amsl.com Delivered-To: rfc-editor-rfi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EE6D13A69D1 for ; Mon, 5 Jan 2009 11:07:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.365 X-Spam-Level: * X-Spam-Status: No, score=1.365 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JBiVpCXOapDA for ; Mon, 5 Jan 2009 11:07:59 -0800 (PST) Received: from mail.amsl.com (mail.amsl.com [IPv6:2001:1890:1112:1::14]) by core3.amsl.com (Postfix) with ESMTP id 5B9D83A6937 for ; Mon, 5 Jan 2009 11:07:56 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by core2.amsl.com (Postfix) with ESMTP id 8233C24301 for ; Mon, 5 Jan 2009 11:07:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com Received: from mail.amsl.com ([64.170.98.20]) by localhost (core2.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYcbF+3Sv2Yl for ; Mon, 5 Jan 2009 11:07:43 -0800 (PST) Received: from steveyPC (steve [64.170.98.61]) by core2.amsl.com (Postfix) with ESMTP id 6C7BB242FB for ; Mon, 5 Jan 2009 11:07:43 -0800 (PST) From: "Steve Young" To: Date: Mon, 5 Jan 2009 11:07:43 -0800 Message-ID: <009d01c96f68$e358cf60$aa0a6e20$@com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 thread-index: AclvaOMxQwvugyByQwqtToYDLJRoHQ== Content-Language: en-us Subject: [rfc-editor-rfi] List and archive test - please ignore X-BeenThere: rfc-editor-rfi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1990985450==" Sender: rfc-editor-rfi-bounces@ietf.org Errors-To: rfc-editor-rfi-bounces@ietf.org This is a multipart message in MIME format. --===============1990985450== Content-Type: multipart/alternative; boundary="----=_NextPart_000_009E_01C96F25.D5358F60" Content-Language: en-us This is a multipart message in MIME format. ------=_NextPart_000_009E_01C96F25.D5358F60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sending a test email to track through mail, mailman, archives. Steve AMS ------=_NextPart_000_009E_01C96F25.D5358F60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sending a test email to track through mail, mailman, = archives.

Steve

AMS

------=_NextPart_000_009E_01C96F25.D5358F60-- --===============1990985450== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ rfc-editor-rfi mailing list rfc-editor-rfi@ietf.org https://www.ietf.org/mailman/listinfo/rfc-editor-rfi --===============1990985450==-- From rfc-editor-rfi-bounces@ietf.org Mon Jan 5 12:27:40 2009 Return-Path: X-Original-To: rfc-editor-rfi-archive@ietf.org Delivered-To: ietfarch-rfc-editor-rfi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7D2428C12A; Mon, 5 Jan 2009 12:27:40 -0800 (PST) X-Original-To: rfc-editor-rfi@core3.amsl.com Delivered-To: rfc-editor-rfi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB3E73A6A98 for ; Mon, 5 Jan 2009 12:27:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.489 X-Spam-Level: X-Spam-Status: No, score=-2.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PL8n7B99O3iz for ; Mon, 5 Jan 2009 12:27:39 -0800 (PST) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.243]) by core3.amsl.com (Postfix) with ESMTP id E72FA3A6A20 for ; Mon, 5 Jan 2009 12:27:38 -0800 (PST) Received: by an-out-0708.google.com with SMTP id c5so2703591anc.4 for ; Mon, 05 Jan 2009 12:27:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=rFzz1hUo/FatPXbn08f7ZIviU9EVaJeb9t7CfCNCAvY=; b=nNybks82Bet8+TAL3C/A5KbYqPaxpvYvoq6FOLpZerEjxyUUisrL5uv+wtjYoRrKrQ 2rGsRA0SVDdLqom7jqP+AGQqjRhKQIXKkXC3/mf7Q7iJ5HLWsGYDk0otlQwGfRlst1Bs LhpgiA88Oy4n8It+5HLyvsgxL4zmfae4taDYE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; b=b6Tta9Mi5cmrKP5r6YUzqJnRnhtPeD+yQjtkbPdD8wd+6f+6gP5kTzk8/5/ILSXuaQ o+sCIMO/Z/S4yaH05EhDBEoItDUXjFcTLlj4aqM2t0c+xahClcf3NVb3ohTm8L+sjrCd 1TD+0cgHcPgGZ1lNPwTPUoqU8KhZM8T20ZF64= Received: by 10.142.48.14 with SMTP id v14mr8834022wfv.122.1231187244451; Mon, 05 Jan 2009 12:27:24 -0800 (PST) Received: from ?130.216.38.124? (stf-brian.sfac.auckland.ac.nz [130.216.38.124]) by mx.google.com with ESMTPS id 24sm277965wfc.42.2009.01.05.12.27.23 (version=SSLv3 cipher=RC4-MD5); Mon, 05 Jan 2009 12:27:24 -0800 (PST) Message-ID: <49626D29.5040208@gmail.com> Date: Tue, 06 Jan 2009 09:27:21 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: rfc-editor-rfi@ietf.org References: <4B1C6144-EE21-4D9F-90FC-285532E4F31B@isoc.org> In-Reply-To: <4B1C6144-EE21-4D9F-90FC-285532E4F31B@isoc.org> Subject: Re: [rfc-editor-rfi] [rfc-i] Draft RFC Editor Services RFI for Community Input X-BeenThere: rfc-editor-rfi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rfc-editor-rfi-bounces@ietf.org Errors-To: rfc-editor-rfi-bounces@ietf.org [Repeat posting to the correct address] Hi, Thanks for posting this. The SoW for the RSE doesn't... Sorry, I'll try that again: The statement of work for the RFC Series Editor doesn't seem to indicate that the RSE supervises the work of the RFC Production Service and the RFC Publisher service. That creates a dilution of authority and responsibility that makes no sense from a service management perspective. I think there needs to be a clear statement that the RSE has the primary management responsibility for the two services. Otherwise, operational confusion is inevitable. (That may also mean in practice that the RSE manages the contracts, if the two services are separately contracted.) It also needs to be clearly stated who the RSE reports to. Is it the IAB, the IAOC, or the IAD? If it's the IAB or IAOC, is the chair or the committee as a whole? Note that I don't have these concerns as strongly for the Independent Submissions Editor, who is a *client* of the RSE, the Production Service and the Publisher. But it should perhaps be made clear in the SoW that the IAB is the formal reporting channel. "6. The IAB, RFC Series Editor and IAOC shall review the performance of the ISE." is a bit too indirect. The SoWs for the Production Center and the Publisher should probably make it clear that they report to the RFC Series Editor in the first instance and the IAD in the second instance; they seem to be logically isolated from the IAB. Brian _______________________________________________ rfc-editor-rfi mailing list rfc-editor-rfi@ietf.org https://www.ietf.org/mailman/listinfo/rfc-editor-rfi From rfc-editor-rfi-bounces@ietf.org Tue Jan 6 07:06:13 2009 Return-Path: X-Original-To: rfc-editor-rfi-archive@ietf.org Delivered-To: ietfarch-rfc-editor-rfi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3D7353A6892; Tue, 6 Jan 2009 07:06:13 -0800 (PST) X-Original-To: rfc-editor-rfi@core3.amsl.com Delivered-To: rfc-editor-rfi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 281FE3A6810 for ; Mon, 5 Jan 2009 20:53:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y1sklhswFbRe for ; Mon, 5 Jan 2009 20:53:46 -0800 (PST) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id DC3CF3A6803 for ; Mon, 5 Jan 2009 20:53:45 -0800 (PST) Received: from [10.20.30.158] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n064rTEu074499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 5 Jan 2009 21:53:30 -0700 (MST) (envelope-from paul.hoffman@standcore.com) Mime-Version: 1.0 Message-Id: Date: Mon, 5 Jan 2009 20:53:27 -0800 To: rfc-editor-rfi@ietf.org From: Paul Hoffman X-Mailman-Approved-At: Tue, 06 Jan 2009 07:06:12 -0800 Subject: [rfc-editor-rfi] Comments on the draft RFI for the RFC Editor function X-BeenThere: rfc-editor-rfi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rfc-editor-rfi-bounces@ietf.org Errors-To: rfc-editor-rfi-bounces@ietf.org Greetings again. John Levine and I have looked over the draft RFI and have found a few areas where we were surprised by content of the draft, and have some suggestions for how to make a better RFI (and therefore a better RFP). The statements of work in the draft RFI seem pretty good. They are not what we expected a few months ago; we thought there would be more responsibility in the RSE and very little other than machine management in the RFC Publisher, but we understand how the current set of tasks for the roles evolved. Our biggest concern with the RFI is that someone bidding on the Production Center has no idea how much to bid for the copy editing. There are no numbers in the RFI estimating the number of pages per hour that ISI and/or outside contractors have spent on copy editing in recent years. Also, there are no numbers in the RFI saying approximately what the percentage of Internet Drafts being turned in today to the RFC Editor are already in xml2rfc format; this number would help any bidder who was planning on using xml2rfc for formatting the RFCs give a much more accurate cost estimate. Similarly, the RFI absolutely needs to be clear on whether or not IASA will participate in hiring copy editors as it has in the past. Bidders will need to know what their staffing responsibilities will be, particularly who is responsible for hiring normal and extra workers. In the SOW for the Publisher, there are too many under-specified content-related tasks that could significantly change the cost of performing the work. In specific, A.3.v ("develop content as directed by the IAD") could entail tens of thousands of dollars of work, or nearly none. Similarly, A.3.vi ("site-map style indexing") could be easy or it could take hundreds of hours of index-priming. A.8 says "best commercial practice", which could mean "be sensible and careful" or could mean "do as much as a bank"; there is more than an order of magnitude difference in cost; A.9 has a similar problem. We are very concerned about SOW for the Publisher, A.11.i, that says "at no additional cost". This could be interpreted as bidders cannot factor in the costs of updating the software that they did not write. It is surprising to see this clause, and this clause could easily cause there to be no bidders at all for the job. We hope the above comments help. --Paul Hoffman, Director --Standcore _______________________________________________ rfc-editor-rfi mailing list rfc-editor-rfi@ietf.org https://www.ietf.org/mailman/listinfo/rfc-editor-rfi From rfc-editor-rfi-bounces@ietf.org Thu Jan 8 12:54:38 2009 Return-Path: X-Original-To: rfc-editor-rfi-archive@ietf.org Delivered-To: ietfarch-rfc-editor-rfi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D1BAF3A6A70; Thu, 8 Jan 2009 12:54:38 -0800 (PST) X-Original-To: rfc-editor-rfi@core3.amsl.com Delivered-To: rfc-editor-rfi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19A7E28C0DF for ; Thu, 8 Jan 2009 12:54:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aYDHRm1Rhakx for ; Thu, 8 Jan 2009 12:54:37 -0800 (PST) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.186]) by core3.amsl.com (Postfix) with ESMTP id E2F083A6957 for ; Thu, 8 Jan 2009 12:54:36 -0800 (PST) Received: by ti-out-0910.google.com with SMTP id a6so6200411tib.25 for ; Thu, 08 Jan 2009 12:54:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :organization:user-agent:mime-version:to:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=RN33152+oyhqGXE1V26GuX64/X2KU6QQKymbxCX3DNQ=; b=BpdH9r4gP/ehznqqC3VAhe6iTbhuLuT0lp810sT86JZHFo0lMUPrbDYLKyVBoajaNN Gvp2drdh1qqV2Dh99lgnefykZNtWf1lK32XVldff5N5FjJMr81cTcptQV7RIHGDW3ZSO H53wt8u8mb44BbjQq8UCiM+LCfUZTDIyTma/w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; b=idyHeKKKGX0XCF3jrDGHiplL1a7H8sven1vEqFECHnLz3yKFaMhmAyzOt46KD6cYCj NEYxrU4Hi1fJGnyRnkB2RTV+1N5EsxQteSXg5S1gQ1HJC+uafBFA/H+uZM9MtjCy5Qhm 56USpndG4I1MAr5C8cT23p7ZRLvTZr4XYGreQ= Received: by 10.110.40.8 with SMTP id n8mr198412tin.41.1231448062430; Thu, 08 Jan 2009 12:54:22 -0800 (PST) Received: from ?10.1.1.4? (118-93-185-90.dsl.dyn.ihug.co.nz [118.93.185.90]) by mx.google.com with ESMTPS id j5sm2047413tid.18.2009.01.08.12.54.19 (version=SSLv3 cipher=RC4-MD5); Thu, 08 Jan 2009 12:54:21 -0800 (PST) Message-ID: <496667FE.8000701@gmail.com> Date: Fri, 09 Jan 2009 09:54:22 +1300 From: Brian E Carpenter Organization: University of Auckland User-Agent: Thunderbird 2.0.0.6 (Windows/20070728) MIME-Version: 1.0 To: Leslie Daigle References: <20090105165556.EC8653A67DA@core3.amsl.com> <0400901BDD034F2FABE887D3@PST.jck.com> <49663F21.8050801@thinkingcat.com> In-Reply-To: <49663F21.8050801@thinkingcat.com> Cc: John C Klensin , rfc-editor-rfi@ietf.org Subject: Re: [rfc-editor-rfi] Last Call: RFC Editor Services Draft RFI X-BeenThere: rfc-editor-rfi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rfc-editor-rfi-bounces@ietf.org Errors-To: rfc-editor-rfi-bounces@ietf.org (ietf list deleted for this short comment which is hopefullly a drafting issue) On 2009-01-09 07:00, Leslie Daigle wrote: ... >> >> (6) In several places in the document, especially in the SOW >> for the RFC Series Editor and Independent Submission Editor, >> various actors are required to "work with" various other >> actors. That language, in context, implies that no one is in >> charge (or everyone is) and is the sort of thing that can lead >> to non-performance justifed by considerable finger-pointing. > > Again, the terminology is perhaps there to solve a different problem: as > things become distributed, it is important to spell out who (people or > entities) needs to be in the loop. (I'm not saying it doesn't introduce > issues, but we are going to have to find a balance to be clear about > expectations, even if it means abusive interpretations could put us in a > bad place). However, as in my earlier comment to this list, the draft RFI *does not* state clearly that the Series Editor is *in charge of* the production and publishing contractors. I cannot imagine how the Editor job could be performed unless the Editor is clearly able to direct those two functions. Even if the contracts are formally held by the IAD, in practice the Editor needs managerial authority. I hope that is only a drafting issue, not a conceptual one. Brian _______________________________________________ rfc-editor-rfi mailing list rfc-editor-rfi@ietf.org https://www.ietf.org/mailman/listinfo/rfc-editor-rfi From rfc-editor-rfi-bounces@ietf.org Thu Jan 8 21:34:57 2009 Return-Path: X-Original-To: rfc-editor-rfi-archive@ietf.org Delivered-To: ietfarch-rfc-editor-rfi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65E273A686B; Thu, 8 Jan 2009 21:34:57 -0800 (PST) X-Original-To: rfc-editor-rfi@core3.amsl.com Delivered-To: rfc-editor-rfi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 331B73A63D3; Thu, 8 Jan 2009 10:00:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qTUyVh3IxJsq; Thu, 8 Jan 2009 10:00:27 -0800 (PST) Received: from zeke.ecotroph.net (zeke.ecotroph.net [70.164.19.155]) by core3.amsl.com (Postfix) with ESMTP id 0923C3A657C; Thu, 8 Jan 2009 10:00:26 -0800 (PST) Received: from beethoven.local ([::ffff:142.167.13.78]) (AUTH: PLAIN leslie, SSL: TLSv1/SSLv3,256bits,AES256-SHA) by zeke.ecotroph.net with esmtp; Thu, 08 Jan 2009 13:00:11 -0500 id 015843AA.49663F2B.00003042 Message-ID: <49663F21.8050801@thinkingcat.com> Date: Thu, 08 Jan 2009 13:00:01 -0500 From: Leslie Daigle User-Agent: Thunderbird 2.0.0.18 (Macintosh/20081105) MIME-Version: 1.0 To: John C Klensin References: <20090105165556.EC8653A67DA@core3.amsl.com> <0400901BDD034F2FABE887D3@PST.jck.com> In-Reply-To: <0400901BDD034F2FABE887D3@PST.jck.com> X-Mailman-Approved-At: Thu, 08 Jan 2009 21:34:56 -0800 Cc: rfc-editor-rfi@ietf.org, ietf@ietf.org Subject: Re: [rfc-editor-rfi] Last Call: RFC Editor Services Draft RFI X-BeenThere: rfc-editor-rfi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="us-ascii"; Format="flowed" Sender: rfc-editor-rfi-bounces@ietf.org Errors-To: rfc-editor-rfi-bounces@ietf.org Hi John, As an individual who happens to find herself on the RFP subcommittee, I'd like to follow up a few points, below. I have added rfc-editor-rfi@ietf.org to the cc line (having seen your follow up note) as it is my understanding that the intention was for that list to be publicly archived, and this gets to the attention of all of the members of the subcommittee. John C Klensin wrote: > This document is hard to comment on because it raises, and > mixes, a number of separate issues. A large number of those > involve questions that the RFI responses might reasonably > address; I have omitted those from these comments unless they > are directly related to more immediate issues. > > The document is repetitive internally and duplicates material > from other materials. In particularly, Appendix B duplicates > much of the material on pages 3 - 5. I have not made these > comments longer by pointing out each place a particular problem > occurs. > > Major issues: > > (1) This document is heavily dependent on the IAB's RFC Editor > model document. It is unfortunate that the comment cutoff on > this document occurs while that one is still being tuned. In > RFC Editor process language, there is a clear normative > dependency between this one and the IAB document and final > decisions cannot be made on this one before that one has > solidified. IMO, closing the comment period on this one > before the IAB signs off on that one is not consistent with the > spirit of the comments and commitment made during and after the > Minneapolis Plenary. > > (2) That dependency is particularly important for two reasons. > First, the RFC Editor Model document leaves a number of loose > ends which the community has been assured will be straightened > out by the IAOC and the RPI, RFP, and ongoing management > processes without the community having to be involved. That is > fine as long as the issues involved are administrative details. > But there is nothing in BCP 101 and its relationship to RFC > 4846 that permits the IAB to delegate fundamental policy > decisions to the IAOC. Personally, I rather hope it's clear that the IAB doesn't make such delegations, but will leave the discussion of the RFC Model document for elsewhere. The RFC Editor Model document is still > not clear on where the IAB believes the boundary lies. For > the record, any decision on that subject presumably creates an > appealable event, with an appeal timer that does not start > until at least the date on which the IAB hands the document off > to the RFC Editor. > > To the extent to which RFC3932bis is relevant (I suggest in > (10), below, that it is not), almost the same comments about > normative dependencies would apply to it. > > (3) The second reason is, in some respects, almost the > opposite. The RFI goes well beyond either the draft RFC Editor > Model document or RFC 4844/ 4846 in assigning critical-path > responsibilities to the IAB. The two RFCs carefully avoid > getting the IAB into a position in which it much respond to a > particular issue on a specific timeframe in order to permit > others to do jobs for which they are contractually obligated. It would be really useful to have a couple of examples of where you see this happening in the SOW. There are places where we worked to make sure the IAB (or some entity) was in a loop, but I don't believe there was the intention of making the IAB critical path. So, it would be helpful to know where you read it that way. > But the SOW here appears to require just that sort of > commitment from the IAB and presumably for the IAB to be able > to make decisions that involve the informed actions of the vast > majority of its members. Without that, either > possibly-important decisions are made by a few individuals, in > the dark, and with no real community input or accountability or > the various contractual actors are unable to proceed with their > work. I note that willingness and a commitment to work > actively on this sort of matter is not part of the IAB role > description in RFC 2850 nor is it part of the IAB job > description most recently given to the Nomcom. If the RFI is > going to assume this level of commitment by the IAB, it would > be useful to know that at least the current IAB membership has > accepted that responsibility and obligation. > > (4) If a potential responder for some of these roles is, > individually or organizationally, an active part of the IETF > community and standards process (or of the community that might > present Independent Submissions to the Independent Submission > Editor), there is a potential for at least the appearance of > conflicts of interest. It seems to me that a key question for > the RFI is to find out how various parties would propose to > deal with those issues. > > (5) There is an inherent contradiction between (i) the apparent > requirement that a potential vendor respondent to the RFI > supply all of a specific list of information (the list under > "The IASA is seeking..." on pages 3 and 4 or its > near-equivalent in Appendix B) and presumably be committed to > it should the vendor choose to respond to an RFP and (ii) the > disclaimer in item (4) on page 5 that a non-response to the RFI > does not bar someone from responding to an RFP. While some of > the information requested in Appendix B are entirely > appropriate to an RFI response that is not binding on either > the IASA or the respondent, others, especially the requirement > to identify a specific candidate person for the Series Editor > if someone might later submit a proposal specifying that > position is a deterrent to getting useful responses. > > It would be completely appropriate for an RFI to request a > discussion of the job description for the Series Editor that is > present in the RFC Editor Model document (except that the > description there is mostly hand-waving) or to discuss that > role more generally, and even to ask for comments on how that > position might effectively be filled, but that particular > requirement, and some of the others, potentially puts a > respondent at a disadvantage relative to an organization that > held that information more closely until it was ready to submit > an RFP response. > > (6) In several places in the document, especially in the SOW > for the RFC Series Editor and Independent Submission Editor, > various actors are required to "work with" various other > actors. That language, in context, implies that no one is in > charge (or everyone is) and is the sort of thing that can lead > to non-performance justifed by considerable finger-pointing. Again, the terminology is perhaps there to solve a different problem: as things become distributed, it is important to spell out who (people or entities) needs to be in the loop. (I'm not saying it doesn't introduce issues, but we are going to have to find a balance to be clear about expectations, even if it means abusive interpretations could put us in a bad place). > Other text seems to carry forward the problem of the RFC Editor > Model document in assigning responsibility with no authority. > In other cases, the final responsibility and authority seems to > lie with the IAB. But the IAB (unlike the IESG) is not a > management body (or has not been one since the late 1980s or > early 1990s) and is not chartered to hire or fire anyone (other > than its Chair). This is another reason why the issue raised > in (3) above is relevant. > > (7) The SOW for the RFC Series Editor, point F.7, appears to > assign responsibility for April Fool's RFCs to the Series > Editor. Under RFC 4846, those RFCs are a special category of > Independent Submissions and hence should belong to the > Independent Submission Editor. Nothing I've seen in the RFC > Editor Model draft appears to contradict that assignment, so > this is either a mistake or an instance of the IASA changing > established policy on its own initiative. > > (8) This document, in the respective SOWs, creates optional > Editorial Boards for both the RSE and the ISE. Those Boards > are optional and, if appointed, have members that serve purely > at the pleasure of the relevant Editor. At least for the ISE > function, that model is different from and contradicts the > carefully-worked-out model established in RFC 4846 and nothing > in the RFC Editor Model draft appears to override 4846 in that > regard. Again, this is either a mistake in the draft RFI or an > instance of the IASA changing established policy on its own > initiative. > > (9) While I would expect this to be elaborated upon in > responses to the RFI, there are a number of places in which > various parties can direct the holders of one function or > another to do specific work that they may not have anticipated > on when they submitted bids or agreed to contracts. Unless the > RFP (and probably the RFI, given that you are asking for > commitments about funding models) anticipates contracts plus > additional tasks on a time and material basis (something that > would be very risky for the IASA/IETF), Well, I can't argue about the possibility of risk, but this is precisely the sort of mechanism that the IASA has been using in its contracts, for exactly the reason you suggest ("unfunded mandates" don't work). these have the > potential to be what are known elsewhere as "unfunded > mandates". If you expect useful responses to the RFI, you > should really provide enough information about how you > anticipate all of those provisions to be supported to permit > those responses (even if the response is to tell you what won't > work). > > (10) The SOW for the Independent Submission Editor appears to > bind that function to the provisions of RFC 3932 or its > successor. This contradicts RFC 4846, which carefully avoided > binding the Independent Submission process to any output from > the IESG. Under 4846, the RFC Editor is required only to give > input from the IESG appropriate consideration; the RFC Editor > is not "subject to its provisions". Both RFC 3932 and its > proposed successor are IESG documents, describing an IESG > procedure for conducting an IESG evaluation. They are not > provisions or instructions for the RFC Editor (or any of its > sub-functions). This is, again, either a mistake in the draft > RFI or an attempt by the IAOC to reverse existing and > carefully-considered and negotiated policy. > > (11) Section A of the Independent Submission Editor SOW appears > to establish tasks or activities for which the ISE is > responsible (or for which the ISE must "ensure" that something > happens) which are dependent on timely and appropriate > responses from other bodies, including the IAB and IESG. It > was not clear from the RFC Editor Model draft how the ISE was > going to be able to do those things without authority to make > the IAB or IESG do anything (their members are not under > contract to the IASA). This draft RFI makes the requirements on > the ISE even stronger and the authority mechanism, if it were > possible, even more vague. > > (12) RFC 4714 was a very controversial document that did not > achieve nearly the level of community review and consensus > associated with RFC 4844 and 4846. It reflects a somewhat > different attitude toward the role and independence of the RFC > Editor Function (in the aggregate) than the attitude reflected > in the two latter documents. Those who disliked it stopped > opposing its publication only when its scope was clearly > limited to what later became known as the IETF Stream (which is > exactly the role that RFC 4844, Section 5.2.1, assigns it). If > the RFI intends to use it more broadly, as the "Reference" > paragraphs of the Production Center and Publisher SOWs > suggests, we have another policy problem. While I won't comment either way about how well received 4714 was, I do agree that its use should be restricted to the IETF Stream. Thanks, Leslie. > > (13) The Production Center is committed to follow the > provisions of a Style Manual that does not exist today, is > unlikely to exist when the RFP goes out, and may become the > first task for the newly-appointed RFC Series Editor in January > 2010. I hope the IAB has a plan about how that particular bit > of transition is going to be handled and that the plan has been > vetted by the IAOC. If not, this is another internal normative > dependency. > > (14) Some of the details of the recent, and still unresolved, > discussion about the IPR policy and Contributions document > point out that the "careful negotiation; don't touch this > document" model may be the wrong one, or at least that the > model of what the "minimal formatting edits" constitute may > need work (see the short titles in the RFC 3978 headers for an > example). Are you sure you want to write that into to > Production Center SOW without some additional qualifications > about where the guidelines come from and how far they can go? > I hope the answer isn't supposed to be "Style Manual", because > those guidelines are a policy matter of some import. > > (15) The whole Production Center SOW is too oriented toward the > IETF Stream, and the Standards substream in particular, with > the other streams left as loose ends. > > (16) Production Center SOA, A.3, involves another controversy > in which the IESG has made rules without obvious community > consensus. Precisely what is meant by "validating the syntax" > (e.g., whether the syntax in a given document is required to > have a single root) is, itself, controversial and a matter of > policy. Expecting respondents to the RFI to comment on this is > inappropriate; expecting to write such a comment into an RFP or > contract without much more specificity would be a grave > disservice to the community. > > (17) It is not clear what Production Center SOA, A.8, means, or > who can authorize/order such a step. Presumably it is at least > stream-dependent. > > (18) Like recent drafts of the RFC Editor Model document, the > SOAs in this document do not reflect the many and varied > iteration paths that can and do occur in the present editing > process. I would be happy to see some of those loops > disappear, but I do not believe that eliminating them would be > consistent with high-quality output. In any event, they should > not be eliminated as an accidental side-effect of the design of > an RFI or RFP. > > (19) It is not clear whether the working document archives to > be maintained by the publisher (source documents, tracking and > reviewing information, and other supporting materials) are > expected to be public and publicly accessible. This has been > another controversial issue in the community and the decision > is likely to have a cost impact. The decision involves policy > and should not be left to an accident or low-level > administrative process. > > Thanks for letting me comment. > > john > > p.s. I'm copying the IETF list. Most of the above are > substantive issues and should no more be isolated to an obscure > mailing list than responses to a Last Call issued by the IESG. > > > --On Monday, January 05, 2009 8:55 -0800 IETF Administrative > Director wrote: > >> All; >> >> This is a reminder that 7 January is the last call opportunity >> to provide input to this Draft RFI before it is released for >> vendor response later in January. >> >> In 2009 the IETF Administrative Oversight Committee (IAOC) >> plans to issue a Request for Information (RFI) and a Request >> for Proposal (RFP) for the performance of the RFC Editor >> functions beginning in 2010. The incumbent has advised that >> they do not intend to respond to the RFP. At the request of >> the IAOC, the RFC Editor Selection Oversight Subcommittee is >> issuing a draft RFI for community comment. The draft is >> located at: http://iaoc.ietf.org/rfpsrfis.html >> >> The purpose of the RFI itself is to identify potential >> contractors to provide the RFC Editor services and to obtain >> feedback from contractors and the broader Internet community >> on the implementation of the new RFC services model. > > > > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www.ietf.org/mailman/listinfo/ietf -- ------------------------------------------------------------------- "Reality: Yours to discover." -- ThinkingCat Leslie Daigle leslie@thinkingcat.com ------------------------------------------------------------------- _______________________________________________ rfc-editor-rfi mailing list rfc-editor-rfi@ietf.org https://www.ietf.org/mailman/listinfo/rfc-editor-rfi From rfc-editor-rfi-bounces@ietf.org Thu Jan 8 21:34:57 2009 Return-Path: X-Original-To: rfc-editor-rfi-archive@ietf.org Delivered-To: ietfarch-rfc-editor-rfi-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 755C928C0DC; Thu, 8 Jan 2009 21:34:57 -0800 (PST) X-Original-To: rfc-editor-rfi@core3.amsl.com Delivered-To: rfc-editor-rfi@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 53C623A68B6; Thu, 8 Jan 2009 13:22:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.643 X-Spam-Level: X-Spam-Status: No, score=-2.643 tagged_above=-999 required=5 tests=[AWL=-0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C1tDM723nllU; Thu, 8 Jan 2009 13:22:33 -0800 (PST) Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by core3.amsl.com (Postfix) with ESMTP id 31A673A67F8; Thu, 8 Jan 2009 13:22:33 -0800 (PST) Received: from [127.0.0.1] (helo=localhost) by bs.jck.com with esmtp (Exim 4.34) id 1LL2KW-000225-Qy; Thu, 08 Jan 2009 16:22:17 -0500 Date: Thu, 08 Jan 2009 16:22:10 -0500 From: John C Klensin To: Brian E Carpenter , Leslie Daigle Message-ID: <610540A5242074D333EF9B1D@PST.jck.com> In-Reply-To: <496667FE.8000701@gmail.com> References: <20090105165556.EC8653A67DA@core3.amsl.com> <0400901BDD034F2FABE887D3@PST.jck.com> <49663F21.8050801@thinkingcat.com> <496667FE.8000701@gmail.com> X-Mailer: Mulberry/4.0.8 (Win32) MIME-Version: 1.0 Content-Disposition: inline X-Mailman-Approved-At: Thu, 08 Jan 2009 21:34:56 -0800 Cc: rfc-editor-rfi@ietf.org, iaoc@ietf.org Subject: Re: [rfc-editor-rfi] Last Call: RFC Editor Services Draft RFI X-BeenThere: rfc-editor-rfi@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: rfc-editor-rfi-bounces@ietf.org Errors-To: rfc-editor-rfi-bounces@ietf.org --On Friday, January 09, 2009 9:54 +1300 Brian E Carpenter wrote: > (ietf list deleted for this short comment which is > hopefullly a drafting issue) Given the nature of the problem and my response, I'd added the IAOC back on and suggest that it is an appropriate topic for the IETF list if it is not clearly and quickly resolved. See below > On 2009-01-09 07:00, Leslie Daigle wrote: > ... >>> >>> (6) In several places in the document, especially in the SOW >>> for the RFC Series Editor and Independent Submission Editor, >>> various actors are required to "work with" various other >>> actors. That language, in context, implies that no one is in >>> charge (or everyone is) and is the sort of thing that can >>> lead to non-performance justifed by considerable >>> finger-pointing. >> >> Again, the terminology is perhaps there to solve a different >> problem: as things become distributed, it is important to >> spell out who (people or entities) needs to be in the loop. >> (I'm not saying it doesn't introduce issues, but we are going >> to have to find a balance to be clear about expectations, >> even if it means abusive interpretations could put us in a >> bad place). > > However, as in my earlier comment to this list, the draft RFI > *does not* state clearly that the Series Editor is *in charge > of* the production and publishing contractors. I cannot > imagine how the Editor job could be performed unless the > Editor is clearly able to direct those two functions. Even if > the contracts are formally held by the IAD, in practice the > Editor needs managerial authority. I hope that is only a > drafting issue, not a conceptual one. I hesitate to speculate about what sort of issue it is, but note that the "responsibility but no authority or control" issue was raised several times during the discussion of the IAB "model" draft and never really addressed (other than a comment from Ray to the effect that the Series Editor could tell him and he would take care of the production house -- a response that I consider completely inadequate for the reasons you identify). Since this issue has been raised several times and still apparently exists in both the handwaving in the RFC Editor Model draft and is skipped over in the draft RFI, I have trouble believing that it is just a drafting omission. But I'd be happy to be wrong about that. I also note that, had this discussion occurred on either the rfc-interest list or the IETF one, the fact that the issue had been raised several times before would have almost certainly been spotted immediately. That adds to my belief that this small and isolated list is the wrong place to be carrying out the discussion, independent of the observation that doing so appears to violate at least the intent of IETF/ IASA rules. john _______________________________________________ rfc-editor-rfi mailing list rfc-editor-rfi@ietf.org https://www.ietf.org/mailman/listinfo/rfc-editor-rfi