From problem-statement-bounces@alvestrand.no Sun Aug 3 09:34:38 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17202 for ; Sun, 3 Aug 2003 09:34:38 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 5363F61BD6; Sun, 3 Aug 2003 15:34:10 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id 28CA861BB1 for ; Sun, 3 Aug 2003 15:34:09 +0200 (CEST) Received: from bs.jck.com ([209.187.148.211] helo=localhost) by bs.jck.com with esmtp (Exim 4.10) id 19jIzt-000AXA-00 for problem-statement@alvestrand.no; Sun, 03 Aug 2003 08:34:07 -0500 Date: Sun, 03 Aug 2003 09:30:49 -0400 From: John C Klensin To: problem-statement@alvestrand.no Message-ID: <2631621.1059903049@localhost> X-Mailer: Mulberry/3.0.3 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: New Issue: Distinguishing IETF docs from others X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit The transaction below appeared last week on the IPR list. Since no one else has said anything, and in the interest of avoiding the notion dropping through the cracks... It is often difficult to distinguish, by reading the document, whether an informational or experimental RFC is an individual contribution or a document that has received some level of IETF approval. That is confusing to readers, may be confusing in consideration about standards vis a vis which documents are authoritative and which are not, and may be an enabler of abuse. The RFC Editor should be encouraged to develop a way to make this distinction with different headers (e.g., individual contribution are not identified with "network working group") or different introductory boilerplate, or by some other mechanism. john ---------- Forwarded Message ---------- Date: Thursday, July 31, 2003 23:26 -0400 From: Scott Bradner To: ipr-wg@ietf.org Subject: -technology (actually thi stime) - ipr disclosure for rfc ed docs thomas sez: > Note: We currently have no way of looking at an RFC and knowing > whether it is the result of an IETF activity or not. But the > current set of documents makes it clear that IPR disclosures > apply to "IETF documents". It is less clear they apply to "RFC > Editor Contributions". I.e., RFC Editor Contributions must > first be submitted as IDs (at which point IPR must be > disclosed), but once the RFC is published, there appears to be > no such requirement anymore. Seems like this leaves things > underspecified. Two practical points: > > 1) Is someone who gets an RFC published via the RFC Editor > Contribution route obligated to update the IETF (or anyone) > about IPR once their document is a published RFC? (AFAIK, > this is not clearly specified). > > 2) If known IPR is not required to be disclosed for RFCs in > category 1, but is for IETF-produced RFCs, it seems like we > may need a way to identify which RFCs are IETF documents > and which are not. How is this intended to be done? (E.g., > maybe all future IETF RFCs should have a line along the > lines "this document was produced by the IETF Foo Bar WG".) I agree that this is the case (the reader does not know) and maybe something should be added to the headers of IETF RFCs to indicate that they are IETF-generated not just for IPR disclosure reasons (because I would expect that the RFC Editor rules will say that such disclosure is required) but to reduce confusion as to what is an IETF document and what is someone's pipe dream but that is not something we can do in this WG since the charter limits us to clarifing the current rules not making new ones. Scott _______________________________________________ Ipr-wg mailing list Ipr-wg@ietf.org https://www1.ietf.org/mailman/listinfo/ipr-wg ---------- End Forwarded Message ---------- From problem-statement-bounces@alvestrand.no Tue Aug 5 22:14:57 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA06706 for ; Tue, 5 Aug 2003 22:14:56 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D23C661C12; Wed, 6 Aug 2003 04:14:28 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mtiwmhc12.worldnet.att.net (mtiwmhc12.worldnet.att.net [204.127.131.116]) by eikenes.alvestrand.no (Postfix) with ESMTP id E287061BE9 for ; Wed, 6 Aug 2003 04:14:26 +0200 (CEST) Received: from tsg1 (199.sanjose-03-04rs16rt.ca.dial-access.att.net[12.81.1.199]) by mtiwmhc12.worldnet.att.net (mtiwmhc12) with SMTP id <2003080602142111200rsa0je>; Wed, 6 Aug 2003 02:14:24 +0000 Message-ID: <00af01c35bc0$6f745810$020aff0a@tsg1> From: "todd glassey" To: , , Date: Tue, 5 Aug 2003 19:13:47 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Cc: degarmo5@earthlink.net, "Contreras, Jorge" Subject: Official notice of appeal on suspension rights. X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit Be advised that this is an official submission of an appeal on the suspension of my posting rights as per Harald Alverstrand, Chair of the IETF. I want to get this matter expedited so we can either reconcile this or take it into an open court. Harald's commentary regarding my posting is ridiculous. With regard to my posting 20% of the list's traffic, the 2418 clause that calls this a Denial of Service Attack is in fact a smoke screen to allow the IETF to set limits on how many postings any one person can make, but only in arbitrary matters, clearly causing a tortuous interference with my participation since issues are being resolved that I cannot participate in. And unless the IESG or the IETF is going to formally place a specific limit on the number of responses that one can submit to postings, then this matter is clearly an act of prejudicial harassment of the IETF Chair and the WG Chairs to suppress that the IPR group is essentially not in my opinion fixing problems but rather making the process and the disclosure issues more painful. Further, the Chair commented that I had "Threatened legal action" against several list members, and I would like to see specific evidence to this "fact" as it was used, since I clearly deny that this is true. Please produce the specific commentary and explain how it was threatening. What I have asked several officers of the IETF and the IESG is whether there is financial coverage for them in operating the organization as any good entity would have. They have refused to answer this in any way. I have also voiced an opinion that the IETF's policies are bringing it head-on into areas where legal action will not be avoidable but I have not said specifically that I would sue anyone. I don't make silly threats, I act upon the causative actions in appropriate manners only. Finally the commentary that "I have been warned" repeatedly by the WG Chairs to not post off topic mailings is ridiculous and contrary to the IETF's charter and operating process, and it must formally take notice of this or face the problems that this refusal to accept the obvious brings. By their very nature, the IETF WG' Lists MUST accept all postings or it is impossible to disclose new ideas on the list, making the process of submitting an I-D ***the only way that new ideas can be submitted*** or can be vetted and for WG Chairs to suppress is contrary to the IETF's operational models (no matter how hokey they are) as defined in RFC2026, RFC2223, and RFC2418. Please be advised, that I will continue to escalate this matter until resolution is forthcoming, and yes Jorge, the other person on the cc line is one of my attorneys. Todd Glassey From problem-statement-bounces@alvestrand.no Wed Aug 6 08:53:25 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14507 for ; Wed, 6 Aug 2003 08:53:23 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id D87E761BAD; Wed, 6 Aug 2003 14:52:53 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by eikenes.alvestrand.no (Postfix) with ESMTP id 768ED61B8C for ; Wed, 6 Aug 2003 14:52:52 +0200 (CEST) Received: from mira-sjc5-c.cisco.com (IDENT:mirapoint@mira-sjc5-c.cisco.com [171.71.163.17]) by sj-core-4.cisco.com (8.12.6/8.12.6) with ESMTP id h76Cqnpp027362 for ; Wed, 6 Aug 2003 05:52:50 -0700 (PDT) Received: from cisco.com (ssh-rtp-1.cisco.com [161.44.11.166]) by mira-sjc5-c.cisco.com (Mirapoint Messaging Server MOS 3.3.6-GR) with ESMTP id AKN28264; Wed, 6 Aug 2003 05:52:48 -0700 (PDT) Message-Id: <200308061252.AKN28264@mira-sjc5-c.cisco.com> To: problem-statement@alvestrand.no From: Melinda Shore Date: Wed, 06 Aug 2003 08:52:47 -0400 Subject: Draft meeting minutes X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no I've attached a draft of the meeting minutes from Vienna - many thanks to Spencer Dawkins and Bilel Jamoussi for their detailed notes. Because of the nature of the working group I've erred on the side of too much detail. I've also got an audio recording of the meeting that I'm hoping to put up on the web within the next few days. Melinda Problem Statement Working Group Minutes, IETF 57 Reported by Spencer Dawkins, Bilel Jamoussi, and Melinda Shore The Problem Statement working group met for one 2.5-hour session in Vienna. The topics covered during the meeting were the two deliverables (problem description document and process document), and moving those towards closure. The intention is to release a new version of the problem description document after the IETF meeting and put that into WG last call. Problem Statement Document We went through open issues and tried to come to closure on them. The first open issue was the discussion of timeliness in section 2.1 of the draft. Several problems that were brought out included that we don't say whether we're talking about "timeliness" refers to working group milestones or to market needs (Margaret Wasserman). The issue is the time involved in moving from draft to proposed standard (Scott Bradner), and that dependencies between documents can hold things up even longer (Elwyn Davies). Harald Alvestrand said that section 2.3 of the draft captures the point well and suggested that we add the word "timeliness" to it. A hum from the working group showed agreement with Harald's point/suggestion. The next open issue was the appeals process. There are questions about both informal mechanisms for resolving processes as well as the formal ones (Margaret Wasserman). It was suggested that the barriers to entry on formal appeals include intimidation and that we need to find a balance between accessibility and providing barriers to frivolity (Dave Crocker). Dave also pointed out that we've never used the recall process and so we can't know if it's useful in practice, and that any changes we make should be based in experience. Brian Carpenter asked that we consider situations where the appeals process itself has failed, not where people were unwilling to use the process. Margaret suggested the introduction of a less formal problem resolution mechanism that could be the last step before a formal appeal, such as an ombudsman. Scott Bradner went back to the recall discussion and pointed out that the lack of recall attempts doesn't mean that there's never been a case where someone thought that an individual should have been recalled. Recalls would take time, so there's no incentive to start a recall within six months of a nomcom - this has been an issue at least twice. This issue needs further discussion on the WG mailing list. The next issue discussed was the size of protocol specifications. Joel Halpern said that he thought of it as a slightly different question - that we want to be able to solve smaller pieces and build from them rather than trying to boil the ocean. Charlie Perkins agreed and said that we need to allow a natural progression through publication of stable pieces and add as needed. Spencer Dawkins pointed out that we need both interface specifications and systems specifications, not just one or the other. Harald Alvestrand said that the issue here isn't about specifications that are too big, it's about complexity. Charlie Perkins added that we need to be able to review the documents, and smaller pieces are more manageable. Elwyn Davies asked that people contribute text if they feel that what is currently in the document is inadequate. The next question was whether or not it's a problem that we have Area Directors who are also working group chairs. Margaret Wasserman said that this was a tiny piece of a larger problem, which is that all of our leaders have multiple roles. This is not inherently a problem except in cases where there may be conflicting responsibilities, for example when an AD is a document editor in a working group in his/her own area and is consequently the chair's "boss." This can blow the appeals chain. Jim Seng said that this causes problems around getting consensus, as well. Dave Crocker said that intimidation comes back into play in this scenario, especially when the IETF has new participants. A hum was taken and there was agreement that section 2.6.6 actually covers this issue adequately. We moved on to discuss whether or not the scope of the IETF is a root cause of current problems. Scott Bradner disagreed that this was the right question to ask, and said that the ITU-T says that the lack of defined scope is the problem. Elwyn agreed and said that it's already covered in section 2.1. A hum indicated that those present felt that the scope question is currently covered sufficiently well in the document. The next question was whether or not there's a problem for non-native English speakers in how the IETF executes its work. Elwyn said that the document currently covers problems with our culture but not education about our culture. Margaret Wasserman said that she didn't think this was a root cause problem, but that the real issue here is whether or not we're successful at becoming a global organization. Raj Patel agreed. James Seng said that this isn't a big problem that prevents progress but it's a minor problem that the IETF has been hostile to ESL participants, especially with cultural differences. Dave Crocker said that he's starting to agree with Margaret about the what the real issue is, and that we should think about what cultural adjustments we're willing to make. John Loughney described differences in expectations of formality, levels of aggressiveness, and so on. Leslie Daigle's criterion was that if you wave a magic wand and the problem goes away, would we be more successful? She thinks our quality would improve. A hum indicated that we need more text on this issue. We then moved on to discuss whether or not our current document format is a problem. Margaret Wasserman asked if this was actually an RFC Editor problem, and Scott Bradner answered that the IETF problem is repeated discussions of the same issue. We took a hum and the sense of the room was that document format is not an issue. The next issue was that of complex problem resolution - how we resolve cross-organizational issues. Alastair Deering said that the IETF has a good working group structure but an opaque area structure and no idea where decisions are made. There needs to be a hierarchy of consensus-making. Working groups are too small for this purpose, experts are too split, and we consequently don't have a broad vision. Scott Bradner said that the issue we're talking about isn't complexity but that decisions can't stay made, which is a systemic issue. Charlie Perkins asked that we start documenting our decisions better. For example, has there ever been an RFC written on ASCII vs. something else? Harald's perspective from the IESG is that community-wide consensus is a big problem and paralyzes the IESG because they don't know what the community wants. Mike ??? said that the W3C decided that they would document their architecture as axiomatic principles, not open for discussion. It may be heavy-handed but right now the IETF process for discovering decisions that are no longer open for discussion stinks. Closing: Elwyn will propose document changes on the mailing list and try to get agreement on them, then fold them into the next release of the document which will be put into WG last call. Process Document This was our first opportunity to discuss the process document at a meeting. The first question was whether or not we're ready to tackle the near-term recommendations. Brian Carpenter suggested that many of these are actually secretariat issues, such as updating milestones. Dave Crocker said that it's been a year since Yokohama and there still haven't been changes. Harald went back to Brian's comment and said that the people who should be noticing that there's a problem with milestone updates are the chairs and ADs. The mechanical part isn't the problem. Margaret said that there are things we can be working on right away, for example posting pointers to appeals, providing a suggestion box, and so on. Joel Halpern said that his WG milestones are wrong because changing the charter is political and difficult, and there are a lot of issues about updating charters. Aaron Falk pointed out that there are a lot of uses for charters. It's a contract between the working group and the AD, not advertising for the WG. Joel asked that we not spend all of our energy on attacking near-term solutions. We need to work on fixing structural problems before the organization falls apart. Dave Crocker disagreed and said that the current processes work fine, just not often enough. Every time we've ever tried to tackle a big problem in a big way we've messed it up. Organizational change is not our area of expertise, so that would be even worse. Allison Mankin really liked the process document and COACH BOF. She wondered why we don't regard the WG chairs as a leadership cadre. Alastair Deering said that other standards bodies have disciplined themselves to stop trying to modify IETF protocols themselves but it's come at the cost of dependencies. For example, 3GPP has a list of 67 dependencies on IETF work for their current release. Avri asked whether we need a short-term WG on liaisons - there was no answer. Bob Hinden said that there are no perfect organizational structures and that we haven't changed ours in a very long time. It's time to change, and we should give WG chairs more responsibility. Ed Juscoviscious addressed the question of charters as contracts and suggested that WGs can't be accountable to dependencies because they don't have control over their own destinies. Scott Bradner said that the IETF has historically been a bottom-up organization. We trickle up, and the previous speakers have been talking about an issue where this isn't appropriate. We don't even rely on outputs of other WGs well. We can't deal with dependencies if there is no way to direct working groups to focus on certain strategic areas. Jonne Soinenen said that there are so many 3GPP dependencies on milestones that aren't met, and asked for reasonable and realistic milestones. Margaret asked that we get back on track to discussing the process document. Avri took a hum to see if those present felt that the overall direction of the document is correct. The hum was positive. She next asked if there are incorrect recommendations in the document, and the hum was negative. The next question was whether or not we need to define a process to identify a mission statement. Margaret Wasserman no longer thinks this is the right thing to do, that we could end up in an eternal rat-hole. It would be great to figure it out but we shouldn't gate anything on it and perhaps it shouldn't be done in a traditional working group. Brian Carpenter said that we do need to do some of it, that scope does matter. He asked that if we do do it, not to use a design team. John Klensin said that we're running the risk of generating process that becomes part of the problem. We need to cut it down and streamline it, and not rely on the IESG folowing detailed procedures. We should work through discussions, nomcom, or even recall petitions. Joel said that he thought those are great things to do but we can't do them in a working group and we have to socialize the results very widely. Scott Bradner said that these things aren't static and that writing them down is a huge mistake. A hum was taken on whether or not we need to define a process to develop a mission statement, and the room was evenly split. We also took a hum on splitting phase 1 and phase 2 as described in the 00 version of the process document, and that was evenly split as well. We next discussed the question of whether an organizational change to our leadership structure is required. Margaret said that it was important to make a process recommendation as part of the problem statement. We could give our leadership a mandate to solves these problems, or we could give it to somebody else. Graham Travers asked if we don't make a recommendation, what will we have done? Brian Carpenter restated the question to being one of organizational reform and leadership responsibility for reform. Joel Halpern said that we're going to need a fairly major change and that if we don't think out-of-the-box it's not going to happen. Margaret agreed and said that our lower-level problems need reorganization as a solution, and that if we don't give that mandate to someone we haven't done anything. Scott disagreed and that we haven't proven that we need to reorganize and we haven't proven that we don't. Our current process to accept change relies on the leadership. Leslie Daigle said that if we fail to make process recommendations we won't have done "nothing" - documenting existing problems is a significant step. If we don't fix them in a year, call nomcom. Charlie Perkins said that the composition of the organization may be okay but not the distribution of responsibility. For example, make the IAB responsible for enforcing architectural principles instead of the IESG. Getting away from adversarial relationships is important. We then moved to discussion three bullet items at once: 1) changing the standards track, 2) whether or not the short- term and long-term problems should be attacked in parallel, and 3) if a working group should be chartered to address long-term problems. Elwyn said that problems with our standards track are our most important problems. What we claim to do is not what we do, and since our Proposed Standards haven't been through the implementation and testing process they are paper specifications. Charlie Perkins said that we must change the standards-track process because it doesn't fulfill internal or external needs, that we should do things in parallel, and that a working group will take too long. He also said that he couldn't think of a better approach than a working group. Scott Bradner said that the standards process has shifted one stage to the left, and there's no energy to advance specifications beyond what used to be an internet draft level of sophistication and experience. Harald said that people design and working groups review, and therefore that we shouldn't use a working group to create process proposals. Raj Patel agreed, particularly on problems with working group timeliness. Do small things quickly and use design teams for more complex tasks. Alastair said that the IETF has become a laughingstock in other standards bodies. The ITU-T can go from wanting to do a BOF to publishing a recommendation in less than nine months. A hum was taken on moving forward. When asked whether solutions work should be started 1) when the problem statement is approved, 2) when the process document is approved, or 3) now, the hum was decidedly in favor of 3), now. From problem-statement-bounces@alvestrand.no Mon Aug 11 07:39:56 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13301 for ; Mon, 11 Aug 2003 07:39:55 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 03A8F61C00; Mon, 11 Aug 2003 13:39:27 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from netcore.fi (netcore.fi [193.94.160.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2E64861BD8 for ; Mon, 11 Aug 2003 13:39:25 +0200 (CEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7BBdOH16112 for ; Mon, 11 Aug 2003 14:39:24 +0300 Date: Mon, 11 Aug 2003 14:39:24 +0300 (EEST) From: Pekka Savola To: problem-statement@alvestrand.no Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: comments on problem-issue-statement-02 X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Hi, Below are a few comments I scribbled up when reading the problem statement draft. I didn't go at it in a lot detail, though. In general, I think the document is in a pretty good condition. I've about 3 more substantial issues some of which may be worth discussing, and a few more editorial ones. All of them should be easily fixable. substantial ----------- 1) ==> general note: there are a few words used in the document that break at least one principle we've found out, that is, not friendly for non-native speakers. At least "stratification", "exacerbate", "cross-pollinating", "ossification", and "Shibboleth". Personally I've pretty good idea of these, but I always flinch when I see too fancy words used, and I think at least these are a symptom of that :-) 2) o The IETF needs to avoid focusing on a too-narrow scope of technology because this would be likely to blinker the IETF's view of 'the good of the Internet', and will harm the long-term goal of making the Internet useful to the greatest number stakeholders; this argues for allowing a relatively wide range of topics to be worked on in the IETF - cross-fertilization has always been one of the IETF's strengths. ==> I think the two-three last lines miss the point completely, or I have an entirely different view of "cross-fertilization". I do not think cross-fertilization automatically happens if we allow a wide range of topics to be worked at here. Rather, it will only happen if people have the will and the energy to spend looking at and helping the other working groups by implanting clue there. How should this text be edited? Good question, either it can be fixed up slightly or revised at more length. Thoughts? 3) 2.6.6 Concentration of Influence in Too Few Hands Until the last couple of years, successive IETF Nominating Committees have chosen to give heavy weighting to continuity of IESG and IAB membership. Thus, the IETF appeared to have created an affinity group system which tended to re-select the same leaders from a limited pool of people who had proved competent and committed in the past. ==> I think there is a potential issue in how the NOMCOM goes about it's business (the approach has obvious advantages too, of course). That is, providing feedback to NOMCOM is very difficult except about current IESG members (whose performance is more or less visiable and known after 2 years, and who usually agree to continue to serve if necessary), and some outstanding new candidates. People might have a *lot* of feedback to give about non-IESG candidates if it was known that those persons have agreed to become nominated. That way, it may be very difficult to get on at the same level of feedback than the current members, and it seems to me that if the current members are willing to continue and haven't done a bad job of it, the process also favors their re-instalment pretty well. But this is both a bug and a feature.. semi-editorial -------------- o Working Groups can potentially be hijacked by sectional interests to the detriment of the IETF's mission. ==> I'm not sure what this point is trying to say, in particular regarding "sectional interests". That there are a number of separate, tightly focused interest groups who are only pushing their own agenda (and e.g. obtaining rough consensus in WGs by room packing) and not advancing the IETF mission? Re-phrase? o Lack of an explicit feed forward path to drive the improvement of the standards development process and success criteria over time and to avoid repetition of failures that may occur. ==> what is "an explicit _feed_ forward path" I've no idea... Normative References [1] Huston, G. and M. Rose, "A Proposal to Improve IETF Productivity", draft-huston-ietf-pact-00 (work in progress), October 2002. [2] Blanchet, M., "Suggestions to Streamline the IETF Process", draft-blanchet-evolutionizeietf-suggestions-00 (work in progress), November 2002. [3] Hardie, T., "Working Groups and their Stuckees", draft-hardie-wg-stuckees-00 (work in progress), February 2003. ==> all of these should probably be informative references, as this document couldn't be published without them getting published otherwise.. [4] Huitema, C. and P. Gross, "The Internet Standards Process -- Revision 2", RFC 1602, March 1994. ==> this should be updated to point to RFC2026? :-) editorial --------- o The sub-section of Section 2.6 dealing with Formal Reconition has been moved to Section 2.5. ==> s/Reco/Recog/ preparation of WG chairs and ADs for conflict resoution is noted. ==> s/reso/resol/ o The IETF is unsure who its stakeholders are, and consequently has managed to drive certain groups of stakeholder, who would ==> s/stakeholder/stakeholders/ o Lack of metrics to measure the achievement of the desired quality and the performance of WGs and the wider IETF.. ==> s/.././ o The IETF does not posess effective formal mechanisms for inter-WG cooperation or communication. ==> s/posess/possess/ ? that subsequent modifications will be minimal as it progresses to DS and FS, assuming effort can be found to create the necessary applicability and interoperability reports that are needed.. ==> s/.././ Note: Using Leadership positions as rewards for good work would probably be damaging to the IETF. ==> s/L/l/, maybe even s/U/u/ ? o Effectively providing technical management, people-management and project supervision for their WGs ==> s/people-management/people management/ ? o Recruiting shrinkage: The number of people who can imagine taking on an IESG post is steadily decreasing. It is largely limited to people who work for large companies who can afford to second IESG members to the IETF for the duration of their appointments. ==> use some other word than "second", like "support" (and other rewording), the intent is not clear. Delay in authorizing a BOF or chartering a new WG can delay the start of the process with similar effects. ==> s/BOF /BOF/ (remove extra space) 'advising' or 'process' chair to work with an enthusiatic newcomer in ==> s/tic/stic/ The IETF culture of openess also tends to tolerate participants, who, s/openess/openness/ -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From problem-statement-bounces@alvestrand.no Thu Aug 14 04:52:43 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03650 for ; Thu, 14 Aug 2003 04:52:43 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 645E761BE6; Thu, 14 Aug 2003 10:52:14 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from bs.jck.com (ns.jck.com [209.187.148.211]) by eikenes.alvestrand.no (Postfix) with ESMTP id CAA8161BB1 for ; Thu, 14 Aug 2003 10:52:12 +0200 (CEST) Received: from [209.187.148.215] (helo=scan.jck.com) by bs.jck.com with esmtp (Exim 4.10) id 19nDq6-000F6Q-00; Thu, 14 Aug 2003 03:52:10 -0500 Date: Thu, 14 Aug 2003 04:52:10 -0400 From: John C Klensin To: Pekka Savola , "problem-statement@alvestrand.no" Message-ID: <159003625.1060836730@scan.jck.com> In-Reply-To: References: X-Mailer: Mulberry/3.1.0b5 (Win32) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Subject: Re: comments on problem-issue-statement-02 X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no Content-Transfer-Encoding: 7bit --On Monday, 11 August, 2003 14:39 +0300 Pekka Savola wrote: >... > Normative References > > [1] Huston, G. and M. Rose, "A Proposal to Improve IETF > Productivity", draft-huston-ietf-pact-00 (work in progress), > October 2002. > > [2] Blanchet, M., "Suggestions to Streamline the IETF > Process", > draft-blanchet-evolutionizeietf-suggestions-00 (work in > progress), November 2002. > > [3] Hardie, T., "Working Groups and their Stuckees", > draft-hardie-wg-stuckees-00 (work in progress), February 2003. > > ==> all of these should probably be informative references, as > this document couldn't be published without them getting > published otherwise.. Let's be very careful here, lest we create and illustrate a problem that then belongs, recursively, on the list. Something is a normative reference or not depending on how the text that uses the reference actually does so. If the text is written such that understanding and, if appropriate, conforming to, the text of the reference is necessary to understanding or implementing the present text, then the reference is normative, period. Conversely, something is informative only if the usage in the text has the character of, e.g., "you don't need to know this, but, if you want to learn more about it, see [4]" or "for examples of how this is done, see [7]". And the second of those becomes normative if the text itself fails to provide a complete specification but, instead, relies on the examples for important information. Sorry to pick on you Pekka, but your comment above, which implies that one can simply move the references from one section to another in order to avoid the "publication first" rule, illustrates either that * The normative/informative rule fails to solve the problem for which it was announced. Instead, it replaces the old problem ("careful effort must go into examination of a document to determine which references are actually normative") with a new, and harder, problem ("documents must be examined to ensure that actual normative references are not disguised as informative ones in the hope of earlier publication (or of making publication possible)"). * The IESG and RFC Editor have made a procedural rule that is sufficiently ill-defined that even people acting with good intent cannot determine what it actually means. or perhaps both. To be fair to Pekka, simply changing things to avoid a rule is probably not what he intended. But, I have certainly seen documents in which references that were almost certainly normative were listed as informative and then published. Had those references been listed as normative, the documents in question would still be sitting in queue. So this makes a useful example. I suggest that the document be expanded to include something like: In generating procedural rules to supplement written, community-approved procedures, the IESG (and others) sometimes underspecify those rules, leading to (i) an additional requirement for case-by-case, seemingly-arbitrary, decisions and to (ii) the development of a subtle "oral tradition" around those rules, and to (iii) an opportunity and incentive for people to "game" the rules, in the hope of escaping (or imposing) whatever burdens they imply. The first of these results is a cause of "late surprises" and wasted time, since a document editor, other individual IETF participant, or WG, acting in good faith, often cannot know how things will be handled without picking an approach, completing the work, and then seeing how things work out. It is also one of the causes (or enabling mechanisms) of people --ADs or not-- trying to influence the decisions of a WG by making "the IESG will never accept..." or "the IESG will require..." statements that seem plausible given the rules. The second acts as a barrier to effective and efficient participation by those who are relatively new to the IETF and, often has greater impact on non-native speakers of English than on those who are good at discerning subtle meanings and intent. And the third wastes everyone's time -- that of the participant who is trying to find a loophole and exploit it, that of reviewers trying to detect any such exploits, and that of the community when the exploits get through the system anyway -- and leads to unnecessary delays. And, of course, when they do get through, they can be a source of lower quality than we would like (also discussed elsewhere). regards, john From problem-statement-bounces@alvestrand.no Thu Aug 14 06:44:06 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05917 for ; Thu, 14 Aug 2003 06:44:03 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2C0DE61BEE; Thu, 14 Aug 2003 12:43:32 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from netcore.fi (netcore.fi [193.94.160.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 4C0FF61BE6 for ; Thu, 14 Aug 2003 12:43:30 +0200 (CEST) Received: from localhost (pekkas@localhost) by netcore.fi (8.11.6/8.11.6) with ESMTP id h7EAhI923823; Thu, 14 Aug 2003 13:43:18 +0300 Date: Thu, 14 Aug 2003 13:43:17 +0300 (EEST) From: Pekka Savola To: John C Klensin In-Reply-To: <159003625.1060836730@scan.jck.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: "problem-statement@alvestrand.no" Subject: Re: comments on problem-issue-statement-02 X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no On Thu, 14 Aug 2003, John C Klensin wrote: > --On Monday, 11 August, 2003 14:39 +0300 Pekka Savola > wrote: > > >... > > Normative References > > > > [1] Huston, G. and M. Rose, "A Proposal to Improve IETF > > Productivity", draft-huston-ietf-pact-00 (work in progress), > > October 2002. > > > > [2] Blanchet, M., "Suggestions to Streamline the IETF > > Process", > > draft-blanchet-evolutionizeietf-suggestions-00 (work in > > progress), November 2002. > > > > [3] Hardie, T., "Working Groups and their Stuckees", > > draft-hardie-wg-stuckees-00 (work in progress), February 2003. > > > > ==> all of these should probably be informative references, as > > this document couldn't be published without them getting > > published otherwise.. > > Let's be very careful here, lest we create and illustrate a > problem that then belongs, recursively, on the list. > > Something is a normative reference or not depending on how the > text that uses the reference actually does so. If the text is > written such that understanding and, if appropriate, conforming > to, the text of the reference is necessary to understanding or > implementing the present text, then the reference is normative, > period. Conversely, something is informative only if the usage > in the text has the character of, e.g., "you don't need to know > this, but, if you want to learn more about it, see [4]" or "for > examples of how this is done, see [7]". And the second of those > becomes normative if the text itself fails to provide a complete > specification but, instead, relies on the examples for important > information. Sorry for my bad wording. There is a problem worth discussing, yes, but in this particular case I was just (poorly) stating that those three references IMHO were clearly informative; they concentrate on solutions, not the problems. In this case, I believe they actually should have been Informative references. > Sorry to pick on you Pekka, but your comment above, which > implies that one can simply move the references from one section > to another in order to avoid the "publication first" rule, > illustrates either that > > * The normative/informative rule fails to solve the > problem for which it was announced. Instead, it > replaces the old problem ("careful effort must go into > examination of a document to determine which references > are actually normative") with a new, and harder, problem > ("documents must be examined to ensure that actual > normative references are not disguised as informative > ones in the hope of earlier publication (or of making > publication possible)"). True, this may be a problem. See below. > * The IESG and RFC Editor have made a procedural rule > that is sufficiently ill-defined that even people acting > with good intent cannot determine what it actually means. I think it's not that difficult to read through normative and informative reference lists and state "OK, I think some of these belong the the other category". So the split seems useful, because instead of everyone forming their own opinion on what is normative/informative, there is one split shown which people should agree to (or if disagree, send in comments to change the fact). > To be fair to Pekka, simply changing things to avoid a rule is > probably not what he intended. But, I have certainly seen > documents in which references that were almost certainly > normative were listed as informative and then published. Had > those references been listed as normative, the documents in > question would still be sitting in queue. So this makes a > useful example. Certainly, there are cases like these. > I suggest that the document be expanded to include something > like: No comment on this proposal. > In generating procedural rules to supplement written, > community-approved procedures, the IESG (and others) sometimes > underspecify those rules, leading to > > (i) an additional requirement for case-by-case, > seemingly-arbitrary, decisions and to > > (ii) the development of a subtle "oral tradition" around > those rules, and to > > (iii) an opportunity and incentive for people to "game" > the rules, in the hope of escaping (or imposing) > whatever burdens they imply. > > The first of these results is a cause of "late surprises" and > wasted time, since a document editor, other individual IETF > participant, or WG, acting in good faith, often cannot know how > things will be handled without picking an approach, completing > the work, and then seeing how things work out. It is also one > of the causes (or enabling mechanisms) of people --ADs or not-- > trying to influence the decisions of a WG by making "the IESG > will never accept..." or "the IESG will require..." statements > that seem plausible given the rules. > > The second acts as a barrier to effective and efficient > participation by those who are relatively new to the IETF and, > often has greater impact on non-native speakers of English than > on those who are good at discerning subtle meanings and intent. > > And the third wastes everyone's time -- that of the participant > who is trying to find a loophole and exploit it, that of > reviewers trying to detect any such exploits, and that of the > community when the exploits get through the system anyway -- and > leads to unnecessary delays. And, of course, when they do get > through, they can be a source of lower quality than we would > like (also discussed elsewhere). > > regards, > john > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From problem-statement-bounces@alvestrand.no Thu Aug 21 00:59:04 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA02702 for ; Thu, 21 Aug 2003 00:59:03 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 845BA61C05; Thu, 21 Aug 2003 06:58:38 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mail.wrs.com (unknown-1-11.wrs.com [147.11.1.11]) by eikenes.alvestrand.no (Postfix) with ESMTP id 03BF861C03 for ; Thu, 21 Aug 2003 06:58:36 +0200 (CEST) Received: (from mrw@localhost) by mail.wrs.com (8.9.3/8.9.1) id VAA22989 for problem-statement@alvestrand.no; Wed, 20 Aug 2003 21:58:22 -0700 (PDT) Date: Wed, 20 Aug 2003 21:58:22 -0700 (PDT) Message-Id: <200308210458.VAA22989@mail.wrs.com> To: problem-statement@alvestrand.no From: mrw@windriver.com (via the vacation program) Subject: away from my mail X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no I will be on vacation until September 2nd, 2003. I will be reading mail occasionally during this time, but I am unlikely to respond to non-critical issues. If you have an urgent issue and need to reach me immediately, please contact my assistant Stephanie Jones: . Margaret I will not be reading my mail for a while. Your mail regarding "Re: That movie" will be read when I return. From problem-statement-bounces@alvestrand.no Tue Aug 26 10:06:23 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05000 for ; Tue, 26 Aug 2003 10:06:22 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 30F9D61BE8; Tue, 26 Aug 2003 16:05:55 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from ietf.org (odin.ietf.org [132.151.1.176]) by eikenes.alvestrand.no (Postfix) with ESMTP id 2BE8361BE8 for ; Tue, 26 Aug 2003 16:05:53 +0200 (CEST) Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04856; Tue, 26 Aug 2003 10:05:47 -0400 (EDT) Message-Id: <200308261405.KAA04856@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: problem-statement@alvestrand.no From: Internet-Drafts@ietf.org Date: Tue, 26 Aug 2003 10:05:47 -0400 Subject: I-D ACTION:draft-ietf-problem-issue-statement-03.txt X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list Reply-To: Internet-Drafts@ietf.org List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Problem Statement Working Group of the IETF. Title : IETF Problem Statement Author(s) : E. Davies Filename : draft-ietf-problem-issue-statement-03.txt Pages : 24 Date : 2003-8-26 This memo summarizes perceived problems in the structure, function and processes of the Internet Engineering Task Force (IETF). We are attempting to identify these problems, so that they can be addressed and corrected by the IETF community. The problems have been digested and categorized from an extensive discussion which took place on the 'problem-statement' mailing list from November 2002 to May 2003. The problem list has been further analyzed to try and determine the root causes, that are at the heart of the perceived problems: The result will be used to guide the next stage of the process in the Problem Statement working group which is to determine the structures and processes that will carry out the corrections. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-problem-issue-statement-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-problem-issue-statement-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-problem-issue-statement-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-26102435.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-problem-issue-statement-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-problem-issue-statement-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-26102435.I-D@ietf.org> --OtherAccess-- --NextPart-- From problem-statement-bounces@alvestrand.no Tue Aug 26 10:26:16 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07908 for ; Tue, 26 Aug 2003 10:26:15 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id 1FF1E61BE8; Tue, 26 Aug 2003 16:25:47 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from mx03.forces.gc.ca (mx03.forces.gc.ca [131.137.245.203]) by eikenes.alvestrand.no (Postfix) with ESMTP id 412B261B94 for ; Tue, 26 Aug 2003 16:25:45 +0200 (CEST) Received: from asgard.ietf.org (asgard.ietf.org [132.151.6.40]) by mx03.forces.gc.ca (DND-Mailer) with ESMTP id BFC6720662B for ; Tue, 26 Aug 2003 10:23:02 -0400 (EDT) Received: from majordomo by asgard.ietf.org with local (Exim 4.14) id 19reSn-0008Ah-Iv for ietf-announce-list@asgard.ietf.org; Tue, 26 Aug 2003 10:06:25 -0400 Received: from ietf.org ([10.27.2.28]) by asgard.ietf.org with esmtp (Exim 4.14) id 19reSI-0007z7-11 for all-ietf@asgard.ietf.org; Tue, 26 Aug 2003 10:05:54 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04856; Tue, 26 Aug 2003 10:05:47 -0400 (EDT) Message-Id: <200308261405.KAA04856@ietf.org> To: IETF-Announce: ; Cc: problem-statement@alvestrand.no From: Internet-Drafts@ietf.org Date: Tue, 26 Aug 2003 10:05:47 -0400 Precedence: bulk MIME-Version: 1.0 Content-Type: Multipart/Mixed; boundary="MIMEStream=_0+53650_77597319743793_307124796" Subject: I-D ACTION:draft-ietf-problem-issue-statement-03.txt X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Reply-To: Internet-Drafts@ietf.org List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no --MIMEStream=_0+53650_77597319743793_307124796 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Problem Statement Working Group of the IETF. Title : IETF Problem Statement Author(s) : E. Davies Filename : draft-ietf-problem-issue-statement-03.txt Pages : 24 Date : 2003-8-26 This memo summarizes perceived problems in the structure, function and processes of the Internet Engineering Task Force (IETF). We are attempting to identify these problems, so that they can be addressed and corrected by the IETF community. The problems have been digested and categorized from an extensive discussion which took place on the 'problem-statement' mailing list from November 2002 to May 2003. The problem list has been further analyzed to try and determine the root causes, that are at the heart of the perceived problems: The result will be used to guide the next stage of the process in the Problem Statement working group which is to determine the structures and processes that will carry out the corrections. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-problem-issue-statement-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-problem-issue-statement-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-problem-issue-statement-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --MIMEStream=_0+53650_77597319743793_307124796 Content-Type: Multipart/Alternative; boundary="MIMEStream=_1+108079_0438371210674_7400185232" --MIMEStream=_1+108079_0438371210674_7400185232 Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-8-26102435.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-problem-issue-statement-03.txt --MIMEStream=_1+108079_0438371210674_7400185232 Content-Type: Message/External-body; name="draft-ietf-problem-issue-statement-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-8-26102435.I-D@ietf.org> --MIMEStream=_1+108079_0438371210674_7400185232-- --MIMEStream=_0+53650_77597319743793_307124796-- From problem-statement-bounces@alvestrand.no Sun Aug 31 04:43:13 2003 Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA03233 for ; Sun, 31 Aug 2003 04:43:12 -0400 (EDT) Received: from eikenes.alvestrand.no (localhost.localdomain [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id CE00361B91; Sun, 31 Aug 2003 10:42:45 +0200 (CEST) X-Original-To: problem-statement@alvestrand.no Delivered-To: problem-statement@alvestrand.no Received: from psg.com (psg.com [147.28.0.62]) by eikenes.alvestrand.no (Postfix) with ESMTP id ED6C961B8D for ; Sun, 31 Aug 2003 04:51:34 +0200 (CEST) Received: from psg.com ([147.28.0.62]) by psg.com with esmtp (Exim 4.22) id 19tIJR-0004Cj-CD; Sun, 31 Aug 2003 02:51:33 +0000 Date: Sun, 31 Aug 2003 11:51:00 +0900 Content-Type: multipart/alternative; boundary=Apple-Mail-35-239198007 Mime-Version: 1.0 (Apple Message framework v552) To: problem-statement@alvestrand.no From: avri Message-Id: X-Mailer: Apple Mail (2.552) X-Mailman-Approved-At: Sun, 31 Aug 2003 10:42:44 +0200 Cc: Melinda Shore Subject: WG Last Call on IETF Problem Statement X-BeenThere: problem-statement@alvestrand.no X-Mailman-Version: 2.1.2 Precedence: list List-Id: Problem Statement List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: problem-statement-bounces@alvestrand.no Errors-To: problem-statement-bounces@alvestrand.no --Apple-Mail-35-239198007 Content-Type: text/plain; delsp=yes; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit This note marks the beginning of the WG Last call for: > Title : IETF Problem Statement > Author(s) : E. Davies > Filename : draft-ietf-problem-issue-statement-03.txt > Pages : 24 > Date : 2003-8-26 > The document can be found at: A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-problem-issue-statement- 03.txt Because of the US holiday on Monday , 1- Sept, the last call will extend from now, 31 August until 16 September (any time zone). Please send your comments to the WG mailing list problem-statement@alvestrand.no thanks a. Avri Doria co-chair --Apple-Mail-35-239198007 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit This note marks the beginning of the WG Last call for: Title : IETF Problem Statement Author(s) : E. Davies Filename : draft-ietf-problem-issue-statement-03.txt Pages : 24 Date : 2003-8-26 The document can be found at: A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-problem-issue-statement-03.txt Because of the US holiday on Monday , 1- Sept, the last call will extend from now, 31 August until 16 September (any time zone). Please send your comments to the WG mailing list Lucida Grandeproblem-statement@alvestrand.no thanks a. Avri Doria co-chair --Apple-Mail-35-239198007--