Re: I-D ACTION:draft-alvestrand-ipod-01.txt

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]