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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf