From owner-ietf-usefor@mail.imc.org Mon Oct 02 15:21:29 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUTM1-0001DU-4L for usefor-archive@lists.ietf.org; Mon, 02 Oct 2006 15:21:29 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUTLz-0003sZ-LY for usefor-archive@lists.ietf.org; Mon, 02 Oct 2006 15:21:29 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k92JJaSu032629; Mon, 2 Oct 2006 12:19:36 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k92JJa4Z032628; Mon, 2 Oct 2006 12:19:36 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k92JJYuw032620 for ; Mon, 2 Oct 2006 12:19:35 -0700 (MST) (envelope-from mibsoft@mibsoftware.com) Received: (qmail 10053 invoked from network); 2 Oct 2006 19:19:33 -0000 Received: from unknown (HELO ?192.168.2.11?) (unknown) by unknown with SMTP; 2 Oct 2006 19:19:33 -0000 X-pair-Authenticated: 216.37.223.2 Message-ID: <4521664A.8030902@mibsoftware.com> Date: Mon, 02 Oct 2006 15:19:38 -0400 From: "Forrest J. Cavalier III" User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harald Tveit Alvestrand CC: Usefor Mailing List Subject: USEFOR last call, point of order Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Harald, I expect a chair to be somewhat of a cheerleader and have an interest in moving things forward. But the chair should be impartial when complying with release procedures. Good executive decisions at the level of the IESG can only be made based on accurate assessments, and "spin" is not acceptable. I think your submission to the IESG requesting last call was biased. Can you explain? 1. I disagree with the idea that it should be published in the event the WG closes. If a WG closes, it is because procedures were not being followed. Why is it reasonable to assume work products that resulted from a flawed process should be accepted? I would think an explicit justification should be presented. 2. There have to be interoperating implementations before it can be standardized, and it should be clearer that there aren't even experimental implementations for some of it. I am not sure that even bare requirements for submitting for last call are met here. That was not clear in your submission. 3. I think the "nobody threatened to appeal" is a hope, not a statement of the risk that someone appeals. You never asked in the group. Did you ask anyone else? Especially when so many good reviewers left the group? 4. You claimed "rough consensus." Is there a reason that the actual poll results 6/10 were not made clear? There is a 2/7 reject/reviewer ratio discernable in the last paragraph, but not stated as a ratio. Are IESG executives aware of the controversies and opinions? Are they aware there are so few participants in the poll and that the chairs and editors were part of those counted? 5. I think the IESG should be made aware that the USEPRO editor is on record as saying that USEFOR is not ready until USEPRO is, and that USEPRO is not close. The IESG should be aware of your previous predictions of schedule and milestones. (See my previous e-mail.) And what that means for a range of when USEPRO can be expected to be completed, and with how many participants. I am not that involved with the IETF standards process, so I don't know which of the above warrant comment to higher levels. Thank you. Forrest From owner-ietf-usefor@mail.imc.org Mon Oct 02 15:37:52 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUTbs-0004jO-Qt for usefor-archive@lists.ietf.org; Mon, 02 Oct 2006 15:37:52 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUTbr-0006CD-Ap for usefor-archive@lists.ietf.org; Mon, 02 Oct 2006 15:37:52 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k92JaTg8036661; Mon, 2 Oct 2006 12:36:29 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k92JaT3s036660; Mon, 2 Oct 2006 12:36:29 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k92JaQlF036650 for ; Mon, 2 Oct 2006 12:36:29 -0700 (MST) (envelope-from harald@alvestrand.no) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EB9172596ED; Mon, 2 Oct 2006 21:33:59 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22497-03; Mon, 2 Oct 2006 21:33:54 +0200 (CEST) Received: from [192.168.1.57] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id D85242596BC; Mon, 2 Oct 2006 21:33:53 +0200 (CEST) Message-ID: <45216A31.8070903@alvestrand.no> Date: Mon, 02 Oct 2006 21:36:17 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Forrest J. Cavalier III" Cc: Usefor Mailing List Subject: Re: USEFOR last call, point of order References: <4521664A.8030902@mibsoftware.com> In-Reply-To: <4521664A.8030902@mibsoftware.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Forrest J. Cavalier III wrote: > Harald, > > I expect a chair to be somewhat of a cheerleader and > have an interest in moving things forward. > > But the chair should be impartial when complying with > release procedures. Good executive decisions at the level > of the IESG can only be made based on accurate assessments, > and "spin" is not acceptable. > > I think your submission to the IESG requesting last call > was biased. Can you explain? > > 1. I disagree with the idea that it should be published in the event the > WG closes. If a WG closes, it is because procedures were not > being followed. Why is it reasonable to assume work products that > resulted from a flawed process should be accepted? I would think an > explicit justification should be presented. If the group is closed, the biggest contributing factor I see for making such a decision is lack of interest. Why do you assume that it has to be caused by lack of interest? > > 2. There have to be interoperating implementations before it can be > standardized, and it should be clearer that there aren't even > experimental implementations for some of it. I am not sure that even > bare requirements > for submitting for last call are met here. That was not clear in your > submission. There has to be interoperating implementations before it can be advanced to Draft Standard. This call is for Proposed Standard. Your interpretation of the IETF standards track is erroneous. > > 3. I think the "nobody threatened to appeal" is a hope, not a statement > of the risk that someone appeals. You never asked in the group. Did you > ask anyone else? Especially when so many good reviewers left the group? Nobody's threatened to appeal in any message I've seen on the list. I trust that people who want to appeal are capable of making their own threats. > > 4. You claimed "rough consensus." Is there a reason that the actual > poll results 6/10 were not made clear? There is a 2/7 > reject/reviewer ratio discernable in the last paragraph, but not > stated as a ratio. Are > IESG executives aware of the controversies and opinions? Are they aware > there are so few participants in the poll and that the chairs and editors > were part of those counted? The writeup should make it quite clear that there are very few people left in the group. I do not agree that 6/10 is a correct counting. > > 5. I think the IESG should be made aware that the USEPRO editor is > on record as saying that USEFOR is not ready until USEPRO is, and > that USEPRO is not close. The IESG should be aware of your previous > predictions of schedule and milestones. (See my previous e-mail.) > And what that means for a range of when USEPRO can be expected to be > completed, and with how many participants. The IESG is quite capable of noticing that the group's spent nine years without producing anything, and that I've taken at least one year longer than I first expected to get the first document out the door. That's a cause for pessimism for the next document, and the ADs are aware of this. WRT the USEFOR/USEPRO linkage, the group consensus was not to hold it back; the IETF rules give no special weight to the opinion of an editor of another document. > > I am not that involved with the IETF standards process, so I don't > know which of the above warrant comment to higher levels. In my opinion: None. Your mileage may vary; the IETF process allows anyone to state any opinion to anyone. Harald From owner-ietf-usefor@mail.imc.org Mon Oct 02 15:43:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUTgs-0001yr-Hz for usefor-archive@lists.ietf.org; Mon, 02 Oct 2006 15:43:02 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUTgr-0006eK-6N for usefor-archive@lists.ietf.org; Mon, 02 Oct 2006 15:43:02 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k92Jfelp037112; Mon, 2 Oct 2006 12:41:40 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k92Jfeq1037111; Mon, 2 Oct 2006 12:41:40 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from phobos.pfm-mainz.de (phobos.pfm-mainz.de [145.253.109.94]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k92Jfd6f037095 for ; Mon, 2 Oct 2006 12:41:39 -0700 (MST) (envelope-from rbabel@babylon.pfm-mainz.de) Received: from babylon.pfm-mainz.de (localhost [127.0.0.1]) by phobos.pfm-mainz.de (Postfix) with ESMTP id 7F5641BC01 for ; Mon, 2 Oct 2006 21:41:37 +0200 (CEST) Received: by message-id.pfm-mainz.de (Postfix, from userid 1000) id 4CD552BF403; Mon, 2 Oct 2006 21:41:13 +0200 (CEST) In-Reply-To: <4521664A.8030902@mibsoftware.com> From: rbabel@babylon.pfm-mainz.de (Ralph Babel) To: ietf-usefor@imc.org Subject: Re: USEFOR last call, point of order Message-Id: <20061002194113.4CD552BF403@message-id.pfm-mainz.de> Date: Mon, 2 Oct 2006 21:41:13 +0200 (CEST) Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Forrest J. Cavalier III wrote: > But the chair should be impartial when complying with > release procedures. Good executive decisions at the > level of the IESG can only be made based on accurate > assessments, and "spin" is not acceptable. Just for the record: I'm with Forrest. Too many contributors have left the WG; nonetheless, the number of reported inconsistencies in the draft remains constant. This "last call" looks more like the chair being tired of the lack of progress (and the draft _is_ far from acceptable), but not feeling like shutting down the WG as announced originally as part of the milestone schedule. From owner-ietf-usefor@mail.imc.org Mon Oct 02 20:07:31 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUXop-0002wt-9V for usefor-archive@lists.ietf.org; Mon, 02 Oct 2006 20:07:31 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUXoo-0007Wi-Md for usefor-archive@lists.ietf.org; Mon, 02 Oct 2006 20:07:31 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k93035j5077999; Mon, 2 Oct 2006 17:03:05 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k93035fs077998; Mon, 2 Oct 2006 17:03:05 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from mauve.mrochek.com (206.117.180.234.brandx.net [206.117.180.234] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k93033PQ077990 for ; Mon, 2 Oct 2006 17:03:03 -0700 (MST) (envelope-from ned.freed@mrochek.com) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M7W392M1DS00Q3T9@mauve.mrochek.com> for ietf-usefor@imc.org; Mon, 2 Oct 2006 17:02:59 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M7VSOQGXJ40008CX@mauve.mrochek.com>; Mon, 02 Oct 2006 17:02:58 -0700 (PDT) Cc: Harald Tveit Alvestrand , Usefor Mailing List To: Forrest J Cavalier III Message-id: <01M7W391VPW20008CX@mauve.mrochek.com> Date: Mon, 02 Oct 2006 15:54:17 -0700 (PDT) From: Ned Freed Subject: Re: USEFOR last call, point of order In-reply-to: "Your message dated Mon, 02 Oct 2006 15:19:38 -0400" <4521664A.8030902@mibsoftware.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <4521664A.8030902@mibsoftware.com> Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.1 (/) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 > I expect a chair to be somewhat of a cheerleader and > have an interest in moving things forward. > But the chair should be impartial when complying with > release procedures. Good executive decisions at the level > of the IESG can only be made based on accurate assessments, > and "spin" is not acceptable. > I think your submission to the IESG requesting last call > was biased. Can you explain? I would suggest you familiarize yourself with IETF processes a bit more before making comments of this sort. Just as one point, the last call process is started by the relevant area director (in this case Lisa Dusseault), not by the WG chair. The fact that the process has begun means the relevant area director is comfortable that the necessary procedures have been followed. This doesn't mean the document is ready to become an RFC. That's what the last call is for: To determine whether or not it is ready. > 1. I disagree with the idea that it should be published in the event the > WG closes. If a WG closes, it is because procedures were not > being followed. I'm actually having a hard time coming up with a case where a WG was shut down due to procedures not being followed. Since the chair is responsible for procedural issues the usual remedy in such cases is to replace the chair. The usual reason for shutting down WGs is when they are completely out in the weeds or there's clearly no chance of the group reaching closure. It is also worth noting that approval of a WG changes document handling somewhat but has never been a publication requirement in the IETF. There have been plenty of cases where a WG failed but some of the WG products made it to some form of RFC. There have also been a huge number of cases where non-WG documents became RFCs. > Why is it reasonable to assume work products that > resulted from a flawed process should be accepted? But why would it be unreasonable? Given that the members of WGs are human, there are almost always minor process flaws if you look hard enough. Specifications should succeed or fail on their own merits. Of course there are some sorts of egregious process failures that would merit an objection during last call or even an appeal, but failures to dot i's or cross t's do not rise to this level. IMO nothing you have pointed out rises to the necessary level. In any case, while procedural issues are in order, you are far more likely to get traction by making cogent technical arguments at this point. > I would think an explicit justification should be presented. I know of no basis for calling for such a thing. > 2. There have to be interoperating implementations before it can be > standardized, and it should be clearer that there aren't even experimental > implementations for some of it. I'm sorry, but this is simply not the case. Interoperability requirements apply to the move from proposed to draft, not the move to proposed. (There are some exceptions to this for things like routing protocols but none that apply here.) > I am not sure that even bare requirements > for submitting for last call are met here. That was not clear in your > submission. The bare requirements for last call are just that: Pretty bare. > 3. I think the "nobody threatened to appeal" is a hope, not a statement > of the risk that someone appeals. You never asked in the group. Did you > ask anyone else? Especially when so many good reviewers left the group? And the main reason why we have an IETF-wide last call is so the document can receive wider review. I find it more than a little curious that you would object to an action whose main goal is wider review by claiming that the capacity for good review no longer exists in the group. If anything this is an argument for a last call, not against one. > 4. You claimed "rough consensus." Is there a reason that the actual poll > results 6/10 were not made clear? There is a 2/7 reject/reviewer ratio > discernable in the last paragraph, but not stated as a ratio. Are > IESG executives aware of the controversies and opinions? Are they aware > there are so few participants in the poll and that the chairs and editors > were part of those counted? Only the AD can answer this, but having been an AD myself I'd be enormously surprised if she isn't aware in detail of what has gone on. > 5. I think the IESG should be made aware that the USEPRO editor is > on record as saying that USEFOR is not ready until USEPRO is, and > that USEPRO is not close. The IESG should be aware of your previous > predictions of schedule and milestones. (See my previous e-mail.) > And what that means for a range of when USEPRO can be expected to be > completed, and with how many participants. WGs that are way past their milestone dates are never in short supply in the IETF. Just picking another group at random, I note that all open OPENPGP milestones have dates in 2001. I recall noting one group some time back that was almost seven years past any of their dates. In any case, if all WGs that have missed milestones were shut down there wouldn't be very many groups left. Harald is actually more of a stickler for milestones and whatnot than most, so I'm a bit surprised USEFOR dates have not been updated. I personally think the utility of these tools in a volunteer organization like the IETF is marginal at best. > I am not that involved with the IETF standards process, so I don't > know which of the above warrant comment to higher levels. Unless things have changed dramatically since my time on the IESG the relevant AD reads this list, so your comments have probably been seen. Nevertheless, you can and should send comments directly to the ADs, the IESG, or to the main IETF list. My suggestion, however, is that the better course of action given that the last call has begun is to comment on technical issues in the document itself rather than the process that has gotten us to this point. Ned From owner-ietf-usefor@mail.imc.org Mon Oct 02 20:21:33 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUY2P-00073h-GN for usefor-archive@lists.ietf.org; Mon, 02 Oct 2006 20:21:33 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUY2O-0000WX-3b for usefor-archive@lists.ietf.org; Mon, 02 Oct 2006 20:21:33 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9308gba078533; Mon, 2 Oct 2006 17:08:42 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k9308gSF078532; Mon, 2 Oct 2006 17:08:42 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from shell.peak.org (shell.peak.org [69.59.192.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9308flC078525 for ; Mon, 2 Oct 2006 17:08:42 -0700 (MST) (envelope-from stanley@peak.org) Received: from shell.peak.org (shell.peak.org [127.0.0.1]) by shell.peak.org (8.13.1/8.13.1) with ESMTP id k9308dLa025169 for ; Mon, 2 Oct 2006 17:08:39 -0700 Received: from localhost (stanley@localhost) by shell.peak.org (8.13.1/8.13.1/Submit) with ESMTP id k9308TDM025166 for ; Mon, 2 Oct 2006 17:08:39 -0700 X-Authentication-Warning: shell.peak.org: stanley owned process doing -bs Date: Mon, 2 Oct 2006 17:08:29 -0700 (PDT) From: stanley@peak.org To: ietf-usefor@imc.org Subject: Re: USEFOR last call, point of order Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.2 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Forrest J. Cavalier III wrote: >I think your submission to the IESG requesting last call >was biased. Can you explain? I felt the same when I read it. It is interesting to see in writing that nobody who dished personal insults my way got censured, despite my being told otherwise while it was happening. Harald Alvestrand : >If the group is closed, the biggest contributing factor I see for making >such a decision is lack of interest. Why do you assume that it has to be >caused by lack of interest? You are the one assuming a lack of interest. People do not always leave this group because they lack interest in the outcome. I'd say that one very good reason is when they've seen a draft that they've worked very hard to get to say one thing go away because the editor decided he didn't like what it said. >Nobody's threatened to appeal in any message I've seen on the list. I recall having seen several such messages appear in the list in the past. I don't recall whether I said it explicitely myself, but I know I made my position clear about the process of discussing changes outside the list on a web system that cannot be accessed by anyone who refuses to accept bogus SSL certs. I also recall at least one and perhaps more people saying "it doesn't matter anymore, I'll just appeal it when it gets to IETF." Expecting them to stay around for half a decade just to say it again during this last-last-last-last call is silly. Of course, you just might not have seen them. I think a statement such as "nobody has threatened to appeal" implies that you actually looked to see if they had. From owner-ietf-usefor@mail.imc.org Mon Oct 02 23:46:02 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUbEI-0006O0-8t for usefor-archive@lists.ietf.org; Mon, 02 Oct 2006 23:46:02 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUbEG-0007W8-Eb for usefor-archive@lists.ietf.org; Mon, 02 Oct 2006 23:46:02 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k933iIeI019243; Mon, 2 Oct 2006 20:44:18 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k933iHXW019242; Mon, 2 Oct 2006 20:44:17 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k933iGNa019236 for ; Mon, 2 Oct 2006 20:44:16 -0700 (MST) (envelope-from mibsoft@mibsoftware.com) Received: (qmail 45097 invoked from network); 3 Oct 2006 03:44:15 -0000 Received: from unknown (HELO ?192.168.2.11?) (unknown) by unknown with SMTP; 3 Oct 2006 03:44:15 -0000 X-pair-Authenticated: 216.37.223.2 Message-ID: <4521DC94.9020705@mibsoftware.com> Date: Mon, 02 Oct 2006 23:44:20 -0400 From: "Forrest J. Cavalier III" User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Usefor Mailing List CC: Ned Freed , Forrest J Cavalier III , Harald Tveit Alvestrand Subject: Re: USEFOR last call, point of order References: <4521664A.8030902@mibsoftware.com> <01M7W391VPW20008CX@mauve.mrochek.com> In-Reply-To: <01M7W391VPW20008CX@mauve.mrochek.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 I really appreciate your detailed response. > My suggestion, however, is that the better course of action given that the last > call has begun is to comment on technical issues in the document itself rather > than the process that has gotten us to this point. 1. It is my opinion that most of the technical issues in USEFOR are going to remain hidden until the discussions start on USEPRO, and implementations start to be written. Raising a significant formal objection now is going to be pretty difficult, since USEFOR is a document format, not a protocol. Risk of harm only arises through activity, not format specifications alone. 2. If this were the last and final WG document out the door, rather than the simplest and least contentious of 3 proposed documents, then I would agree that process discussions would be pointless: everything would be done. But we have 90% of the work left to do. 3. It seems that missing a milestone by a year or many years is not rare in WGs. But missing this prediction by a year, something like 5 times as many months as Harald first predicted, and then predicting that the next and more complicated work product will be complete in a year using the same process does not inspire confidence and trust. 4. It seems process is not a grounds for appeal, and a discussion about process is off-topic. If everyone thinks this WG is working well, then carry on. The rest of the software development world has discovered that process explains results. Thank you again, Ned and Harald, for replying. Forrest From owner-ietf-usefor@mail.imc.org Tue Oct 03 00:24:53 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUbpt-0003h1-Ej for usefor-archive@lists.ietf.org; Tue, 03 Oct 2006 00:24:53 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUbpp-0000KO-1R for usefor-archive@lists.ietf.org; Tue, 03 Oct 2006 00:24:53 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k934NCoX030823; Mon, 2 Oct 2006 21:23:12 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k934NCwR030822; Mon, 2 Oct 2006 21:23:12 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp1.stanford.edu (smtp1.Stanford.EDU [171.67.22.28]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k934NBKt030816 for ; Mon, 2 Oct 2006 21:23:11 -0700 (MST) (envelope-from rra@stanford.edu) Received: from smtp1.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EE9F44C63A for ; Mon, 2 Oct 2006 21:23:10 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.stanford.edu (Postfix) with ESMTP id D71EA4C46D for ; Mon, 2 Oct 2006 21:23:10 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id D1550E78DD; Mon, 2 Oct 2006 21:23:10 -0700 (PDT) From: Russ Allbery To: Usefor Mailing List Subject: Re: USEFOR last call, point of order In-Reply-To: <4521DC94.9020705@mibsoftware.com> (Forrest J. Cavalier, III's message of "Mon, 02 Oct 2006 23:44:20 -0400") Organization: The Eyrie References: <4521664A.8030902@mibsoftware.com> <01M7W391VPW20008CX@mauve.mrochek.com> <4521DC94.9020705@mibsoftware.com> Date: Mon, 02 Oct 2006 21:23:10 -0700 Message-ID: <87ac4eauz5.fsf@windlord.stanford.edu> User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Forrest J Cavalier writes: > 4. It seems process is not a grounds for appeal, and a discussion about > process is off-topic. If everyone thinks this WG is working well, then > carry on. The rest of the software development world has discovered > that process explains results. I don't think the WG is working well. I do, however, think that the current USEFOR draft is superior to RFC 1036 as guidance for implementors on Usenet today, and I think it's silly to have a superior document be left in semi-permanent limbo the way that Son-of was. So when weighing the decision of whether to publish or not publish USEFOR, separate from the questions of whether or not we're likely to accomplish all of our goals, it seems to me that it's better for the general community to publish it. As for continued work, well, I'm willing to keep working provided that people are still reviewing and we seem to be converging on something useful. I think we mostly did that with USEFOR. Whether we can do that with USEPRO is very iffy, but we haven't really tried yet, and I don't want to give up without even trying. It's worth pointing out that the NNTP working group also went on for many years past its deadlines and only finally made progress when the WG was down to about five active members, and yet I'm extremely pleased with the documents we produced and which are about to become RFCs. -- Russ Allbery (rra@stanford.edu) From owner-ietf-usefor@mail.imc.org Tue Oct 03 12:19:37 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GUmzZ-0001mx-2d for usefor-archive@lists.ietf.org; Tue, 03 Oct 2006 12:19:37 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GUmzX-0000Ni-E4 for usefor-archive@lists.ietf.org; Tue, 03 Oct 2006 12:19:37 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k93GHFi2047306; Tue, 3 Oct 2006 09:17:15 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k93GHFKa047305; Tue, 3 Oct 2006 09:17:15 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k93GHDEu047296 for ; Tue, 3 Oct 2006 09:17:14 -0700 (MST) (envelope-from lisa@osafoundation.org) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 685B014228C; Tue, 3 Oct 2006 09:17:13 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24844-04; Tue, 3 Oct 2006 09:17:12 -0700 (PDT) Received: from [192.168.1.101] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 86BDF142287; Tue, 3 Oct 2006 09:17:12 -0700 (PDT) In-Reply-To: <20061002194113.4CD552BF403@message-id.pfm-mainz.de> References: <20061002194113.4CD552BF403@message-id.pfm-mainz.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/alternative; boundary=Apple-Mail-31--951080653 Message-Id: Cc: ietf-usefor@imc.org From: Lisa Dusseault Subject: Re: USEFOR last call, point of order Date: Tue, 3 Oct 2006 09:17:09 -0700 To: Ralph Babel X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 789c141a303c09204b537a4078e2a63f --Apple-Mail-31--951080653 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Thanks for your input on the suitability of this draft for publication -- IETF last call is a fine time for this input, as Ned explained. However, note that at this point I'm most interested in seeing justified arguments that the document in last-call now is *worse* than what it is replacing. If the usefor-usefor draft is a higher-quality document, even if it's not perfect, the low WG size/ energy suggests to me that it should replace the older document rather than continue getting slowly and contentiously polished. By the way, I found this to be a well-written doc when I did my own read last week. Without being a netnews implementor I can't necessarily find all inconsistencies but I did find the text generally clear and well-organized. I have thought about some of the reported unaddressed inconsistencies brought up on this list, and did not identify any as being big/bad enough to adversely affect interoperability. I have been reading everything that goes by on the list (though I haven't consulted the tracking system) since March of this year. The publication of a new Proposed Standard document on the Netnews article format should not be considered the last word ever on the topic. If somebody found the energy to revise the document further some day, and found support for that work, it could happen. Improving a standard is generally possible; perfecting it is not. Lisa On Oct 2, 2006, at 12:41 PM, Ralph Babel wrote: > > Forrest J. Cavalier III wrote: > >> But the chair should be impartial when complying with >> release procedures. Good executive decisions at the >> level of the IESG can only be made based on accurate >> assessments, and "spin" is not acceptable. > > Just for the record: I'm with Forrest. > > Too many contributors have left the WG; nonetheless, the > number of reported inconsistencies in the draft remains > constant. This "last call" looks more like the chair being > tired of the lack of progress (and the draft _is_ far from > acceptable), but not feeling like shutting down the WG as > announced originally as part of the milestone schedule. > --Apple-Mail-31--951080653 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Thanks for your input on the suitability of this draft = for publication -- IETF last call is a fine time for this input, as Ned = explained.=A0 However, note that at this point I'm most interested in = seeing justified arguments that the document in last-call now is *worse* = than what it is replacing.=A0 If the usefor-usefor draft is a = higher-quality document, even if it's not perfect, the low WG = size/energy suggests to me that it should replace the older document = rather than continue getting slowly and contentiously = polished.=A0=A0

By = the way, I found this to be a well-written doc when I did my own read = last week. Without being a netnews implementor I can't necessarily find = all inconsistencies but I did find the text generally clear and = well-organized.=A0 I have thought about some of the reported unaddressed = inconsistencies brought up on this list, and did not identify any as = being big/bad enough to adversely affect interoperability.=A0 I have = been reading everything that goes by on the list (though I haven't = consulted the tracking system) since March of this = year.

The= publication of a new Proposed Standard document on the Netnews article = format should not be considered the last word ever on the topic.=A0 If = somebody found the energy to revise the document further some day, and = found support for that work, it could happen.=A0 Improving a standard is = generally possible; perfecting it is not.

Lisa

On Oct 2, 2006, at 12:41 PM, = Ralph Babel wrote:


Forrest = J. Cavalier III wrote:
But the chair = should be impartial when complying with
release = procedures. Good executive decisions at the
level = of the IESG can only be made based on accurate
assessments, and "spin" is not acceptable.
=

Just for the record: I'm with Forrest.

Too many = contributors have left the WG; nonetheless, the
number of reported inconsistencies in the draft = remains
constant. This "last call" looks = more like the chair being
tired of the = lack of progress (and the draft _is_ far from
acceptable), but not feeling like shutting down the = WG as
announced originally as part of = the milestone schedule.


= --Apple-Mail-31--951080653-- From owner-ietf-usefor@mail.imc.org Wed Oct 04 07:16:39 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV4jv-0004CO-2r for usefor-archive@lists.ietf.org; Wed, 04 Oct 2006 07:16:39 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV4iP-0001MU-PE for usefor-archive@lists.ietf.org; Wed, 04 Oct 2006 07:15:11 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k94BC8Ks088607; Wed, 4 Oct 2006 04:12:08 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k94BC8fk088606; Wed, 4 Oct 2006 04:12:08 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-4.gradwell.net (lon-mail-4.gradwell.net [193.111.201.130]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k94BC5c7088586 for ; Wed, 4 Oct 2006 04:12:07 -0700 (MST) (envelope-from news@clerew.man.ac.uk) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3*clerew&man*ac#uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.231) id 45239704.4954.34bf for ietf-usefor@imc.org; Wed, 4 Oct 2006 12:12:04 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id k94BC2Lo022910 for ; Wed, 4 Oct 2006 12:12:03 +0100 (BST) Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id k94BC2Rx022906 for ietf-usefor@imc.org; Wed, 4 Oct 2006 12:12:02 +0100 (BST) To: ietf-usefor@imc.org Xref: clerew local.usefor:23663 Path: clerew!chl From: "Charles Lindsey" Subject: Re: USEFOR last call, point of order Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: <4521664A.8030902@mibsoftware.com> <01M7W391VPW20008CX@mauve.mrochek.com> <4521DC94.9020705@mibsoftware.com> Date: Wed, 4 Oct 2006 10:40:29 GMT Lines: 31 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 In <4521DC94.9020705@mibsoftware.com> "Forrest J. Cavalier III" writes: >I really appreciate your detailed response. >> My suggestion, however, is that the better course of action given that the last >> call has begun is to comment on technical issues in the document itself rather >> than the process that has gotten us to this point. >1. It is my opinion that most of the technical issues in USEFOR are going to >remain hidden until the discussions start on USEPRO, and implementations start >to be written. Raising a significant formal objection now is going to be pretty >difficult, since USEFOR is a document format, not a protocol. Risk of harm only >arises through activity, not format specifications alone. Then your proper course of action is to recommend to the IESG that they decline to publish it until they see USEPRO (that is also my own view, but I accept that the consensus was against me). But you have given no cogent reason for absolute rejection of the document. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor@mail.imc.org Wed Oct 04 11:41:14 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GV8ry-0002Dd-37 for usefor-archive@lists.ietf.org; Wed, 04 Oct 2006 11:41:14 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GV8rv-0000SQ-Lf for usefor-archive@lists.ietf.org; Wed, 04 Oct 2006 11:41:14 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k94FcndI043826; Wed, 4 Oct 2006 08:38:49 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k94FcnFL043825; Wed, 4 Oct 2006 08:38:49 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k94FclQW043817 for ; Wed, 4 Oct 2006 08:38:48 -0700 (MST) (envelope-from mibsoft@mibsoftware.com) Received: (qmail 74884 invoked from network); 4 Oct 2006 15:38:46 -0000 Received: from unknown (HELO ?192.168.2.11?) (unknown) by unknown with SMTP; 4 Oct 2006 15:38:46 -0000 X-pair-Authenticated: 208.111.196.23 Message-ID: <4523D57F.5060509@mibsoftware.com> Date: Wed, 04 Oct 2006 11:38:39 -0400 From: "Forrest J. Cavalier III" User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-usefor@imc.org Subject: Re: USEFOR last call, point of order References: <4521664A.8030902@mibsoftware.com> <01M7W391VPW20008CX@mauve.mrochek.com> <4521DC94.9020705@mibsoftware.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Charles Lindsey wrote: > In <4521DC94.9020705@mibsoftware.com> "Forrest J. Cavalier III" writes: > > >>I really appreciate your detailed response. > > >>>My suggestion, however, is that the better course of action given that the last >>>call has begun is to comment on technical issues in the document itself rather >>>than the process that has gotten us to this point. > > >>1. It is my opinion that most of the technical issues in USEFOR are going to >>remain hidden until the discussions start on USEPRO, and implementations start >>to be written. Raising a significant formal objection now is going to be pretty >>difficult, since USEFOR is a document format, not a protocol. Risk of harm only >>arises through activity, not format specifications alone. > > > Then your proper course of action is to recommend to the IESG that they > decline to publish it until they see USEPRO (that is also my own view, but > I accept that the consensus was against me). > > But you have given no cogent reason for absolute rejection of the > document. > It was the third way I was searching for. Discuss the process. Discuss how USEFOR came to be submitted for last call, and if that was proper. Discuss how soon the clean up to USEFOR (that USEPRO will cause) will happen. I agree that "Perfect draft" is unreasonable. But there is a continuum of imperfection. We have a disagreement in the WG about how ready the document is. That disagreement was NOT apparent or highlighted by the submission from Alexey. The IESG gives no more weight to the USEPRO editor's view than others, which is weird, considering how USEFOR came to be a piece split off from a larger work, and the significant interdependencies between them. If USEFOR were a strict documentation of existing practice, my opinion would be different. So, Charles is correct that I have given no reason for absolute rejection of the document. I don't think it should be absolutely rejected. I agree it is an improvement over those parts of previous standards. And that is what the IESG is looking for: some improvement. That's a pretty low bar. If "minimal improvement over 1036" was the bar of acceptance, then we could have submitted long, long, long ago. We could have used Son-Of-1036. But that was NOT the charter. If that is the bar, then no Format standard that proposes new features can be appealed. Is that what the IESG rules intend? If one were to try to appeal to the IESG to reject USEFOR now, most likely it would be based on something that USEPRO draft says now. (As I said, activities create risk, not mere format specifications.) But an appeal on that basis would be dismissed by saying "Well, USEPRO is just a draft, we can fix it in USEPRO." Saying that it is fixable in USEPRO is pure hubris, (some format flaws cannot be overcome by protocol.) Saying that USEPRO will be fixed in any particular time frame is not supported by the track record of this WG. Isn't there a third way? Apparently not. I predict the end result of all this will be is a confusing set of conflicting or incomplete standards issued from a single WG, and no one left interested in cleaning it up. The people who can act to prevent that are the chair and the AD. From owner-ietf-usefor@mail.imc.org Wed Oct 04 23:30:24 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVJwG-0003jR-8R for usefor-archive@lists.ietf.org; Wed, 04 Oct 2006 23:30:24 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVJsx-0002Na-Rg for usefor-archive@lists.ietf.org; Wed, 04 Oct 2006 23:27:00 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k953NdKN027054; Wed, 4 Oct 2006 20:23:39 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k953NdmK027053; Wed, 4 Oct 2006 20:23:39 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k953Nci6027039 for ; Wed, 4 Oct 2006 20:23:38 -0700 (MST) (envelope-from news@clerew.man.ac.uk) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3&clerew$man^ac^uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.232) id 45247ab9.f462.11f for ietf-usefor@imc.org; Thu, 5 Oct 2006 04:23:37 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id k953NaK1005864 for ; Thu, 5 Oct 2006 04:23:36 +0100 (BST) Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id k953NaQo005861 for ietf-usefor@imc.org; Thu, 5 Oct 2006 04:23:36 +0100 (BST) To: ietf-usefor@imc.org Xref: clerew local.usefor:23666 Path: clerew!chl From: "Charles Lindsey" Subject: USEPRO: Path header Message-ID: X-Newsreader: NN version 6.5.2 (NOV) Date: Wed, 4 Oct 2006 21:23:55 GMT Lines: 348 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: fca741f5016e6ff607eaed2fd431d10d Since USEFOR is now on its way to IETF Last Call, I presume it is now in order to discuss USEPRO. I would like to start with the Path header, because we made a lot of changes to that in USEFOR, and USEPRO needs to catch up. I also have various other tidyings to propose, but they can wait a couple of days while I sort them out. So please let us just stick to the Path header for the moment. The following text deals with all the changes which seem to be required. There are alternatives suggested at several places which need to be discussed, and there is a special request to Richard Clayton to explain the reasons why demon still need to use the "demon", so that I can include it in the example. Share and Enjoy! 2.3. Identification of news servers [There are two alternative texts which have been proposed:] In order to record the passage of articles through the network, news servers need to identify themselves by means of a (F-3.1.5), which can appear in Path, Injection-Info and Xref header fields. Whatever is used in the Path header field SHOULD be used also in any Injection-Info header field (and it would be normal to use it in any Xref header field also). [Maybe that last sentence moves elsewhere.] NOTE: Such s may also be suitable for sending email to news server administrators (see [USEAGE]). [1st alternative] s can take the following forms (in decreasing order of preference): 1. A fully qualified domain name (FQDN) that SHOULD be resolvable in the DNS (whether via an A, AAAA or MX record or an equivalent CNAME), thus guaranteeing a unique identity. Ideally, it will also provide a means to contact the administrators by email (according to [RFC 2142], the forms "usenet@server" and "news@server" are common addresses for a news server administrator). | 2. Some other (arbitrary) name in the form of a , and | believed to be unique and registered at least with all other news servers sending articles directly to the given one. This option SHOULD NOT be used unless the earlier option is unavailable (e.g. because the server in question is not connected to the Internet), or unless it is of longstanding usage and cessation would be unduly disruptive, or unless the earlier option is provided as well. [2nd alternative] s can take the following forms (in decreasing order of preference): 1. A fully qualified domain name (FQDN) that can be resolved to an email server via an MX, A or AAAA record according to the procedures of [RFC 2821]; this guarantees that the name is unique, and makes it easy to contact the administrators if needed. 2. A fully qualified domain name (FQDN) that is guaranteed to be unique by the administrators of the domain; for instance, the uniqueness of "server.example.org" could be guaranteed by the administrator of "example.org" even if nothing is stored in the DNS for that name. | 3. Some other (arbitrary) name in the form of a , and | believed to be unique and registered at least with all other news-servers sending articles directly to the given one. This option SHOULD NOT be used unless the earlier options are unavailable, or unless the name is of longstanding usage and cessation would be unduly disruptive, or unless one of the earlier options is provided as well. According to [RFC 2142]], the forms "usenet@server" and "news@server" are common addresses for a news server administrator. [end of alternatives] | NOTE: Although domain names are case insensitive and it is | intended that s should also be so, it is customary | to render them all in lowercase, since many implementations | compare them case sensitively for reasons of efficiency. | NOTE: A news server administrator who chooses a | which turns out not to be unique (disregarding case) will have to bear the consequences. | NOTE: An IP address is not permitted as a , | although it may still appear in a . Since the | syntax permits a colon (":" which, prior to this standard, was | an alternative to the "!" delimiter) within any | which takes the form of an , it would be unwise to | choose as a anything composed solely from four or | less hexadecimal digits. 3.2. Transitional Arrangements | o The new style of Path header field, using a to allow | "!!" as a delimiter> and introducing s (which | can be distinguished from s by their leading ".") is already consistent with the previous standards. However, the intention is that relaying agents should eventually reject articles in the old style, and so this possibility should be offered as a configurable option in relaying agents. User agents are unaffected. 7. Duties of Various Agents In this section, the word "trusted", as applied to the source of some article, means that an agent processing that article has verified, by some means, the identity of that source (which may be another agent or a poster). [I am proposing to s/trusted identity/verified identity/ throughout this chapter, as it seems to convey the sense better; anyone have any problems with this?] 7.2. Duties of an Injecting Agent In the normal course of events, an article that has already been injected into a Netnews network will never pass through another injecting agent. So, if an injecting agent receives an otherwise valid article that has already been injected (as evidenced by the presence of an Injection-Date header field, an Injection-Info header | field, or more than one occurrence of the "POSTED" in a Path header field) it MAY choose to reject it, but otherwise SHOULD cause it to be relayed, as it stands, by a relaying agent (7.3). 7.2.1. Proto-articles NOTE: An article that is offered for reinjection has, by definition, already been injected once, and is not therefore to be considered as a proto-article. Hence a genuine proto-article | will not contain any Injection-Date header field nor the "POSTED" anywhere in its Path header field, though that header field MAY contain s corresponding to machines traversed between the posting agent and the injecting agent proper. 7.2.2. Procedure to be followed by Injecting Agents 10. It MUST then prepend the of the injecting agent, | followed by '!.' and the "POSTED", and then a | further "!", to the content of the Path header field; this header field SHOULD then be folded if it would otherwise result in a header line of excessive length. 7.3. Duties of a Relaying Agent In order to avoid unnecessary relaying, an article SHOULD NOT be relayed if the of the receiving agent (or some known | alias thereof) appears as a in its Path header field. | But note that the (which follows the last "!") is not a | , although not all current implementations observe | this distinction. | For this to work, each relaying agent needs to insert it own (chosen according to 2.3) into the Path header field. It | MAY insert more than one for itself (in which case | the leftmost should be the one by which it is known to its immediate | neighbours), but where an article passes through several relaying | agents at the same site it MAY omit the s for some of | them (but NOT the one which finally relays it to an outside site). | It MAY (and usually SHOULD) also add a giving | additional information concerning the route taken by the article | through the network. A consists of either the | special "!" (which effectively replaces the standard | delimiter "!" by "!!"), or it is composed from a usually | followed by a . The following are the only s defined by this standard: | o "POSTED" (already introduced in Step 10 of 7.2.2), which is never | followed by a ; | o "SEEN", whose following indicates the trusted | identity (see 7) of the agent from which the article was received | (but makes no claim as to whether it matched the indicates the trusted | identity of the agent from which the article was received and | asserts that it could not be reconciled with the | (supposedly) inserted by that agent. | Other s beginning with "X" MAY be used by a relaying | agent to make some assertion not envisaged here, but other (non-"X") | s MUST NOT be used unless defined by some extension to | this standard. | NOTE: The "MATCH", which might have indicated the | trusted identity of the source agent with an assertion that it | agreed with the inserted by that agent, has NOT | been provided, since the special conveys exactly | that meaning for this commonly occurring case. | NOTE: Whilst s are case insensitive, it is | intended that they should normally be rendered in uppercase. A relaying agent processes articles as follows: | 1. It MUST/SHOULD establish the trusted identity of the source of the article and compare it with the leftmost of | the existing Path header field's content. Except possibly when | relaying to other hosts on the same site, It then MUST or | SHOULD, as indicated, prepend to that content (from left to | right) the following: | o (MUST) its own ; | o (MUST) a "!" delimiter; | o (MUST/SHOULD) if the trusted and existing identities match, a | (effectively converting the "!" delimiter into | "!!"); | o (MUST/SHOULD) alternatively, where the identities do not | match (or have not been determied to match), a ".", the | "MISMATCH" (or "SEEN"), another ".", a indicating the trusted identity, and finally a | further "!"; | o possibly further s etc. as above, identifying | itself. | This header field SHOULD then be folded if it would otherwise | result in a header line of excessive length. [The "MUST/SHOULD"s above were all "MUST" in the previous drafts. Discussion is needed to resolve this.] | NOTE: Since each agent at one site can be assumed to be aware of | the identity of the others (and of itself), it would be most | unusual for their s to be separated other than by | "!!". Thus the presence of a single "!", unless followed by a | "." and some , can be taken as signifying an agent | that has not yet been upgraded to conform to this standard. | NOTE: Whilst the presence of a "MISMATCH" would normally | indicate that the existing Path was bogus in some sense, it | could also indicate that the ralaying agent was improperly | configured to recognise the identities or aliases used by its | neighbours. Administators of relaying agents should therefore | periodically monitor the being inserted so as | to avoid this. NOTE: In order to prevent overloading, relaying agents should not routinely query an external entity (such as a DNS-server) in order to determine a trusted identity (though a local cache of the required information might usefully be consulted). 7.3.1. Path Header Field Example | Path: bar.isp.example!.SEEN.news3.foo.isp.example!foo.isp.example | !!foo-server!.MISMATCH.2001:DB8:0:0:8:800:200C:417A | !dubious.site.example!!old.site.example!barbaz!!baz.isp.example | !.POSTED!dialup123.baz.isp.example!not-for-mail NOTE: That article was injected into the news stream by | baz.isp.example, as indicated by the "POSTED" (complaints may be addressed to abuse@baz.isp.example). The injector has chosen to record that it got it from dialup123.baz.isp.example. "not-for-mail" is a dummy , though sometimes a real userid is put there. The article was relayed, perhaps by UUCP, to the machine known, at least to old.site.example, as "barbaz". Barbaz relayed it to old.site.example, which does not yet | conform to this standard (hence the single '!' delimiter). So one cannot be sure that it really came from barbaz. | Old.site.example relayed it to a site claiming to be | dubious.site.example, and claiming (by using the '!!' | delimiter) to have verified that it came from old.site.example. | Dubious.site.example relayed it to "foo-server" which, not being | convinced that it truly came from dubious.site.example, and | knowing that it in fact arrived from a host with the IPv6address | [2001:DB8:0:0:8:800:200C:417A], inserted the | "!.MISMATCH.2001:DB8:0:0:8:800:200C:417A" (that is not to say | that [2001:DB8:0:0:8:800:200C:417A] was not a correct IPv6 | address for dubious-site.example, but simply that that | connection could not be substantiated by foo-server). "foo-server" is a locally significant name within the complex site of many machines run by foo.isp.example, so the latter should have no problem recognizing foo-server and using a '!!' | delimiter. It was not strictly necessary to insert the "foo-server" as well as "foo.isp.example" (but maybe | some site elsewhere had some reason to test for it). [Please could Richard Clayton provide a more plausible reason why "foo- server" might be a here?] | It then went to bar.isp.example which determined (by reverse | DNS) that it had come from news3.foo.isp.example, but had taken | no steps to check whether that was a known alias for | foo.isp.example (which it probably was). Strictly, it SHOULD | have made such a check, and then inserted either a "!!" or a | "!MISMATCH..." according to the result. | Presumably bar.isp.example then delivered the article to its direct clients. | It appears that foo.isp.example, foo-server and baz.isp.example decided to fold the line, on the grounds that it seemed to be | getting a little too long. Note that folding and whitespace is | permitted before (but not after) any "!" (but not within a | "!!"); hence continuation lines will always start with either | "!" or "!!". 7.4. Duties of a Serving Agent A serving agent processes articles as follows: | 1. It MUST/SHOULD establish the trusted identity of the source of the article and modify the Path header field as for a relaying agent (7.3). 7.8. Duties of a Moderator 5. Any variant header fields (2.4) MUST be removed, except that a Path header field MAY be truncated to only those entries following | its "POSTED" . Any Injection-Info header field (F- 3.2.8 SHOULD be removed (and if not, the injecting agent will do so, as required in 7.2.2). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor@mail.imc.org Wed Oct 04 23:30:25 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVJwH-0003k7-7i for usefor-archive@lists.ietf.org; Wed, 04 Oct 2006 23:30:25 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVJrd-0002DB-9p for usefor-archive@lists.ietf.org; Wed, 04 Oct 2006 23:25:43 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k953NdMI027046; Wed, 4 Oct 2006 20:23:39 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k953Nd5o027045; Wed, 4 Oct 2006 20:23:39 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k953NbSe027038 for ; Wed, 4 Oct 2006 20:23:38 -0700 (MST) (envelope-from news@clerew.man.ac.uk) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3#clerew$man&ac#uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.232) id 45247ab8.f4ed.ee for ietf-usefor@imc.org; Thu, 5 Oct 2006 04:23:36 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id k953NZ5d005856 for ; Thu, 5 Oct 2006 04:23:35 +0100 (BST) Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id k953NZ1p005853 for ietf-usefor@imc.org; Thu, 5 Oct 2006 04:23:35 +0100 (BST) To: ietf-usefor@imc.org Xref: clerew local.usefor:23665 Path: clerew!chl From: "Charles Lindsey" Subject: NIGGLE: uppercase, upper case, upper-case Message-ID: X-Newsreader: NN version 6.5.2 (NOV) Date: Wed, 4 Oct 2006 21:07:13 GMT Lines: 19 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.2 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 In USEFOR, I find two occurrences of "uppercase", and one each of "lower case" and "lower-case". I think we discussed this before, and agreed on "uppercase" (but seemingly the change did not propagate to the lower occurrences). In USEPRO, I am intending to use "uppercase" and "lowercase" wherever they occur. If this is agreeable, then I suggest Ken just adds these two aberrations to his niggle-list. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor@mail.imc.org Thu Oct 05 03:37:26 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVNnK-0006Ix-4r for usefor-archive@lists.ietf.org; Thu, 05 Oct 2006 03:37:26 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVNnI-0006bv-Px for usefor-archive@lists.ietf.org; Thu, 05 Oct 2006 03:37:26 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k957Xh47055911; Thu, 5 Oct 2006 00:33:43 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k957Xhjt055910; Thu, 5 Oct 2006 00:33:43 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from proof.pobox.com (postfix@proof.pobox.com [207.106.133.28]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k957Xg7C055898 for ; Thu, 5 Oct 2006 00:33:43 -0700 (MST) (envelope-from McQuilWP@pobox.com) Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id EAFF829A8B; Thu, 5 Oct 2006 03:34:03 -0400 (EDT) Received: from MCQWP2 (ip72-197-112-82.sd.sd.cox.net [72.197.112.82]) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 88DF87D4CB; Thu, 5 Oct 2006 03:34:02 -0400 (EDT) Date: Thu, 5 Oct 2006 00:33:39 -0700 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <1414115487.20061005003339@pobox.com> To: Usenet Subject: Re: USEPRO: Path header In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.2 (+) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 On Wed, 2006-10-04, Charles Lindsey wrote: > [I am proposing to s/trusted identity/verified identity/ throughout this > chapter, as it seems to convey the sense better; anyone have any > problems with this?] I wonder if it might be more accurate to refer to a "verified identifier" and to s/identity/identifier/ in the subsequent text. Since what is being verified is a name rather than an agent itself, this may make it clearer that there could be aliases either known or unknown. -- Bill McQuillan From owner-ietf-usefor@mail.imc.org Thu Oct 05 11:27:15 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVV7z-0000uw-EM for usefor-archive@lists.ietf.org; Thu, 05 Oct 2006 11:27:15 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVV7y-0000t0-2A for usefor-archive@lists.ietf.org; Thu, 05 Oct 2006 11:27:15 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k95FK2sG017349; Thu, 5 Oct 2006 08:20:02 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k95FK2PX017348; Thu, 5 Oct 2006 08:20:02 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k95FJxJn017307 for ; Thu, 5 Oct 2006 08:20:00 -0700 (MST) (envelope-from usenet-format@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GVUyX-0001vA-Ns for ietf-usefor@imc.org; Thu, 05 Oct 2006 17:17:29 +0200 Received: from pd9fba984.dip0.t-ipconnect.de ([217.251.169.132]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Oct 2006 17:17:29 +0200 Received: from nobody by pd9fba984.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Oct 2006 17:17:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-usefor@imc.org From: Frank Ellermann Subject: Re: USEFOR last call, point of order Date: Thu, 05 Oct 2006 17:08:02 +0200 Organization: Lines: 26 Message-ID: <45251FD1.5CE6@xyzzy.claranet.de> References: <4521664A.8030902@mibsoftware.com> <01M7W391VPW20008CX@mauve.mrochek.com> <4521DC94.9020705@mibsoftware.com> <87ac4eauz5.fsf@windlord.stanford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba984.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Russ Allbery wrote: > the current USEFOR draft is superior to RFC 1036 as guidance for > implementors on Usenet today, and I think it's silly to have a superior > document be left in semi-permanent limbo the way that Son-of was. [...] > it seems to me that it's better for the general community to publish it +1 > I'm willing to keep working provided that people are still reviewing > and we seem to be converging on something useful. I think we mostly > did that with USEFOR. Whether we can do that with USEPRO is very iffy, > but we haven't really tried yet, and I don't want to give up without > even trying. +1. Getting it right for USEPRO based on Usefor-10 is IMO possible, we have a clean data structure (= usefor, the format), and most procedures (= usepro) on this data should be obvious. Nothing radical, maybe some controversies about MUST vs. SHOULD wrt new implementations, there's no showstopper in sight from my POV. I hope that the s-o-1036 parts about gateways will be integrated into USEPRO (and IIRC that was already okay in all USEPRO drafts): Above all avoid loops. Frank From owner-ietf-usefor@mail.imc.org Thu Oct 05 12:21:23 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVVyN-0003hw-7U for usefor-archive@lists.ietf.org; Thu, 05 Oct 2006 12:21:23 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVVyI-0001AQ-Q5 for usefor-archive@lists.ietf.org; Thu, 05 Oct 2006 12:21:23 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k95GEF9J023842; Thu, 5 Oct 2006 09:14:15 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k95GEFrZ023841; Thu, 5 Oct 2006 09:14:15 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k95GEC7G023829 for ; Thu, 5 Oct 2006 09:14:14 -0700 (MST) (envelope-from news@clerew.man.ac.uk) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3#clerew&man#ac*uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.232) id 45252ed6.3f6b.231 for ietf-usefor@imc.org; Thu, 5 Oct 2006 17:12:06 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id k95GC3Z2003326 for ; Thu, 5 Oct 2006 17:12:04 +0100 (BST) Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id k95GC3NN003322 for ietf-usefor@imc.org; Thu, 5 Oct 2006 17:12:03 +0100 (BST) To: ietf-usefor@imc.org Xref: clerew local.usefor:23669 Path: clerew!chl From: "Charles Lindsey" Subject: Re: USEPRO: Path header Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: <1414115487.20061005003339@pobox.com> Date: Thu, 5 Oct 2006 11:49:41 GMT Lines: 39 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 In <1414115487.20061005003339@pobox.com> Bill McQuillan writes: >On Wed, 2006-10-04, Charles Lindsey wrote: >> [I am proposing to s/trusted identity/verified identity/ throughout this >> chapter, as it seems to convey the sense better; anyone have any >> problems with this?] >I wonder if it might be more accurate to refer to a "verified identifier" >and to s/identity/identifier/ in the subsequent text. Actually, looking at the instances of "trusted" in that chapter, the phrase used is usually "trusted identity of the source" or "trusted source" or "trusted agent". I probably ought to make the usage consistent. There are also some occurrences of "trusted" that should remain as such (e.g. whether you are going to trust some issuer of cancels or control messages even though his identity is not in doubt). >Since what is being verified is a name rather than an agent itself, this may >make it clearer that there could be aliases either known or unknown. I think what you are identifying is the source of the article; then whether the name supplied matches that source; and finally you use that name in an Injection-Info or in a . So I think what you have is indeed a "verified identity of the source", whatever wording you choose to use. But I am open to further opinions -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 From owner-ietf-usefor@mail.imc.org Fri Oct 06 15:07:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GVv2V-0008B3-Mm for usefor-archive@lists.ietf.org; Fri, 06 Oct 2006 15:07:19 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GVv2U-0004qx-AN for usefor-archive@lists.ietf.org; Fri, 06 Oct 2006 15:07:19 -0400 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k96J3BkO084490; Fri, 6 Oct 2006 12:03:11 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k96J3BT4084489; Fri, 6 Oct 2006 12:03:11 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k96J39Mq084479 for ; Fri, 6 Oct 2006 12:03:09 -0700 (MST) (envelope-from usenet-format@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GVuxM-0002MO-Aq for ietf-usefor@imc.org; Fri, 06 Oct 2006 21:02:02 +0200 Received: from d253244.dialin.hansenet.de ([80.171.253.244]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Oct 2006 21:02:00 +0200 Received: from nobody by d253244.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Oct 2006 21:02:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-usefor@imc.org From: Frank Ellermann Subject: Re: Gen-art review of draft-ietf-usefor-usefor-10.txt Date: Fri, 06 Oct 2006 20:57:33 +0200 Organization: Lines: 36 Message-ID: <4526A71C.29E@xyzzy.claranet.de> References: <4525FDE4.3090400@ericsson.com> <45260E5A.7060409@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d253244.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: X-Spam-Score: 1.8 (+) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Harald Alvestrand wrote: [about [FWS in the prose] > one possible solution is to replace "[FWS]" with the text > "optional FWS" where that is the intended meaning. 1: Not in the note about in chapter 2.2, there it's [FWS] as seen in the ABNF of RFC 2822. 2: The ..."comments (CFWS):" at the begin of chater 3 is also okay. 3: 3.1.4 (see below) Newsgroups 4: 3.2.4 (see below) Distribution 5: 3.2.6 (see below) Followup-To 6: The [CFWS] in chapter 3.2.8 Injection-Info is okay 7: Both CFWS without square brackets in 3.2.10 References are okay 9: The [FWS] in appendix B about Newsgroups isn't wrong. 10: The CFWS in appendix C about References is okay (see 7). My editor claims that's all outside of ABNF. > the [FWS] in the text (not grammar) of section 3.1.4 should > have been "FWS" without brackets Makes sense. > same for section 3.2.4, 3.2.5, 3.2.8 s/3.2.5/3.2.6/ (3.2.5 is Expires, no explicit FWS issue) IMO the [CFWS] in 3.2.8 is okay. With that we'd get three cases of s/[FWS]/optional FWS/ in the prose: 3.1.4, 3.2.4, and 3.2.6 Frank Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k96J3BkO084490; Fri, 6 Oct 2006 12:03:11 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k96J3BT4084489; Fri, 6 Oct 2006 12:03:11 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k96J39Mq084479 for ; Fri, 6 Oct 2006 12:03:09 -0700 (MST) (envelope-from usenet-format@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GVuxM-0002MO-Aq for ietf-usefor@imc.org; Fri, 06 Oct 2006 21:02:02 +0200 Received: from d253244.dialin.hansenet.de ([80.171.253.244]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Oct 2006 21:02:00 +0200 Received: from nobody by d253244.dialin.hansenet.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 06 Oct 2006 21:02:00 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-usefor@imc.org From: Frank Ellermann Subject: Re: Gen-art review of draft-ietf-usefor-usefor-10.txt Date: Fri, 06 Oct 2006 20:57:33 +0200 Organization: Lines: 36 Message-ID: <4526A71C.29E@xyzzy.claranet.de> References: <4525FDE4.3090400@ericsson.com> <45260E5A.7060409@alvestrand.no> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: d253244.dialin.hansenet.de X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Harald Alvestrand wrote: [about [FWS in the prose] > one possible solution is to replace "[FWS]" with the text > "optional FWS" where that is the intended meaning. 1: Not in the note about in chapter 2.2, there it's [FWS] as seen in the ABNF of RFC 2822. 2: The ..."comments (CFWS):" at the begin of chater 3 is also okay. 3: 3.1.4 (see below) Newsgroups 4: 3.2.4 (see below) Distribution 5: 3.2.6 (see below) Followup-To 6: The [CFWS] in chapter 3.2.8 Injection-Info is okay 7: Both CFWS without square brackets in 3.2.10 References are okay 9: The [FWS] in appendix B about Newsgroups isn't wrong. 10: The CFWS in appendix C about References is okay (see 7). My editor claims that's all outside of ABNF. > the [FWS] in the text (not grammar) of section 3.1.4 should > have been "FWS" without brackets Makes sense. > same for section 3.2.4, 3.2.5, 3.2.8 s/3.2.5/3.2.6/ (3.2.5 is Expires, no explicit FWS issue) IMO the [CFWS] in 3.2.8 is okay. With that we'd get three cases of s/[FWS]/optional FWS/ in the prose: 3.1.4, 3.2.4, and 3.2.6 Frank Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k95GEF9J023842; Thu, 5 Oct 2006 09:14:15 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k95GEFrZ023841; Thu, 5 Oct 2006 09:14:15 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-1.gradwell.net (lon-mail-1.gradwell.net [193.111.201.125]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k95GEC7G023829 for ; Thu, 5 Oct 2006 09:14:14 -0700 (MST) (envelope-from news@clerew.man.ac.uk) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3#clerew&man#ac*uk) by lon-mail-1.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.232) id 45252ed6.3f6b.231 for ietf-usefor@imc.org; Thu, 5 Oct 2006 17:12:06 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id k95GC3Z2003326 for ; Thu, 5 Oct 2006 17:12:04 +0100 (BST) Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id k95GC3NN003322 for ietf-usefor@imc.org; Thu, 5 Oct 2006 17:12:03 +0100 (BST) To: ietf-usefor@imc.org Xref: clerew local.usefor:23669 Path: clerew!chl From: "Charles Lindsey" Subject: Re: USEPRO: Path header Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: <1414115487.20061005003339@pobox.com> Date: Thu, 5 Oct 2006 11:49:41 GMT Lines: 39 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <1414115487.20061005003339@pobox.com> Bill McQuillan writes: >On Wed, 2006-10-04, Charles Lindsey wrote: >> [I am proposing to s/trusted identity/verified identity/ throughout this >> chapter, as it seems to convey the sense better; anyone have any >> problems with this?] >I wonder if it might be more accurate to refer to a "verified identifier" >and to s/identity/identifier/ in the subsequent text. Actually, looking at the instances of "trusted" in that chapter, the phrase used is usually "trusted identity of the source" or "trusted source" or "trusted agent". I probably ought to make the usage consistent. There are also some occurrences of "trusted" that should remain as such (e.g. whether you are going to trust some issuer of cancels or control messages even though his identity is not in doubt). >Since what is being verified is a name rather than an agent itself, this may >make it clearer that there could be aliases either known or unknown. I think what you are identifying is the source of the article; then whether the name supplied matches that source; and finally you use that name in an Injection-Info or in a . So I think what you have is indeed a "verified identity of the source", whatever wording you choose to use. But I am open to further opinions -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k95FK2sG017349; Thu, 5 Oct 2006 08:20:02 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k95FK2PX017348; Thu, 5 Oct 2006 08:20:02 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k95FJxJn017307 for ; Thu, 5 Oct 2006 08:20:00 -0700 (MST) (envelope-from usenet-format@gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GVUyX-0001vA-Ns for ietf-usefor@imc.org; Thu, 05 Oct 2006 17:17:29 +0200 Received: from pd9fba984.dip0.t-ipconnect.de ([217.251.169.132]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Oct 2006 17:17:29 +0200 Received: from nobody by pd9fba984.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 05 Oct 2006 17:17:29 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: ietf-usefor@imc.org From: Frank Ellermann Subject: Re: USEFOR last call, point of order Date: Thu, 05 Oct 2006 17:08:02 +0200 Organization: Lines: 26 Message-ID: <45251FD1.5CE6@xyzzy.claranet.de> References: <4521664A.8030902@mibsoftware.com> <01M7W391VPW20008CX@mauve.mrochek.com> <4521DC94.9020705@mibsoftware.com> <87ac4eauz5.fsf@windlord.stanford.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: pd9fba984.dip0.t-ipconnect.de X-Mailer: Mozilla 3.0 (OS/2; U) Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Russ Allbery wrote: > the current USEFOR draft is superior to RFC 1036 as guidance for > implementors on Usenet today, and I think it's silly to have a superior > document be left in semi-permanent limbo the way that Son-of was. [...] > it seems to me that it's better for the general community to publish it +1 > I'm willing to keep working provided that people are still reviewing > and we seem to be converging on something useful. I think we mostly > did that with USEFOR. Whether we can do that with USEPRO is very iffy, > but we haven't really tried yet, and I don't want to give up without > even trying. +1. Getting it right for USEPRO based on Usefor-10 is IMO possible, we have a clean data structure (= usefor, the format), and most procedures (= usepro) on this data should be obvious. Nothing radical, maybe some controversies about MUST vs. SHOULD wrt new implementations, there's no showstopper in sight from my POV. I hope that the s-o-1036 parts about gateways will be integrated into USEPRO (and IIRC that was already okay in all USEPRO drafts): Above all avoid loops. Frank Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k957Xh47055911; Thu, 5 Oct 2006 00:33:43 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k957Xhjt055910; Thu, 5 Oct 2006 00:33:43 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from proof.pobox.com (postfix@proof.pobox.com [207.106.133.28]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k957Xg7C055898 for ; Thu, 5 Oct 2006 00:33:43 -0700 (MST) (envelope-from McQuilWP@pobox.com) Received: from proof (localhost [127.0.0.1]) by proof.pobox.com (Postfix) with ESMTP id EAFF829A8B; Thu, 5 Oct 2006 03:34:03 -0400 (EDT) Received: from MCQWP2 (ip72-197-112-82.sd.sd.cox.net [72.197.112.82]) by proof.sasl.smtp.pobox.com (Postfix) with ESMTP id 88DF87D4CB; Thu, 5 Oct 2006 03:34:02 -0400 (EDT) Date: Thu, 5 Oct 2006 00:33:39 -0700 From: Bill McQuillan X-Priority: 3 (Normal) Message-ID: <1414115487.20061005003339@pobox.com> To: Usenet Subject: Re: USEPRO: Path header In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: On Wed, 2006-10-04, Charles Lindsey wrote: > [I am proposing to s/trusted identity/verified identity/ throughout this > chapter, as it seems to convey the sense better; anyone have any > problems with this?] I wonder if it might be more accurate to refer to a "verified identifier" and to s/identity/identifier/ in the subsequent text. Since what is being verified is a name rather than an agent itself, this may make it clearer that there could be aliases either known or unknown. -- Bill McQuillan Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k953NdMI027046; Wed, 4 Oct 2006 20:23:39 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k953Nd5o027045; Wed, 4 Oct 2006 20:23:39 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k953NbSe027038 for ; Wed, 4 Oct 2006 20:23:38 -0700 (MST) (envelope-from news@clerew.man.ac.uk) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster$pop3#clerew$man&ac#uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.232) id 45247ab8.f4ed.ee for ietf-usefor@imc.org; Thu, 5 Oct 2006 04:23:36 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id k953NZ5d005856 for ; Thu, 5 Oct 2006 04:23:35 +0100 (BST) Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id k953NZ1p005853 for ietf-usefor@imc.org; Thu, 5 Oct 2006 04:23:35 +0100 (BST) To: ietf-usefor@imc.org Xref: clerew local.usefor:23665 Path: clerew!chl From: "Charles Lindsey" Subject: NIGGLE: uppercase, upper case, upper-case Message-ID: X-Newsreader: NN version 6.5.2 (NOV) Date: Wed, 4 Oct 2006 21:07:13 GMT Lines: 19 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In USEFOR, I find two occurrences of "uppercase", and one each of "lower case" and "lower-case". I think we discussed this before, and agreed on "uppercase" (but seemingly the change did not propagate to the lower occurrences). In USEPRO, I am intending to use "uppercase" and "lowercase" wherever they occur. If this is agreeable, then I suggest Ken just adds these two aberrations to his niggle-list. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k953NdKN027054; Wed, 4 Oct 2006 20:23:39 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k953NdmK027053; Wed, 4 Oct 2006 20:23:39 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-3.gradwell.net (lon-mail-3.gradwell.net [193.111.201.127]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k953Nci6027039 for ; Wed, 4 Oct 2006 20:23:38 -0700 (MST) (envelope-from news@clerew.man.ac.uk) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster^pop3&clerew$man^ac^uk) by lon-mail-3.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.232) id 45247ab9.f462.11f for ietf-usefor@imc.org; Thu, 5 Oct 2006 04:23:37 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id k953NaK1005864 for ; Thu, 5 Oct 2006 04:23:36 +0100 (BST) Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id k953NaQo005861 for ietf-usefor@imc.org; Thu, 5 Oct 2006 04:23:36 +0100 (BST) To: ietf-usefor@imc.org Xref: clerew local.usefor:23666 Path: clerew!chl From: "Charles Lindsey" Subject: USEPRO: Path header Message-ID: X-Newsreader: NN version 6.5.2 (NOV) Date: Wed, 4 Oct 2006 21:23:55 GMT Lines: 348 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Since USEFOR is now on its way to IETF Last Call, I presume it is now in order to discuss USEPRO. I would like to start with the Path header, because we made a lot of changes to that in USEFOR, and USEPRO needs to catch up. I also have various other tidyings to propose, but they can wait a couple of days while I sort them out. So please let us just stick to the Path header for the moment. The following text deals with all the changes which seem to be required. There are alternatives suggested at several places which need to be discussed, and there is a special request to Richard Clayton to explain the reasons why demon still need to use the "demon", so that I can include it in the example. Share and Enjoy! 2.3. Identification of news servers [There are two alternative texts which have been proposed:] In order to record the passage of articles through the network, news servers need to identify themselves by means of a (F-3.1.5), which can appear in Path, Injection-Info and Xref header fields. Whatever is used in the Path header field SHOULD be used also in any Injection-Info header field (and it would be normal to use it in any Xref header field also). [Maybe that last sentence moves elsewhere.] NOTE: Such s may also be suitable for sending email to news server administrators (see [USEAGE]). [1st alternative] s can take the following forms (in decreasing order of preference): 1. A fully qualified domain name (FQDN) that SHOULD be resolvable in the DNS (whether via an A, AAAA or MX record or an equivalent CNAME), thus guaranteeing a unique identity. Ideally, it will also provide a means to contact the administrators by email (according to [RFC 2142], the forms "usenet@server" and "news@server" are common addresses for a news server administrator). | 2. Some other (arbitrary) name in the form of a , and | believed to be unique and registered at least with all other news servers sending articles directly to the given one. This option SHOULD NOT be used unless the earlier option is unavailable (e.g. because the server in question is not connected to the Internet), or unless it is of longstanding usage and cessation would be unduly disruptive, or unless the earlier option is provided as well. [2nd alternative] s can take the following forms (in decreasing order of preference): 1. A fully qualified domain name (FQDN) that can be resolved to an email server via an MX, A or AAAA record according to the procedures of [RFC 2821]; this guarantees that the name is unique, and makes it easy to contact the administrators if needed. 2. A fully qualified domain name (FQDN) that is guaranteed to be unique by the administrators of the domain; for instance, the uniqueness of "server.example.org" could be guaranteed by the administrator of "example.org" even if nothing is stored in the DNS for that name. | 3. Some other (arbitrary) name in the form of a , and | believed to be unique and registered at least with all other news-servers sending articles directly to the given one. This option SHOULD NOT be used unless the earlier options are unavailable, or unless the name is of longstanding usage and cessation would be unduly disruptive, or unless one of the earlier options is provided as well. According to [RFC 2142]], the forms "usenet@server" and "news@server" are common addresses for a news server administrator. [end of alternatives] | NOTE: Although domain names are case insensitive and it is | intended that s should also be so, it is customary | to render them all in lowercase, since many implementations | compare them case sensitively for reasons of efficiency. | NOTE: A news server administrator who chooses a | which turns out not to be unique (disregarding case) will have to bear the consequences. | NOTE: An IP address is not permitted as a , | although it may still appear in a . Since the | syntax permits a colon (":" which, prior to this standard, was | an alternative to the "!" delimiter) within any | which takes the form of an , it would be unwise to | choose as a anything composed solely from four or | less hexadecimal digits. 3.2. Transitional Arrangements | o The new style of Path header field, using a to allow | "!!" as a delimiter> and introducing s (which | can be distinguished from s by their leading ".") is already consistent with the previous standards. However, the intention is that relaying agents should eventually reject articles in the old style, and so this possibility should be offered as a configurable option in relaying agents. User agents are unaffected. 7. Duties of Various Agents In this section, the word "trusted", as applied to the source of some article, means that an agent processing that article has verified, by some means, the identity of that source (which may be another agent or a poster). [I am proposing to s/trusted identity/verified identity/ throughout this chapter, as it seems to convey the sense better; anyone have any problems with this?] 7.2. Duties of an Injecting Agent In the normal course of events, an article that has already been injected into a Netnews network will never pass through another injecting agent. So, if an injecting agent receives an otherwise valid article that has already been injected (as evidenced by the presence of an Injection-Date header field, an Injection-Info header | field, or more than one occurrence of the "POSTED" in a Path header field) it MAY choose to reject it, but otherwise SHOULD cause it to be relayed, as it stands, by a relaying agent (7.3). 7.2.1. Proto-articles NOTE: An article that is offered for reinjection has, by definition, already been injected once, and is not therefore to be considered as a proto-article. Hence a genuine proto-article | will not contain any Injection-Date header field nor the "POSTED" anywhere in its Path header field, though that header field MAY contain s corresponding to machines traversed between the posting agent and the injecting agent proper. 7.2.2. Procedure to be followed by Injecting Agents 10. It MUST then prepend the of the injecting agent, | followed by '!.' and the "POSTED", and then a | further "!", to the content of the Path header field; this header field SHOULD then be folded if it would otherwise result in a header line of excessive length. 7.3. Duties of a Relaying Agent In order to avoid unnecessary relaying, an article SHOULD NOT be relayed if the of the receiving agent (or some known | alias thereof) appears as a in its Path header field. | But note that the (which follows the last "!") is not a | , although not all current implementations observe | this distinction. | For this to work, each relaying agent needs to insert it own (chosen according to 2.3) into the Path header field. It | MAY insert more than one for itself (in which case | the leftmost should be the one by which it is known to its immediate | neighbours), but where an article passes through several relaying | agents at the same site it MAY omit the s for some of | them (but NOT the one which finally relays it to an outside site). | It MAY (and usually SHOULD) also add a giving | additional information concerning the route taken by the article | through the network. A consists of either the | special "!" (which effectively replaces the standard | delimiter "!" by "!!"), or it is composed from a usually | followed by a . The following are the only s defined by this standard: | o "POSTED" (already introduced in Step 10 of 7.2.2), which is never | followed by a ; | o "SEEN", whose following indicates the trusted | identity (see 7) of the agent from which the article was received | (but makes no claim as to whether it matched the indicates the trusted | identity of the agent from which the article was received and | asserts that it could not be reconciled with the | (supposedly) inserted by that agent. | Other s beginning with "X" MAY be used by a relaying | agent to make some assertion not envisaged here, but other (non-"X") | s MUST NOT be used unless defined by some extension to | this standard. | NOTE: The "MATCH", which might have indicated the | trusted identity of the source agent with an assertion that it | agreed with the inserted by that agent, has NOT | been provided, since the special conveys exactly | that meaning for this commonly occurring case. | NOTE: Whilst s are case insensitive, it is | intended that they should normally be rendered in uppercase. A relaying agent processes articles as follows: | 1. It MUST/SHOULD establish the trusted identity of the source of the article and compare it with the leftmost of | the existing Path header field's content. Except possibly when | relaying to other hosts on the same site, It then MUST or | SHOULD, as indicated, prepend to that content (from left to | right) the following: | o (MUST) its own ; | o (MUST) a "!" delimiter; | o (MUST/SHOULD) if the trusted and existing identities match, a | (effectively converting the "!" delimiter into | "!!"); | o (MUST/SHOULD) alternatively, where the identities do not | match (or have not been determied to match), a ".", the | "MISMATCH" (or "SEEN"), another ".", a indicating the trusted identity, and finally a | further "!"; | o possibly further s etc. as above, identifying | itself. | This header field SHOULD then be folded if it would otherwise | result in a header line of excessive length. [The "MUST/SHOULD"s above were all "MUST" in the previous drafts. Discussion is needed to resolve this.] | NOTE: Since each agent at one site can be assumed to be aware of | the identity of the others (and of itself), it would be most | unusual for their s to be separated other than by | "!!". Thus the presence of a single "!", unless followed by a | "." and some , can be taken as signifying an agent | that has not yet been upgraded to conform to this standard. | NOTE: Whilst the presence of a "MISMATCH" would normally | indicate that the existing Path was bogus in some sense, it | could also indicate that the ralaying agent was improperly | configured to recognise the identities or aliases used by its | neighbours. Administators of relaying agents should therefore | periodically monitor the being inserted so as | to avoid this. NOTE: In order to prevent overloading, relaying agents should not routinely query an external entity (such as a DNS-server) in order to determine a trusted identity (though a local cache of the required information might usefully be consulted). 7.3.1. Path Header Field Example | Path: bar.isp.example!.SEEN.news3.foo.isp.example!foo.isp.example | !!foo-server!.MISMATCH.2001:DB8:0:0:8:800:200C:417A | !dubious.site.example!!old.site.example!barbaz!!baz.isp.example | !.POSTED!dialup123.baz.isp.example!not-for-mail NOTE: That article was injected into the news stream by | baz.isp.example, as indicated by the "POSTED" (complaints may be addressed to abuse@baz.isp.example). The injector has chosen to record that it got it from dialup123.baz.isp.example. "not-for-mail" is a dummy , though sometimes a real userid is put there. The article was relayed, perhaps by UUCP, to the machine known, at least to old.site.example, as "barbaz". Barbaz relayed it to old.site.example, which does not yet | conform to this standard (hence the single '!' delimiter). So one cannot be sure that it really came from barbaz. | Old.site.example relayed it to a site claiming to be | dubious.site.example, and claiming (by using the '!!' | delimiter) to have verified that it came from old.site.example. | Dubious.site.example relayed it to "foo-server" which, not being | convinced that it truly came from dubious.site.example, and | knowing that it in fact arrived from a host with the IPv6address | [2001:DB8:0:0:8:800:200C:417A], inserted the | "!.MISMATCH.2001:DB8:0:0:8:800:200C:417A" (that is not to say | that [2001:DB8:0:0:8:800:200C:417A] was not a correct IPv6 | address for dubious-site.example, but simply that that | connection could not be substantiated by foo-server). "foo-server" is a locally significant name within the complex site of many machines run by foo.isp.example, so the latter should have no problem recognizing foo-server and using a '!!' | delimiter. It was not strictly necessary to insert the "foo-server" as well as "foo.isp.example" (but maybe | some site elsewhere had some reason to test for it). [Please could Richard Clayton provide a more plausible reason why "foo- server" might be a here?] | It then went to bar.isp.example which determined (by reverse | DNS) that it had come from news3.foo.isp.example, but had taken | no steps to check whether that was a known alias for | foo.isp.example (which it probably was). Strictly, it SHOULD | have made such a check, and then inserted either a "!!" or a | "!MISMATCH..." according to the result. | Presumably bar.isp.example then delivered the article to its direct clients. | It appears that foo.isp.example, foo-server and baz.isp.example decided to fold the line, on the grounds that it seemed to be | getting a little too long. Note that folding and whitespace is | permitted before (but not after) any "!" (but not within a | "!!"); hence continuation lines will always start with either | "!" or "!!". 7.4. Duties of a Serving Agent A serving agent processes articles as follows: | 1. It MUST/SHOULD establish the trusted identity of the source of the article and modify the Path header field as for a relaying agent (7.3). 7.8. Duties of a Moderator 5. Any variant header fields (2.4) MUST be removed, except that a Path header field MAY be truncated to only those entries following | its "POSTED" . Any Injection-Info header field (F- 3.2.8 SHOULD be removed (and if not, the injecting agent will do so, as required in 7.2.2). -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k94FcndI043826; Wed, 4 Oct 2006 08:38:49 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k94FcnFL043825; Wed, 4 Oct 2006 08:38:49 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k94FclQW043817 for ; Wed, 4 Oct 2006 08:38:48 -0700 (MST) (envelope-from mibsoft@mibsoftware.com) Received: (qmail 74884 invoked from network); 4 Oct 2006 15:38:46 -0000 Received: from unknown (HELO ?192.168.2.11?) (unknown) by unknown with SMTP; 4 Oct 2006 15:38:46 -0000 X-pair-Authenticated: 208.111.196.23 Message-ID: <4523D57F.5060509@mibsoftware.com> Date: Wed, 04 Oct 2006 11:38:39 -0400 From: "Forrest J. Cavalier III" User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ietf-usefor@imc.org Subject: Re: USEFOR last call, point of order References: <4521664A.8030902@mibsoftware.com> <01M7W391VPW20008CX@mauve.mrochek.com> <4521DC94.9020705@mibsoftware.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Charles Lindsey wrote: > In <4521DC94.9020705@mibsoftware.com> "Forrest J. Cavalier III" writes: > > >>I really appreciate your detailed response. > > >>>My suggestion, however, is that the better course of action given that the last >>>call has begun is to comment on technical issues in the document itself rather >>>than the process that has gotten us to this point. > > >>1. It is my opinion that most of the technical issues in USEFOR are going to >>remain hidden until the discussions start on USEPRO, and implementations start >>to be written. Raising a significant formal objection now is going to be pretty >>difficult, since USEFOR is a document format, not a protocol. Risk of harm only >>arises through activity, not format specifications alone. > > > Then your proper course of action is to recommend to the IESG that they > decline to publish it until they see USEPRO (that is also my own view, but > I accept that the consensus was against me). > > But you have given no cogent reason for absolute rejection of the > document. > It was the third way I was searching for. Discuss the process. Discuss how USEFOR came to be submitted for last call, and if that was proper. Discuss how soon the clean up to USEFOR (that USEPRO will cause) will happen. I agree that "Perfect draft" is unreasonable. But there is a continuum of imperfection. We have a disagreement in the WG about how ready the document is. That disagreement was NOT apparent or highlighted by the submission from Alexey. The IESG gives no more weight to the USEPRO editor's view than others, which is weird, considering how USEFOR came to be a piece split off from a larger work, and the significant interdependencies between them. If USEFOR were a strict documentation of existing practice, my opinion would be different. So, Charles is correct that I have given no reason for absolute rejection of the document. I don't think it should be absolutely rejected. I agree it is an improvement over those parts of previous standards. And that is what the IESG is looking for: some improvement. That's a pretty low bar. If "minimal improvement over 1036" was the bar of acceptance, then we could have submitted long, long, long ago. We could have used Son-Of-1036. But that was NOT the charter. If that is the bar, then no Format standard that proposes new features can be appealed. Is that what the IESG rules intend? If one were to try to appeal to the IESG to reject USEFOR now, most likely it would be based on something that USEPRO draft says now. (As I said, activities create risk, not mere format specifications.) But an appeal on that basis would be dismissed by saying "Well, USEPRO is just a draft, we can fix it in USEPRO." Saying that it is fixable in USEPRO is pure hubris, (some format flaws cannot be overcome by protocol.) Saying that USEPRO will be fixed in any particular time frame is not supported by the track record of this WG. Isn't there a third way? Apparently not. I predict the end result of all this will be is a confusing set of conflicting or incomplete standards issued from a single WG, and no one left interested in cleaning it up. The people who can act to prevent that are the chair and the AD. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k94BC8Ks088607; Wed, 4 Oct 2006 04:12:08 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k94BC8fk088606; Wed, 4 Oct 2006 04:12:08 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from lon-mail-4.gradwell.net (lon-mail-4.gradwell.net [193.111.201.130]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k94BC5c7088586 for ; Wed, 4 Oct 2006 04:12:07 -0700 (MST) (envelope-from news@clerew.man.ac.uk) Received: from [80.175.135.89] ([80.175.135.89] helo=clerew.man.ac.uk country=GB ident=postmaster&pop3*clerew&man*ac#uk) by lon-mail-4.gradwell.net with esmtpa (Gradwell gwh-smtpd 1.231) id 45239704.4954.34bf for ietf-usefor@imc.org; Wed, 4 Oct 2006 12:12:04 +0100 (envelope-sender ) Received: from clerew.man.ac.uk (localhost [127.0.0.1]) by clerew.man.ac.uk (8.13.7/8.13.7) with ESMTP id k94BC2Lo022910 for ; Wed, 4 Oct 2006 12:12:03 +0100 (BST) Received: (from news@localhost) by clerew.man.ac.uk (8.13.7/8.13.7/Submit) id k94BC2Rx022906 for ietf-usefor@imc.org; Wed, 4 Oct 2006 12:12:02 +0100 (BST) To: ietf-usefor@imc.org Xref: clerew local.usefor:23663 Path: clerew!chl From: "Charles Lindsey" Subject: Re: USEFOR last call, point of order Message-ID: X-Newsreader: NN version 6.5.2 (NOV) References: <4521664A.8030902@mibsoftware.com> <01M7W391VPW20008CX@mauve.mrochek.com> <4521DC94.9020705@mibsoftware.com> Date: Wed, 4 Oct 2006 10:40:29 GMT Lines: 31 Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: In <4521DC94.9020705@mibsoftware.com> "Forrest J. Cavalier III" writes: >I really appreciate your detailed response. >> My suggestion, however, is that the better course of action given that the last >> call has begun is to comment on technical issues in the document itself rather >> than the process that has gotten us to this point. >1. It is my opinion that most of the technical issues in USEFOR are going to >remain hidden until the discussions start on USEPRO, and implementations start >to be written. Raising a significant formal objection now is going to be pretty >difficult, since USEFOR is a document format, not a protocol. Risk of harm only >arises through activity, not format specifications alone. Then your proper course of action is to recommend to the IESG that they decline to publish it until they see USEPRO (that is also my own view, but I accept that the consensus was against me). But you have given no cogent reason for absolute rejection of the document. -- Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clerew.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5 Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k93GHFi2047306; Tue, 3 Oct 2006 09:17:15 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k93GHFKa047305; Tue, 3 Oct 2006 09:17:15 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from laweleka.osafoundation.org (laweleka.osafoundation.org [204.152.186.98]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k93GHDEu047296 for ; Tue, 3 Oct 2006 09:17:14 -0700 (MST) (envelope-from lisa@osafoundation.org) Received: from localhost (localhost [127.0.0.1]) by laweleka.osafoundation.org (Postfix) with ESMTP id 685B014228C; Tue, 3 Oct 2006 09:17:13 -0700 (PDT) Received: from laweleka.osafoundation.org ([127.0.0.1]) by localhost (laweleka.osafoundation.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24844-04; Tue, 3 Oct 2006 09:17:12 -0700 (PDT) Received: from [192.168.1.101] (c-69-181-78-47.hsd1.ca.comcast.net [69.181.78.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by laweleka.osafoundation.org (Postfix) with ESMTP id 86BDF142287; Tue, 3 Oct 2006 09:17:12 -0700 (PDT) In-Reply-To: <20061002194113.4CD552BF403@message-id.pfm-mainz.de> References: <20061002194113.4CD552BF403@message-id.pfm-mainz.de> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: multipart/alternative; boundary=Apple-Mail-31--951080653 Message-Id: Cc: ietf-usefor@imc.org From: Lisa Dusseault Subject: Re: USEFOR last call, point of order Date: Tue, 3 Oct 2006 09:17:09 -0700 To: Ralph Babel X-Mailer: Apple Mail (2.752.2) X-Virus-Scanned: by amavisd-new and clamav at osafoundation.org Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: --Apple-Mail-31--951080653 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Thanks for your input on the suitability of this draft for publication -- IETF last call is a fine time for this input, as Ned explained. However, note that at this point I'm most interested in seeing justified arguments that the document in last-call now is *worse* than what it is replacing. If the usefor-usefor draft is a higher-quality document, even if it's not perfect, the low WG size/ energy suggests to me that it should replace the older document rather than continue getting slowly and contentiously polished. By the way, I found this to be a well-written doc when I did my own read last week. Without being a netnews implementor I can't necessarily find all inconsistencies but I did find the text generally clear and well-organized. I have thought about some of the reported unaddressed inconsistencies brought up on this list, and did not identify any as being big/bad enough to adversely affect interoperability. I have been reading everything that goes by on the list (though I haven't consulted the tracking system) since March of this year. The publication of a new Proposed Standard document on the Netnews article format should not be considered the last word ever on the topic. If somebody found the energy to revise the document further some day, and found support for that work, it could happen. Improving a standard is generally possible; perfecting it is not. Lisa On Oct 2, 2006, at 12:41 PM, Ralph Babel wrote: > > Forrest J. Cavalier III wrote: > >> But the chair should be impartial when complying with >> release procedures. Good executive decisions at the >> level of the IESG can only be made based on accurate >> assessments, and "spin" is not acceptable. > > Just for the record: I'm with Forrest. > > Too many contributors have left the WG; nonetheless, the > number of reported inconsistencies in the draft remains > constant. This "last call" looks more like the chair being > tired of the lack of progress (and the draft _is_ far from > acceptable), but not feeling like shutting down the WG as > announced originally as part of the milestone schedule. > --Apple-Mail-31--951080653 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1

Thanks for your input on the suitability of this draft = for publication -- IETF last call is a fine time for this input, as Ned = explained.=A0 However, note that at this point I'm most interested in = seeing justified arguments that the document in last-call now is *worse* = than what it is replacing.=A0 If the usefor-usefor draft is a = higher-quality document, even if it's not perfect, the low WG = size/energy suggests to me that it should replace the older document = rather than continue getting slowly and contentiously = polished.=A0=A0

By = the way, I found this to be a well-written doc when I did my own read = last week. Without being a netnews implementor I can't necessarily find = all inconsistencies but I did find the text generally clear and = well-organized.=A0 I have thought about some of the reported unaddressed = inconsistencies brought up on this list, and did not identify any as = being big/bad enough to adversely affect interoperability.=A0 I have = been reading everything that goes by on the list (though I haven't = consulted the tracking system) since March of this = year.

The= publication of a new Proposed Standard document on the Netnews article = format should not be considered the last word ever on the topic.=A0 If = somebody found the energy to revise the document further some day, and = found support for that work, it could happen.=A0 Improving a standard is = generally possible; perfecting it is not.

Lisa

On Oct 2, 2006, at 12:41 PM, = Ralph Babel wrote:


Forrest = J. Cavalier III wrote:
But the chair = should be impartial when complying with
release = procedures. Good executive decisions at the
level = of the IESG can only be made based on accurate
assessments, and "spin" is not acceptable.
=

Just for the record: I'm with Forrest.

Too many = contributors have left the WG; nonetheless, the
number of reported inconsistencies in the draft = remains
constant. This "last call" looks = more like the chair being
tired of the = lack of progress (and the draft _is_ far from
acceptable), but not feeling like shutting down the = WG as
announced originally as part of = the milestone schedule.


= --Apple-Mail-31--951080653-- Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k934NCoX030823; Mon, 2 Oct 2006 21:23:12 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k934NCwR030822; Mon, 2 Oct 2006 21:23:12 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from smtp1.stanford.edu (smtp1.Stanford.EDU [171.67.22.28]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k934NBKt030816 for ; Mon, 2 Oct 2006 21:23:11 -0700 (MST) (envelope-from rra@stanford.edu) Received: from smtp1.stanford.edu (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id EE9F44C63A for ; Mon, 2 Oct 2006 21:23:10 -0700 (PDT) Received: from windlord.stanford.edu (windlord.Stanford.EDU [171.64.19.147]) by smtp1.stanford.edu (Postfix) with ESMTP id D71EA4C46D for ; Mon, 2 Oct 2006 21:23:10 -0700 (PDT) Received: by windlord.stanford.edu (Postfix, from userid 1000) id D1550E78DD; Mon, 2 Oct 2006 21:23:10 -0700 (PDT) From: Russ Allbery To: Usefor Mailing List Subject: Re: USEFOR last call, point of order In-Reply-To: <4521DC94.9020705@mibsoftware.com> (Forrest J. Cavalier, III's message of "Mon, 02 Oct 2006 23:44:20 -0400") Organization: The Eyrie References: <4521664A.8030902@mibsoftware.com> <01M7W391VPW20008CX@mauve.mrochek.com> <4521DC94.9020705@mibsoftware.com> Date: Mon, 02 Oct 2006 21:23:10 -0700 Message-ID: <87ac4eauz5.fsf@windlord.stanford.edu> User-Agent: Gnus/5.110006 (No Gnus v0.6) XEmacs/21.4.19 (linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Forrest J Cavalier writes: > 4. It seems process is not a grounds for appeal, and a discussion about > process is off-topic. If everyone thinks this WG is working well, then > carry on. The rest of the software development world has discovered > that process explains results. I don't think the WG is working well. I do, however, think that the current USEFOR draft is superior to RFC 1036 as guidance for implementors on Usenet today, and I think it's silly to have a superior document be left in semi-permanent limbo the way that Son-of was. So when weighing the decision of whether to publish or not publish USEFOR, separate from the questions of whether or not we're likely to accomplish all of our goals, it seems to me that it's better for the general community to publish it. As for continued work, well, I'm willing to keep working provided that people are still reviewing and we seem to be converging on something useful. I think we mostly did that with USEFOR. Whether we can do that with USEPRO is very iffy, but we haven't really tried yet, and I don't want to give up without even trying. It's worth pointing out that the NNTP working group also went on for many years past its deadlines and only finally made progress when the WG was down to about five active members, and yet I'm extremely pleased with the documents we produced and which are about to become RFCs. -- Russ Allbery (rra@stanford.edu) Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k933iIeI019243; Mon, 2 Oct 2006 20:44:18 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k933iHXW019242; Mon, 2 Oct 2006 20:44:17 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k933iGNa019236 for ; Mon, 2 Oct 2006 20:44:16 -0700 (MST) (envelope-from mibsoft@mibsoftware.com) Received: (qmail 45097 invoked from network); 3 Oct 2006 03:44:15 -0000 Received: from unknown (HELO ?192.168.2.11?) (unknown) by unknown with SMTP; 3 Oct 2006 03:44:15 -0000 X-pair-Authenticated: 216.37.223.2 Message-ID: <4521DC94.9020705@mibsoftware.com> Date: Mon, 02 Oct 2006 23:44:20 -0400 From: "Forrest J. Cavalier III" User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Usefor Mailing List CC: Ned Freed , Forrest J Cavalier III , Harald Tveit Alvestrand Subject: Re: USEFOR last call, point of order References: <4521664A.8030902@mibsoftware.com> <01M7W391VPW20008CX@mauve.mrochek.com> In-Reply-To: <01M7W391VPW20008CX@mauve.mrochek.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: I really appreciate your detailed response. > My suggestion, however, is that the better course of action given that the last > call has begun is to comment on technical issues in the document itself rather > than the process that has gotten us to this point. 1. It is my opinion that most of the technical issues in USEFOR are going to remain hidden until the discussions start on USEPRO, and implementations start to be written. Raising a significant formal objection now is going to be pretty difficult, since USEFOR is a document format, not a protocol. Risk of harm only arises through activity, not format specifications alone. 2. If this were the last and final WG document out the door, rather than the simplest and least contentious of 3 proposed documents, then I would agree that process discussions would be pointless: everything would be done. But we have 90% of the work left to do. 3. It seems that missing a milestone by a year or many years is not rare in WGs. But missing this prediction by a year, something like 5 times as many months as Harald first predicted, and then predicting that the next and more complicated work product will be complete in a year using the same process does not inspire confidence and trust. 4. It seems process is not a grounds for appeal, and a discussion about process is off-topic. If everyone thinks this WG is working well, then carry on. The rest of the software development world has discovered that process explains results. Thank you again, Ned and Harald, for replying. Forrest Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9308gba078533; Mon, 2 Oct 2006 17:08:42 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k9308gSF078532; Mon, 2 Oct 2006 17:08:42 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from shell.peak.org (shell.peak.org [69.59.192.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k9308flC078525 for ; Mon, 2 Oct 2006 17:08:42 -0700 (MST) (envelope-from stanley@peak.org) Received: from shell.peak.org (shell.peak.org [127.0.0.1]) by shell.peak.org (8.13.1/8.13.1) with ESMTP id k9308dLa025169 for ; Mon, 2 Oct 2006 17:08:39 -0700 Received: from localhost (stanley@localhost) by shell.peak.org (8.13.1/8.13.1/Submit) with ESMTP id k9308TDM025166 for ; Mon, 2 Oct 2006 17:08:39 -0700 X-Authentication-Warning: shell.peak.org: stanley owned process doing -bs Date: Mon, 2 Oct 2006 17:08:29 -0700 (PDT) From: stanley@peak.org To: ietf-usefor@imc.org Subject: Re: USEFOR last call, point of order Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Forrest J. Cavalier III wrote: >I think your submission to the IESG requesting last call >was biased. Can you explain? I felt the same when I read it. It is interesting to see in writing that nobody who dished personal insults my way got censured, despite my being told otherwise while it was happening. Harald Alvestrand : >If the group is closed, the biggest contributing factor I see for making >such a decision is lack of interest. Why do you assume that it has to be >caused by lack of interest? You are the one assuming a lack of interest. People do not always leave this group because they lack interest in the outcome. I'd say that one very good reason is when they've seen a draft that they've worked very hard to get to say one thing go away because the editor decided he didn't like what it said. >Nobody's threatened to appeal in any message I've seen on the list. I recall having seen several such messages appear in the list in the past. I don't recall whether I said it explicitely myself, but I know I made my position clear about the process of discussing changes outside the list on a web system that cannot be accessed by anyone who refuses to accept bogus SSL certs. I also recall at least one and perhaps more people saying "it doesn't matter anymore, I'll just appeal it when it gets to IETF." Expecting them to stay around for half a decade just to say it again during this last-last-last-last call is silly. Of course, you just might not have seen them. I think a statement such as "nobody has threatened to appeal" implies that you actually looked to see if they had. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k93035j5077999; Mon, 2 Oct 2006 17:03:05 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k93035fs077998; Mon, 2 Oct 2006 17:03:05 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from mauve.mrochek.com (206.117.180.234.brandx.net [206.117.180.234] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k93033PQ077990 for ; Mon, 2 Oct 2006 17:03:03 -0700 (MST) (envelope-from ned.freed@mrochek.com) Received: from dkim-sign.mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M7W392M1DS00Q3T9@mauve.mrochek.com> for ietf-usefor@imc.org; Mon, 2 Oct 2006 17:02:59 -0700 (PDT) Received: from mauve.mrochek.com by mauve.mrochek.com (PMDF V6.1-1 #35243) id <01M7VSOQGXJ40008CX@mauve.mrochek.com>; Mon, 02 Oct 2006 17:02:58 -0700 (PDT) Cc: Harald Tveit Alvestrand , Usefor Mailing List To: Forrest J Cavalier III Message-id: <01M7W391VPW20008CX@mauve.mrochek.com> Date: Mon, 02 Oct 2006 15:54:17 -0700 (PDT) From: Ned Freed Subject: Re: USEFOR last call, point of order In-reply-to: "Your message dated Mon, 02 Oct 2006 15:19:38 -0400" <4521664A.8030902@mibsoftware.com> MIME-version: 1.0 Content-type: TEXT/PLAIN; format=flowed References: <4521664A.8030902@mibsoftware.com> Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: > I expect a chair to be somewhat of a cheerleader and > have an interest in moving things forward. > But the chair should be impartial when complying with > release procedures. Good executive decisions at the level > of the IESG can only be made based on accurate assessments, > and "spin" is not acceptable. > I think your submission to the IESG requesting last call > was biased. Can you explain? I would suggest you familiarize yourself with IETF processes a bit more before making comments of this sort. Just as one point, the last call process is started by the relevant area director (in this case Lisa Dusseault), not by the WG chair. The fact that the process has begun means the relevant area director is comfortable that the necessary procedures have been followed. This doesn't mean the document is ready to become an RFC. That's what the last call is for: To determine whether or not it is ready. > 1. I disagree with the idea that it should be published in the event the > WG closes. If a WG closes, it is because procedures were not > being followed. I'm actually having a hard time coming up with a case where a WG was shut down due to procedures not being followed. Since the chair is responsible for procedural issues the usual remedy in such cases is to replace the chair. The usual reason for shutting down WGs is when they are completely out in the weeds or there's clearly no chance of the group reaching closure. It is also worth noting that approval of a WG changes document handling somewhat but has never been a publication requirement in the IETF. There have been plenty of cases where a WG failed but some of the WG products made it to some form of RFC. There have also been a huge number of cases where non-WG documents became RFCs. > Why is it reasonable to assume work products that > resulted from a flawed process should be accepted? But why would it be unreasonable? Given that the members of WGs are human, there are almost always minor process flaws if you look hard enough. Specifications should succeed or fail on their own merits. Of course there are some sorts of egregious process failures that would merit an objection during last call or even an appeal, but failures to dot i's or cross t's do not rise to this level. IMO nothing you have pointed out rises to the necessary level. In any case, while procedural issues are in order, you are far more likely to get traction by making cogent technical arguments at this point. > I would think an explicit justification should be presented. I know of no basis for calling for such a thing. > 2. There have to be interoperating implementations before it can be > standardized, and it should be clearer that there aren't even experimental > implementations for some of it. I'm sorry, but this is simply not the case. Interoperability requirements apply to the move from proposed to draft, not the move to proposed. (There are some exceptions to this for things like routing protocols but none that apply here.) > I am not sure that even bare requirements > for submitting for last call are met here. That was not clear in your > submission. The bare requirements for last call are just that: Pretty bare. > 3. I think the "nobody threatened to appeal" is a hope, not a statement > of the risk that someone appeals. You never asked in the group. Did you > ask anyone else? Especially when so many good reviewers left the group? And the main reason why we have an IETF-wide last call is so the document can receive wider review. I find it more than a little curious that you would object to an action whose main goal is wider review by claiming that the capacity for good review no longer exists in the group. If anything this is an argument for a last call, not against one. > 4. You claimed "rough consensus." Is there a reason that the actual poll > results 6/10 were not made clear? There is a 2/7 reject/reviewer ratio > discernable in the last paragraph, but not stated as a ratio. Are > IESG executives aware of the controversies and opinions? Are they aware > there are so few participants in the poll and that the chairs and editors > were part of those counted? Only the AD can answer this, but having been an AD myself I'd be enormously surprised if she isn't aware in detail of what has gone on. > 5. I think the IESG should be made aware that the USEPRO editor is > on record as saying that USEFOR is not ready until USEPRO is, and > that USEPRO is not close. The IESG should be aware of your previous > predictions of schedule and milestones. (See my previous e-mail.) > And what that means for a range of when USEPRO can be expected to be > completed, and with how many participants. WGs that are way past their milestone dates are never in short supply in the IETF. Just picking another group at random, I note that all open OPENPGP milestones have dates in 2001. I recall noting one group some time back that was almost seven years past any of their dates. In any case, if all WGs that have missed milestones were shut down there wouldn't be very many groups left. Harald is actually more of a stickler for milestones and whatnot than most, so I'm a bit surprised USEFOR dates have not been updated. I personally think the utility of these tools in a volunteer organization like the IETF is marginal at best. > I am not that involved with the IETF standards process, so I don't > know which of the above warrant comment to higher levels. Unless things have changed dramatically since my time on the IESG the relevant AD reads this list, so your comments have probably been seen. Nevertheless, you can and should send comments directly to the ADs, the IESG, or to the main IETF list. My suggestion, however, is that the better course of action given that the last call has begun is to comment on technical issues in the document itself rather than the process that has gotten us to this point. Ned Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k92Jfelp037112; Mon, 2 Oct 2006 12:41:40 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k92Jfeq1037111; Mon, 2 Oct 2006 12:41:40 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from phobos.pfm-mainz.de (phobos.pfm-mainz.de [145.253.109.94]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k92Jfd6f037095 for ; Mon, 2 Oct 2006 12:41:39 -0700 (MST) (envelope-from rbabel@babylon.pfm-mainz.de) Received: from babylon.pfm-mainz.de (localhost [127.0.0.1]) by phobos.pfm-mainz.de (Postfix) with ESMTP id 7F5641BC01 for ; Mon, 2 Oct 2006 21:41:37 +0200 (CEST) Received: by message-id.pfm-mainz.de (Postfix, from userid 1000) id 4CD552BF403; Mon, 2 Oct 2006 21:41:13 +0200 (CEST) In-Reply-To: <4521664A.8030902@mibsoftware.com> From: rbabel@babylon.pfm-mainz.de (Ralph Babel) To: ietf-usefor@imc.org Subject: Re: USEFOR last call, point of order Message-Id: <20061002194113.4CD552BF403@message-id.pfm-mainz.de> Date: Mon, 2 Oct 2006 21:41:13 +0200 (CEST) Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Forrest J. Cavalier III wrote: > But the chair should be impartial when complying with > release procedures. Good executive decisions at the > level of the IESG can only be made based on accurate > assessments, and "spin" is not acceptable. Just for the record: I'm with Forrest. Too many contributors have left the WG; nonetheless, the number of reported inconsistencies in the draft remains constant. This "last call" looks more like the chair being tired of the lack of progress (and the draft _is_ far from acceptable), but not feeling like shutting down the WG as announced originally as part of the milestone schedule. Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k92JaTg8036661; Mon, 2 Oct 2006 12:36:29 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k92JaT3s036660; Mon, 2 Oct 2006 12:36:29 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k92JaQlF036650 for ; Mon, 2 Oct 2006 12:36:29 -0700 (MST) (envelope-from harald@alvestrand.no) Received: from localhost (eikenes.alvestrand.no [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id EB9172596ED; Mon, 2 Oct 2006 21:33:59 +0200 (CEST) Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22497-03; Mon, 2 Oct 2006 21:33:54 +0200 (CEST) Received: from [192.168.1.57] (162.80-203-220.nextgentel.com [80.203.220.162]) by eikenes.alvestrand.no (Postfix) with ESMTP id D85242596BC; Mon, 2 Oct 2006 21:33:53 +0200 (CEST) Message-ID: <45216A31.8070903@alvestrand.no> Date: Mon, 02 Oct 2006 21:36:17 +0200 From: Harald Alvestrand User-Agent: Thunderbird 1.5.0.7 (Windows/20060909) MIME-Version: 1.0 To: "Forrest J. Cavalier III" Cc: Usefor Mailing List Subject: Re: USEFOR last call, point of order References: <4521664A.8030902@mibsoftware.com> In-Reply-To: <4521664A.8030902@mibsoftware.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at alvestrand.no Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Forrest J. Cavalier III wrote: > Harald, > > I expect a chair to be somewhat of a cheerleader and > have an interest in moving things forward. > > But the chair should be impartial when complying with > release procedures. Good executive decisions at the level > of the IESG can only be made based on accurate assessments, > and "spin" is not acceptable. > > I think your submission to the IESG requesting last call > was biased. Can you explain? > > 1. I disagree with the idea that it should be published in the event the > WG closes. If a WG closes, it is because procedures were not > being followed. Why is it reasonable to assume work products that > resulted from a flawed process should be accepted? I would think an > explicit justification should be presented. If the group is closed, the biggest contributing factor I see for making such a decision is lack of interest. Why do you assume that it has to be caused by lack of interest? > > 2. There have to be interoperating implementations before it can be > standardized, and it should be clearer that there aren't even > experimental implementations for some of it. I am not sure that even > bare requirements > for submitting for last call are met here. That was not clear in your > submission. There has to be interoperating implementations before it can be advanced to Draft Standard. This call is for Proposed Standard. Your interpretation of the IETF standards track is erroneous. > > 3. I think the "nobody threatened to appeal" is a hope, not a statement > of the risk that someone appeals. You never asked in the group. Did you > ask anyone else? Especially when so many good reviewers left the group? Nobody's threatened to appeal in any message I've seen on the list. I trust that people who want to appeal are capable of making their own threats. > > 4. You claimed "rough consensus." Is there a reason that the actual > poll results 6/10 were not made clear? There is a 2/7 > reject/reviewer ratio discernable in the last paragraph, but not > stated as a ratio. Are > IESG executives aware of the controversies and opinions? Are they aware > there are so few participants in the poll and that the chairs and editors > were part of those counted? The writeup should make it quite clear that there are very few people left in the group. I do not agree that 6/10 is a correct counting. > > 5. I think the IESG should be made aware that the USEPRO editor is > on record as saying that USEFOR is not ready until USEPRO is, and > that USEPRO is not close. The IESG should be aware of your previous > predictions of schedule and milestones. (See my previous e-mail.) > And what that means for a range of when USEPRO can be expected to be > completed, and with how many participants. The IESG is quite capable of noticing that the group's spent nine years without producing anything, and that I've taken at least one year longer than I first expected to get the first document out the door. That's a cause for pessimism for the next document, and the ADs are aware of this. WRT the USEFOR/USEPRO linkage, the group consensus was not to hold it back; the IETF rules give no special weight to the opinion of an editor of another document. > > I am not that involved with the IETF standards process, so I don't > know which of the above warrant comment to higher levels. In my opinion: None. Your mileage may vary; the IETF process allows anyone to state any opinion to anyone. Harald Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k92JJaSu032629; Mon, 2 Oct 2006 12:19:36 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id k92JJa4Z032628; Mon, 2 Oct 2006 12:19:36 -0700 (MST) (envelope-from owner-ietf-usefor@mail.imc.org) X-Authentication-Warning: balder-227.proper.com: majordom set sender to owner-ietf-usefor@mail.imc.org using -f Received: from relay00.pair.com (relay00.pair.com [209.68.5.9]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id k92JJYuw032620 for ; Mon, 2 Oct 2006 12:19:35 -0700 (MST) (envelope-from mibsoft@mibsoftware.com) Received: (qmail 10053 invoked from network); 2 Oct 2006 19:19:33 -0000 Received: from unknown (HELO ?192.168.2.11?) (unknown) by unknown with SMTP; 2 Oct 2006 19:19:33 -0000 X-pair-Authenticated: 216.37.223.2 Message-ID: <4521664A.8030902@mibsoftware.com> Date: Mon, 02 Oct 2006 15:19:38 -0400 From: "Forrest J. Cavalier III" User-Agent: Mozilla Thunderbird 0.7 (Windows/20040616) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Harald Tveit Alvestrand CC: Usefor Mailing List Subject: USEFOR last call, point of order Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ietf-usefor@mail.imc.org Precedence: bulk List-Archive: List-Unsubscribe: List-ID: Harald, I expect a chair to be somewhat of a cheerleader and have an interest in moving things forward. But the chair should be impartial when complying with release procedures. Good executive decisions at the level of the IESG can only be made based on accurate assessments, and "spin" is not acceptable. I think your submission to the IESG requesting last call was biased. Can you explain? 1. I disagree with the idea that it should be published in the event the WG closes. If a WG closes, it is because procedures were not being followed. Why is it reasonable to assume work products that resulted from a flawed process should be accepted? I would think an explicit justification should be presented. 2. There have to be interoperating implementations before it can be standardized, and it should be clearer that there aren't even experimental implementations for some of it. I am not sure that even bare requirements for submitting for last call are met here. That was not clear in your submission. 3. I think the "nobody threatened to appeal" is a hope, not a statement of the risk that someone appeals. You never asked in the group. Did you ask anyone else? Especially when so many good reviewers left the group? 4. You claimed "rough consensus." Is there a reason that the actual poll results 6/10 were not made clear? There is a 2/7 reject/reviewer ratio discernable in the last paragraph, but not stated as a ratio. Are IESG executives aware of the controversies and opinions? Are they aware there are so few participants in the poll and that the chairs and editors were part of those counted? 5. I think the IESG should be made aware that the USEPRO editor is on record as saying that USEFOR is not ready until USEPRO is, and that USEPRO is not close. The IESG should be aware of your previous predictions of schedule and milestones. (See my previous e-mail.) And what that means for a range of when USEPRO can be expected to be completed, and with how many participants. I am not that involved with the IETF standards process, so I don't know which of the above warrant comment to higher levels. Thank you. Forrest