--On Monday, 22 May, 2006 11:03 -0700 Dave Crocker
<dhc2@xxxxxxxxxxxx> wrote:
>
>
> John C Klensin wrote:
>>> If they are not all operational notes, then the series should
>>> not be called operational notes.
>>
>> I can't speak for Harald or the IESG, but I would personally
>> welcome a constructive suggestion.
>
> Steering Group Administrative Notes (SGAN)
I could live with this (or, probably, any of a few dozen other
things).
>...
>> Regardless of that, in the IETF, the IETF doesn't really
>> approve anything. We can't, we don't vote. What we do is to
>> charge the
> > IESG with interpreting community consensus and making
> decisions
> > on behalf of the IETF based on that consensus.
>
> We do not do precise, objective measurements of the sort
> usually called voting, but we absolutely DO do community
> approval. The iterative working group rough consensus
> assessments, the working group last call, and the IETF last
> call are all used to formulate an aggregate assessment of
> community approval.
Agree so far, with the understanding that the IESG is, for these
sorts of matters, the body charged with evaluating and assessing
that approval. I also believe that there are cases in which it
is more rational for the IESG to take an action, publicize it,
and see if anyone complaints than to attempt to determine how
the community would react to that action in advance. I
suspect you might agree with that because the alternative leads
to paralysis. However, I presume we might disagree about the
boundary between the cases in which that is appropriate and
those in which it is not.
> One of the major power changes in the IETF has been treating
> IESG approval as something higher than community approval. It
> is precisely what empowers Area Directors to feel that they
> are the personal Keepers of Quality rather than (merely) the
> agents of the community. Most area directors are excellent at
> their technologies, but it really is a bit much to expect or
> require them to be superior to the collective wisdom of the
> community seeking to use the work being standardized.
We are in complete agreement on this subject, and I have tried
to write my comments in strict conformance with the notion of
the IETF as evaluator of community consensus, rather than that
of a higher or independent authority.
Moving the next few comments out of order, and deleting what I
think are side-discussions, for reasons that will be obvious...
>...
> In any event, I suspect the reason I am motivated to criticize
> the current proposal is that it is yet-another focus on
> creating a mechanism about form, rather than anything that has
> substantive relevance to timeliness or utility of IETF output.
> Certainly it is always a good thing, to rationalize a
> documentation process, but new mechanisms are expensive.
> Hence, not "low impact".
>
> Where we probably differ is in our view of the strategic cost
> of creating a mechanism that is secondary to the IETF's
> strategic problems.
Actually, probably not. Where I think we differ is that I see
three aspects of the status quo as problematic and
unsatisfactory. If I thought they were working well, I would
consider this proposal a waste of time and hence too costly to
be worth the investment in either change or even this
discussion. Those aspects are:
(i) Excessive time between determination of a procedural
change and formal publication of a document describing
the current (revised) policy and waste of RFC Editor
resources on documents that are not either technical or,
in the RFC sense, archival.
(ii) Excessive difficulty in determining what rules and
procedures actually apply as the reader tries to thread
RFCs and sections of RFCs together.
(iii) The current system provides an incentive, however
limited, for the IESG to decide on changes in procedural
details in private and then announce (or not) those
changes that encourages what appears to be a game of
"gotcha" with the community. I believe that IESG's
tendency to actually do this has been declining (after
some community outcry) but eliminating any procedural
characteristics that encourage it seems desirable.
In combination, I consider those three issues to be significant
enough to overcome the presumption that a new mechanism is, a
priori, simply not worth the trouble.
> In any event, the proposed mechanism is not burdened with the
> patina of community review and approval. This means that
> approval process solely subject to the desires of IESG.
> The name of the mechanism should make that distinction clear.
Ok. I now understand where we disagree. That is probably as
much progress as we can make and I, at least, will now leave
further discussion to others.
I am making two assumptions, which you may not share:
(1) We already have procedures that were approved solely subject
to the desires of the IESG (or the secretariat in combination
with the IESG). I believe that various format-checking tools,
the document historically called "id-nits", the I-D posting
deadlines prior to IETF meetings, the "two BOF" restriction and
exceptions to it, the rules about interim meetings, and so on,
all fall into that category, at least in the sense that the IESG
decided on and implemented them without benefit of WG process,
Last Call, or other mechanisms for formally determining
community consensus.
(2) For those documents that we have traditionally handled with
the full rituals, checks, and evidence of community consensus
that are normally associated with BCPs, the approval process
will not change. I believe for example, that were the IESG to
approve a significant change to RFC 2026 on its own initiative
without community exposure of the ideas and community consensus
on them, the action would be immediately followed by procedural
appeals and, potentially, group recalls or a general bloodbath.
Conversely, because the IESG ultimately makes the decision,
subject to community push-back, as to which documents and
procedures require BCP treatment and which ones can be handled
as in (1), we have the potential for that sort of pushback
today... as well as the demonstrated potential for the IESG to
simply ignore the rules.
Because of those two assumptions, I do not see this as a large
procedural change: abuses that can occur with the proposed
system can occur with the existing one. We have documents and
procedures that are approved strictly on the IESG's initiative
today: the proposed system doesn't make that worse and might
help by providing a centralized way to at least locate and
identify those procedures.
Now, one might also sensibly believe (although I do not) that
documents covered by that first assumption should not exist and
that everything should go to some process that permits formal
assessment of community consensus. But, if so, it seems to me
that the way to pursue that is not to worry about this document
but to clarify 2026 and various other procedural, charter, and
authority documents to prohibit IESG decisions of that point.
john
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf