On Wed May 4 2005 11:18, Brian E Carpenter wrote: > Bruce Lilly wrote: > > One problem is that the IESG routinely sabotages development along > > That is, I think, an inappropriate choice of word. No offense intended, and it should not be construed as indicating volition, but I can't immediately think of another word that adequately describes the predictable and observed result: > > the Standards Track by disbanding WGs as soon as a PS is produced, > > leaving nobody to do the work necessary for advancement to Draft. > > Er, we don't terminate the people. Of course not. But RFC 2026 assigns the responsibility for documentation of the two fully interoperable, independent implementations required for advancement to Draft to the Working Group Chair (sect. 4.1.2, 3rd paragraph). It's unclear who would do that, along with the associated testing and production of a protocol action request after the Working Group has been disbanded. Moreover, Proposed Standards rarely include a concise, well- defined set of conformance criteria that would facilitate testing and production of the requisite documentation in the absence of a panel of experts such as the WG that devised the specification. It seems to me that if the IESG is going to disband WGs working on Standards Track documents prior to production of Draft (or movement to Historic), that it ought to ensure that there is such a set of criteria in Proposed Standards so that the testing and documentation can proceed in the absence of a panel of experts; but it has not done so. Otherwise, how can the IESG expect that there will be an advance? How will the IESG fulfill its obligations for RFC 2026 section 6.2 (last paragraph) obligations? If the answer to either question is "it cannot", then how would you describe the practice of disbanding WGs with neither a Draft Standard nor an objectively testable set of conformance criteria? It is a fact that after 24 months, former WG chairs move on to other responsibilities and/or interests, and Document Editors may be unwilling to approve errata and/or to provide clarification or other updates after a WG has been disbanded. Terminating the people isn't necessary; these facts of life have the same result, at least in some specific observed cases, and the 2418 provision for a dormant WG explicitly provides a mechanism to address those issues. When the IESG drags out the review schedule beyond the 24 month deadline, former WG Chairs and/or Editors may no longer recall details of WG discussions and decisions, exacerbating the problems. > And we have always been advised > by the community to avoid eternal WGs. I see no reason why a time limit could not be stated. RFC 2418 (section 4, first paragraph) explicitly provides for a WG to go dormant, rather than be disbanded, pending advancement along the Standards Track. As 2026 provides for explicit review at 24 months after Proposed, and at regular intervals thereafter, those would seem to be appropriate values for charter timeline milestones, with progress review and a decision re. rechartering as a means of implementing the 2026 review schedule (which hasn't been followed in practice). That's hardly "eternal"; at some point either full Standard status is reached and the WG can be disbanded as the ultimate goal of the Standards Track has been reached, or the WG can be rechartered to amend the specification in such as way as to permit advancement (e.g. if there is some unimplemented provision as noted in 2026 sect. 4.1.2 2nd paragraph) or for a brief period to produce a "move to Historic" document: > > Charters should probably explicitly provide for WG activity leading > > at least to Draft Standard (or to Historic if the necessary two > > independent implementations fail to develop within a reasonable time). > > That assumes we care about moving stuff to DS. That wasn't at all > obvious during the discussion of 2774 and is by no means obvious > in the newtrk discussions. We ought to care about the issues mentioned in 2026 sect. 4.1.2 for DS: demonstration of community interest and utility (two independent fully interoperable implementations), removal of unused or unimplemented features (cruft; as noted in the NEWTRK discussion, that removes potential security and interoperability loopholes), and clarification of the specification based on field experience. If we don't care about utility and community interest, it means that we're likely wasting effort on dead ends. If we don't care about security and interoperability, we're headed for serious trouble. And if we don't care about clear specifications, there's not much point in being an SDO. "The goal of the IETF is to make the Internet work better" -- the IETF Mission Statement, RFC 3935 -- certainly relates to utility and interest, as does its definition of "Relevant". The definition of "Quality" in the Mission Statement directly relates to the other points. 3774 notes (Introduction) that the comments started on the wgchairs mailing list. It is somewhat to be expected that some of those closely involved with the work believe that they have produced perfection (we certainly wouldn't want them to knowingly produce shoddy work); see slide 59, first bullet point of ftp://ftp.rfc-editor.org/in-notes/rfc-editor/tutorial62.pdf for example. Now if some of those closely involved in work believe that they produce perfection in one go, it's hardly surprising that they do not see value in the multi-step standards track. The history of specifications which have advanced to full Standard status clearly shows that there is in fact progressive modification as a specification progresses. The fact that there are errors in published Standards Track specifications (http://www.rfc-editor.org/errata.html) is another data point that indicates that specifications rarely emerge fully-baked and perfect. From such a wider perspective it seems clear that progression is valuable; maybe 3 stages isn't the right number (but I suspect that it's about right -- if anything, the DRUMS experience tells us that there is sometimes a need for a 4th stage (consolidation of extensions and amendments). In that specific case, the relevant Standards have been rewritten and published back at entry level (Proposed Standard), the WG has been disbanded, and after more than 4 years -- double the 24-month review period specified in RFC 2026 -- there is no Draft Standard for the core application protocols addressed. There are known errors in the Proposed Standard specifications, some documented; others remain unpublished and known to a small group (lower-case 'g'). Meanwhile, there have been still more extensions and amendments, with more apparently to come (depending on what happens with various drafts). Perhaps in another decade or two, these core protocols will have advanced to Standard again, by which time there will again be a large number of amendments and extensions, resulting in yet another cycle of consolidation and progression. I submit that the practices of prematurely disbanding WGs and then dragging out the review schedule are the primary causes of the lack of timeliness of production of Standards (and as a side note, there is no reason -- with a relevant issue and an active WG to do the work -- that progress cannot be made much faster; progression to Draft can occur in as little as 6 months, and to full Standard in another 4 months per 2026 section 6.2). There is also a degree of inconsistency in the way that revisited Standards are addressed; the rfc-index states that 821, a.k.a. STD 10, has been obsoleted by 2821 (a Proposed Standard); likewise for 822 (STD 11) and 2822. The std-index, however, still points to the earlier, supposedly obsoleted, RFCs. In other cases where a full Standard is being reformulated, the std-index (e.g. for STD 12) has a reserved placeholder. It's unclear why there is such an inconsistency, but there does seem to be some confusion about the effective status of 821, 822, 2821, and 2822. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf