--On Friday, 08 September, 2006 22:09 -0700 "C. M. Heard"
<heard@xxxxxxxxx> wrote:
> On Fri, 8 Sep 2006, John C Klensin wrote:
>> --On Thursday, 07 September, 2006 20:11 -0400 Sam Hartman
>> wrote:
>> > OK. I read RFC 2026 as giving the IESG the latitude to
>> > make a judgment of the technical quality of a protocol (and
>> > the TS) when advancing along the standards track. I'd
>> > always assumed that the IESG should include factors like
>> > security in that determination--not just interoperability.
>> > Heck, I even assumed it was reasonable to have a higher bar
>> > for spec clarity at DS than PS.
>>
>> I think both of those (spec quality and factors like security)
>> are useful and important. But 2026 seems very clear on this
>> subject:
>>
>> > 4.1.2 Draft Standard
>> >
>> > A specification from which at least two independent and
>> > interoperable implementations from different code bases
>> > have been developed, and for which sufficient successful
>> > operational experience has been obtained, may be elevated
>> > to the "Draft Standard" level. For the purposes of this
>> > section, "interoperable" means to be functionally
>> > equivalent or interchangeable components of the system or
>> > process in which they are used.
>> > [...] Elevation to
>> > Draft Standard is a major advance in status, indicating a
>> > strong belief that the specification is mature and will
>> > be useful.
> [ ... ]
>> If the documents meet the published requirements for Draft,
>> then they should be published at Draft.
>>
>> The recent practice in the IESG appears to have been closer to
>> "if we don't like it or would not recommend it, it should not
>> be published at all, especially on the standards track no
>> matter how widely interoperable implementations are
>> deployed". I can find little support for that position in
>> RFC 2026 or elsewhere.
>
> I think that Mr Hartman is right and that Mr Klensin is
> mistaken.
I don't think this is even a question of right or wrong
(mistaken), but of interpretation and appropriateness. There
are also some issues about when the exercise of judgment and
discretion turns into either abuse of process or substituting
IESG judgment for the judgment or the community or that of the
marketplace. I am also trying to suggest that, where these
sections of 2026 to be reopened, there might be pressures to
narrow IESG authority in addition to those for broadening it,
and for reasons exactly connected to those issues about the
appropriate range of discretion.
I note that, in the middle of the "decruft" process, at least
two proposals were introduced (one less formally than the other)
to require giving more weight to marketplace decisions, rather
than IESG judgment, in determining which specifications were
advanced. Those proposals were not debated and rejected by the
community. Instead, they simply disappeared after it became
clear that the IESG would not be receptive to any reduction of
the authority of their opinions. That may have been the right
decision, but the community never had a chance to make it.
> As I read it, section 6 of RFC 2026 not only gives the IESG the
> latitude to make a judgment of the technical quality of a
> specification when advancing it along the standards track, but
> actually REQUIRES the IESG to do so:
>
> |6. THE INTERNET STANDARDS PROCESS
> |
> | The mechanics of the Internet Standards Process involve
> decisions of | the IESG concerning the elevation of a
> specification onto the | standards track or the movement of
> a standards-track specification | from one maturity level to
> another. Although a number of reasonably | objective
> criteria (described below and in section 4) are available |
> to guide the IESG in making a decision to move a specification
> onto, | along, or off the standards track, there is no
> algorithmic guarantee | of elevation to or progression along
> the standards track for any | specification. The
> experienced collective judgment of the IESG | concerning the
> technical quality of a specification proposed for |
> elevation to or advancement in the standards track is an
> essential | component of the decision-making process.
> ...
>From my point of view, we have two issues here. The first is
that I see the IESG as the interpreter of community consensus
rather than as an authority in itself. This text sounds
remarkably like "self-sufficient authority". I don't believe
that was the community's intent when 2026 was written. More
important, as time goes on and the composition of the IESG and
the community of active IETF participants shifts, I think it has
become less appropriate.
The second is a meta-issue about what the above means by
"technical quality". Certainly the clarity of the specification
is a key issue (and is is, as you point out, called out in
6.1.2). But our traditional tool for both evaluating and
refining document quality is independent interoperable
implementations. While documents can always be improved, if
such implementations were created without difficulties, that
should create a strong presumption that the document is clear
enough.
Of course, there are other issues in technical quality. A
protocol that simply won't do the job claimed for it should have
either the protocol or the claim adjusted before publication. A
protocol that might be harmful to the Internet generally should
either be rejected or published with appropriate explanation,
warnings, and disclaimers.
Where I'm probably out near the fringe of the IETF community is
that, after more than three decades of involvement in
standardization efforts of several types, I've gotten very
skeptical of the impact of a standards-producing body approving
some things and not others on the basis of how they feel about
them. I am very much in favor of high specification quality. I
am also in favor of avoiding putting the label "standard" on
something until after it is proven to be implementable and
feasible. But, ultimately, the marketplace will do what it
does and the primary contribution of a standardization effort is
not to approve or disapprove, but to increase the odds that, (i)
if two implementers or organizations want to do the same thing,
they have the opportunity to do it in a compatible and
interoperable way and (ii) if a procuring organization doesn't
want to be limited to a single source, they have a better
opportunity to specify what they are looking for in a way that
will encourage competition.
>From that point of view, we should aspire to specifications that
are absolutely clear about their strengths and weaknesses
_especially_ where security and basic network operations (e.g.,
scalability) are concerned. But, once those specifications are
clear enough (for a given level), I think we should publish
them, ideally with indications of both maturity and how much we
think they are good ideas. I expect that the marketplace will
take "maturity" more seriously than recommendation levels, but
that is another issue. And, if the marketplace responds by
implementing and deploying something widely, even if the IESG
thinks it is a terrible idea, I think we have some level of
obligation to improve the specification (including better
explanations about what it terrible about it if those are
appropriate), and publish the result... on the standards track
in order to continue to facilitate interoperability.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf