>Basically, email conversations encourage quick responses even in
>cases where quick responses are not useful. If one takes extra time
>to study the issue and form a more useful response, e.g. one that is
>more convincing or one that might further consensus, one risks that
>the list will have already formed an opinion on the issue and the
>opportunity for the response to be useful will have passed.
Correct. This is also a problem of the "rough consensus" being
evaluated by Chairs, when they actually consider more the humming
than the difference of positions.
>>In other words, this list prefers to discuss process rather than
>>perform useful work.
>Given the pattern stated above, it follows that process discussions
>will take more time to reach closure - or continue indefinitely -
>because there's inherently more speculation on process questions.
However, I feel this is tied to the RFC 3935 core values and rough
consensus system. I do not expect IETF to change them. The solution
would be for the IETF to better define their interoperability
obligations towards the SSDOs they leverage standards from. This is
in RFC 3935 but not really entered in the IETF culture.
>>Hence, my focus is entirely upon anything that will place less load on
>>the IESG, and therefore:
>
>Not that placing a lighter load on the IESG is a bad thing, but you
>said "Hence" and I don't see how one follows from the other.
>
>p.s. My conclusion from the above is that we need a better medium
>for conducting process discussions over the network, or better tools
>for conducting discussions over email. But of course that's a
>research topic and therefore this message is unlikely to be persuasive.
Correct. We faced that problem at the GNSO/WG Review. I documented
the solution we came with ("positions links") and I experimented
positively on some lists. It really helps concerted consensus,
decreases mail traffic, and keeps the mailing list system intact.
In reforming RFC 3683 we have to be careful not to replace it by a
stronger incitement to start "IETF wars" when someone opposes a lobby
using the IETF to support their own strategy/exclusive. My weak to
strong strategy made me to win the consensus I wanted. RFC 3683 was
used aferward to prevent I would continue for the further texts to
come. It also wad to confuse the IESG enough so it would not respect
the published consensual text without any technical rationale being
discussed. It mad the IESG to actually interfered within the
consensus building process of a WG at the call of the "losing" party
(I do not think there should be a losing party in a consensus, but my
opponents felt there should).
I think this is not good.
jfc
_______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf