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)
Whatever their source and whatever their focus, they are
approved by the IESG and not the IETF. They are roughly
equivalent to Presidential Executive Orders, in the U.S. That
is rather different from a law or constitutional amendment.
Since it is not relevant to this thread, I will skip making an
obvious comment about the present Administration and its
attitudes and behavior. But I would have chosen other analogies.
Any mechanism can be abused. For mechanisms involving people, the likelihood
that it will eventually happen is quite high, so it is important to deal with
that potential when designing the mechanism. It is one of the reasons that it
is important to have the mechanism make clear what its basis of authority is.
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.
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.
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.
Now, as I read the I-D, it isn't intended to have any procedural
impact at all.
That hardly seems possible, given the scope and content of the documents
intended for the series.
And I continue to be a little surprised that we are disagreeing
about this one: mutual teasing notwithstanding, I'm usually
reasonably good at predicting where we will disagree, and would
not have predicted this one.
If our agreeing were entirely predictable, it would cease to be "interesting"...
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.
d/
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf