[newtrk] pepost - IESG comments on ISDs
sob@harvard.edu (Scott Bradner) Mon, 06 June 2005 14:09 UTC
Received: from darkwing.uoregon.edu (root@darkwing.uoregon.edu [128.223.142.13]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03109 for <newtrk-archive@lists.ietf.org>; Mon, 6 Jun 2005 10:09:18 -0400 (EDT)
Received: from darkwing.uoregon.edu (majordom@localhost [127.0.0.1]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j56E8R5J002582; Mon, 6 Jun 2005 07:08:27 -0700 (PDT)
Received: (from majordom@localhost) by darkwing.uoregon.edu (8.13.4/8.13.4/Submit) id j56E8ROW002578; Mon, 6 Jun 2005 07:08:27 -0700 (PDT)
Received: from newdev.harvard.edu (newdev.eecs.harvard.edu [140.247.60.212]) by darkwing.uoregon.edu (8.13.4/8.13.4) with ESMTP id j56E8Quq002482 for <newtrk@lists.uoregon.edu>; Mon, 6 Jun 2005 07:08:26 -0700 (PDT)
Received: by newdev.harvard.edu (Postfix, from userid 501) id EBC5937688C; Mon, 6 Jun 2005 10:08:20 -0400 (EDT)
To: newtrk@lists.uoregon.edu
Subject: [newtrk] pepost - IESG comments on ISDs
Message-Id: <20050606140820.EBC5937688C@newdev.harvard.edu>
Date: Mon, 06 Jun 2005 10:08:20 -0400
From: sob@harvard.edu
Sender: owner-newtrk@lists.uoregon.edu
Precedence: bulk
Reply-To: sob@harvard.edu
just so that its easier to find - here is a repost of the IESG comments on the ISD proposal - please do not respond to this as a whole - I'll send a series of targeted messages on parts of it ------ sent by Brian E Carpenter Tue, 10 May 2005 09:51:44 +0200 ------ The IESG discussed the ISD proposal at some length during its recent retreat meeting. The short summary is that the IESG understands several problems that the ISD proposal seems to be trying to solve but believes the proposal is not sufficiently clear about what problem is being solved and has issues with the proposed solution. However, to be constructive, the IESG wants to discuss possible ways forward to achieve some or all of the desired results. Assuming newtrk meets in Paris, IESG members will make a best effort to be present, and we assume there will be email discussion before then. Although we know the authors will disagree, several members expressed significant concerns that this proposal would increase the complexity of the standards process, would slow down the IETF's throughput and would not in the end be useful to implementers. Specifically, concern was expressed that determining the right granularity (e.g. how many ISDs would be needed to cover the SIP area, and how many SIP RFCs would be pointed to by multiple ISDs) would be very hard, and would lead to complexity and confusion when updates occur. Rather than clarifying and simplifying the "standards action" event, it would get more complex. Another concern that was expressed was that, except for trivial cases where an ISD is probably not needed anyway, experience (e.g. RFC 1812, draft-ietf-ipv6-node-requirements-11.txt) suggests that ISDs are likely to require major effort to produce. That effort is probably justified in some cases (as the cited examples show) but not for every single standards action. There was a general observation that what the IETF does well is write specifications, and maybe we should leave it at that, with the "market" choosing which to turn into de facto standards. Thus we are not sure if it is worthwhile to spend the necessary effort to turn the current ISD proposal into something that would in practice improve the standards process. If we choose to spend more effort on the ISD proposal in its present form, we should recognize that this will be a high-risk, high-cost approach and we may ultimately fail to produce something that works for the IETF community better than what we do today. However, there was a feeling that for complex or fundamental technologies (e.g. TCP, SMTP, SIP, IPSEC) there would be a clear benefit to the community to have documents of some kind that give appropriate guidance to implementers and operators. There are two directions we could take if we want to continue work on ISDs. The IESG believes it is important to pick one of these directions. There is internal disagreement within the IESG about which direction we should take. Some IESG members expressed objections to each approach; more discussion is needed to confirm that if an approach is taken the IESG can live with that approach. We'd like to have that dialog with newtrk. The first approach is to treat the ISDs as a light-weight replacement for the three-level standards track. The goal would be to make ISDs very simple; minimize text in the document and make an ISD little more than a collection of links and metadata. This would, in effect, give IETF blessing to the realities that the Internet runs mainly on Proposed Standards and that the STD series has failed as a citation series. The second approach would be to create some sort of document series for roadmap documents. The ISDs would focus on describing the documents that compose a standard and their interrelations. These ISDs would be fairly complicated to write--at least as complicated as existing roadmap documents. We do not believe that if ISDs are going to be roadmaps their approval should be linked to standards-action document approval. Also, we do not believe that if ISDs are roadmaps they should be required for all technologies; instead they should be used when appropriate. (This is orthogonal to the three-level standards track; that could be simplified independently, as implied by the newtrk charter.) We do not believe ISDs can fill both possible roles. We believe the current specification does not clearly state a goal and we believe that the lack of goal introduces significant ambiguity into the proposal. Regardless of what approach is taken, we need to consider the procedural implications of these changes. We believe that significant effort needs to be put into thinking about how these changes will be automated. The only way to constantly improve the IETF's document throughput is to maximize automatic tools. Before any ISD proposal can be implemented, we need to understand how it would be implemented, how it would modify the existing automation tools, who would implement it and what the costs would be. This effort needs to be closely coordinated with the ISD proposal: while these details may not be appropriate to include in the ISD document we need to confirm implementation is possible while we can still make changes to the proposal. Brian for the IESG . newtrk resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/newtrk.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/newtrk/index.html