[newtrk] IETF Process discussions - next steps
Brian E Carpenter <brc@zurich.ibm.com> Thu, 10 August 2006 09:48 UTC
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1GB79U-0008Hy-FL for newtrk-archive@lists.ietf.org; Thu, 10 Aug 2006 05:48:32 -0400
Received: from mailapps.uoregon.edu ([128.223.142.45]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1GB79R-0002nt-UM for newtrk-archive@lists.ietf.org; Thu, 10 Aug 2006 05:48:32 -0400
Received: from mailapps.uoregon.edu (localhost [127.0.0.1]) by mailapps.uoregon.edu (8.13.7/8.13.7) with ESMTP id k7A9gVu5031812; Thu, 10 Aug 2006 02:42:31 -0700
Received: (from majordom@localhost) by mailapps.uoregon.edu (8.13.7/8.13.7/Submit) id k7A9gV6F031810; Thu, 10 Aug 2006 02:42:31 -0700
Received: from mtagate2.uk.ibm.com (mtagate2.uk.ibm.com [195.212.29.135]) by mailapps.uoregon.edu (8.13.7/8.13.7) with ESMTP id k7A9gTCT031794 for <newtrk@lists.uoregon.edu>; Thu, 10 Aug 2006 02:42:30 -0700
Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate2.uk.ibm.com (8.13.7/8.13.7) with ESMTP id k7A9gNni076392 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <newtrk@lists.uoregon.edu>; Thu, 10 Aug 2006 09:42:24 GMT
Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.6/NCO/VER7.0) with ESMTP id k7A9iCZX132120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <newtrk@lists.uoregon.edu>; Thu, 10 Aug 2006 10:44:12 +0100
Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k7A9gNQu000367 for <newtrk@lists.uoregon.edu>; Thu, 10 Aug 2006 10:42:23 +0100
Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av02.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k7A9gNDu000362 for <newtrk@lists.uoregon.edu>; Thu, 10 Aug 2006 10:42:23 +0100
Received: from zurich.ibm.com (sig-9-145-255-174.de.ibm.com [9.145.255.174]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id LAA174272 for <newtrk@lists.uoregon.edu>; Thu, 10 Aug 2006 11:42:22 +0200
Message-ID: <44DAFF7D.1060803@zurich.ibm.com>
Date: Thu, 10 Aug 2006 11:42:21 +0200
From: Brian E Carpenter <brc@zurich.ibm.com>
Organization: IBM
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113
X-Accept-Language: en, fr, de
MIME-Version: 1.0
To: New Track <newtrk@lists.uoregon.edu>
Subject: [newtrk] IETF Process discussions - next steps
Content-Type: text/plain; charset="us-ascii"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: ClamAV 0.88.4/1644/Wed Aug 9 20:55:42 2006 on mailapps
X-Virus-Status: Clean
Sender: owner-newtrk@lists.uoregon.edu
Precedence: bulk
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86
Here are my conclusions from the plenary discussion and the General Area open meeting at IETF 66. 1. Conclusions from plenary discussion on Newtrk issues (draft-carpenter-newtrk-questions-00.txt) A clear theme in the plenary discussion in Montreal was "declare victory." Unfortunately, in reading the notes and listening to the audio recording, and reading subsequent emails, it is also clear that different speakers meant different things by this phrase - anywhere from clarifying today's standards track, through reducing it to two or one stages, to simply sitting down and shutting up. Although on the order of 40 people out of several hundred in the plenary appeared to believe that formal changes to the standards process should be made, and some people are ready to do work (thanks!) there was no firm consensus for a given direction (as there never has been in the Newtrk WG). One useful observation was that there is nothing in present rules and procedures to prevent the writing and publication of overview standards documents ("ISDs" in Newtrk parlance), as long as they fit into RFC 2026 rules as Applicability Statements. A need was observed for lightweight documentation of the real world deployment status of individual standards, as concrete feedback from running code. Again, no rule prevents this today, but neither do we have guidelines as to the format, status and indexing of such documents. My conclusions are that: 1.1. There is insufficient pressure and energy in the community to justify the effort of reaching consensus on formal changes to the standards process at this time. 1.2. For complex standards where a normative or informative overview document would be beneficial, nothing in today's rules and procedures prevents interested parties from writing and submitting such documents within the rules set by RFC 2026, and such efforts should be welcomed. 1.3. The community should be encouraged to produce documentation of deployment and interoperability of individual IETF standards, even if there is no proposal to advance them on the standards track. Such documents should be directed towards efforts to update IETF standards and/or to document errata and operational issues. A more systematic framework than today's implementation reports would be beneficial. 1.4. The newtrk WG should be closed. 2. Conclusion from GenArea mini-BOF on IESG structure and charter. It seemed clear in the room that people felt there was not a serious enough problem with RFC 3710 to justify a significant effort. There was some support for undertaking at least the first step: * List Tasks that Currently Gate on the IESG in order to document whether there is in fact a problem worth solving. My conclusion is to ask John Leslie to lead a small team to carry out this very specific task for the information of the community. 3. Conclusion from GenArea mini-BOF on WG Procedures (RFC 2418) It seems there is some feeling that the RFC is beginning to show its age, and would be worth updating. My conclusion is that the best first step is to ask Margaret Wasserman to lead a small team to survey participants and build a list of issues that need updating. Of course, any actual update to RFC 2418 would then have to follow normal IETF consensus process. 3. Conclusion from GenArea mini-BOF on mailing list management procedures. (draft-galvin-maillists-00.txt) It seems clear from recent experience with RFC 3683 that something needs to happen in this area and that feelings run deep on this issue. However, the energy to work on this in the community is limited despite some support in the mini-BOF for doing so. My conclusion is, as experiments under draft-hartman-mailinglist-experiment are possible immediately, there is no urgency to start an organized effort right now - but it should be considered over the coming months. Meanhwile I would like to ask Jim Galvin to update his draft according to the discussion, for future reference. A suggestion was made during the meeting to rapidly declare RFC 3683 obsolete. Brian Carpenter General Area Director . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html
- Re: [newtrk] IETF Process discussions - next steps John C Klensin
- [newtrk] IETF Process discussions - next steps Brian E Carpenter
- Re: [newtrk] IETF Process discussions - next steps Eliot Lear
- Re: [newtrk] IETF Process discussions - next steps Brian E Carpenter
- Re: [newtrk] IETF Process discussions - next steps Pekka Savola
- [newtrk] Reviewing state of PS and DS standards John Leslie
- Re: [newtrk] Reviewing state of PS and DS standar… Scott Bradner
- Re: [newtrk] Reviewing state of PS and DS standar… Scott W Brim
- Re: [newtrk] Reviewing state of PS and DS standar… James M. Polk
- Re: [newtrk] Reviewing state of PS and DS standar… John C Klensin
- Re: [newtrk] Reviewing state of PS and DS standar… Brian E Carpenter
- Re: [newtrk] Reviewing state of PS and DS standar… Brian E Carpenter
- Re: [newtrk] Reviewing state of PS and DS standar… Pekka Savola
- Re: [newtrk] Reviewing state of PS and DS standar… Eliot Lear
- RE: [newtrk] Reviewing state of PS and DS standar… john.loughney
- Re: [newtrk] Reviewing state of PS and DS standar… Margaret Wasserman
- Re: [newtrk] Reviewing state of PS and DS standar… Brian E Carpenter
- Re: [newtrk] Reviewing state of PS and DS standar… Bill Fenner
- Re: [newtrk] Reviewing state of PS and DS standar… Brian E Carpenter
- Re: [newtrk] Reviewing state of PS and DS standar… Margaret Wasserman
- Re: [newtrk] Reviewing state of PS and DS standar… Eliot Lear
- Re: [newtrk] Reviewing state of PS and DS standar… Margaret Wasserman
- Re: [newtrk] Reviewing state of PS and DS standar… John Leslie
- Re: [newtrk] Reviewing state of PS and DS standar… Douglas Otis
- Re: [newtrk] Reviewing state of PS and DS standar… John C Klensin
- Re: [newtrk] Reviewing state of PS and DS standar… John C Klensin
- Re: [newtrk] Reviewing state of PS and DS standar… Spencer Dawkins
- Re: [newtrk] Reviewing state of PS and DS standar… John C Klensin
- Re: [newtrk] Reviewing state of PS and DS standar… Scott W Brim
- Re: [newtrk] Reviewing state of PS and DS standar… John C Klensin
- Re: [newtrk] Reviewing state of PS and DS standar… Eliot Lear
- Re: [newtrk] Reviewing state of PS and DS standar… Douglas Otis
- Re: [newtrk] Reviewing state of PS and DS standar… C. M. Heard
- Re: [newtrk] Reviewing state of PS and DS standar… Brian E Carpenter
- Re: [newtrk] IETF Process discussions - next steps Brian E Carpenter
- RE: [newtrk] IETF Process discussions - next steps Robert Snively
- Re: [newtrk] IETF Process discussions - next steps Douglas Otis
- Re: [newtrk] IETF Process discussions - next steps Brian E Carpenter
- RE: [newtrk] IETF Process discussions - next steps Robert Snively
- Re: [newtrk] IETF Process discussions - next steps Douglas Otis
- Re: [newtrk] IETF Process discussions - next steps John C Klensin
- Re: [newtrk] IETF Process discussions - next steps Brian E Carpenter