Eric Rescorla wrote:
Since experimentation resulted in significant Internet deployment
of these specifications, the DKIM working group will make every
reasonable attempt to keep changes compatible with what is
deployed, making incompatible changes only when they are necessary
for the success of the specifications.
As I argued on the DKIM working group list, I think this text is a bad
idea. Part of IETF having change control of a specification is having
the ability to make changes, and the bar of "necessary to the success of
the specification" is way too high for that. Note that I'm not
suggesting that the WG shouldn't consider compatibility, merely that it
shouldn't be effectively prohibited by charter from making incompatible
improvements.
I hear you, Eric, and, yes, we've all discussed this at length before.
There are people with opinions at both extremes on this (from "we must
leave that paragraph unchanged" to "we must remove that paragraph
completely"). For my part, as the current editor of the charter, I'm
happy with a change in the text if we can get consensus on some text
that will make both sides at least somewhat happy (or perhaps I should
say "somewhat less unhappy"). We weren't able to do that on the ietf-dkim
list before the BOF. Let's try to spend a little time doing that now
(keeping in mind the realities of the IETF process, and that the charter
can not bypass that process, nor is it trying to). We have more eyes
and more fingers now, and perhaps someone new can craft text that will
work.
Experience in this area (anti-spam-related things) shows us that we DO
need strong guidelines to stay on track, and I believe that weakening the
wording too much does not provide us with those guidelines. As I said in
in my other post, just sent, it's really the job of the WG chairs to deal
with this. Still, strong guidelines make it easier for the chairs to do
their jobs efficiently, and for the ADs to handle escalations effectively.
Can someone propose an alternative to the first-quoted paragraph above,
from the proposed charter, that keeps the sense that the specifications
we're agreeing to use as a starting point be strong conflict-resolution
guides, and that they be used to steer the discussion... without making
it seem, incorrectly, that the WG is not willing to accept changes that
make sense to make?
Barry
--
Barry Leiba, Pervasive Computing Technology (leiba@xxxxxxxxxxxxxx)
http://www.research.ibm.com/people/l/leiba
http://www.research.ibm.com/spam
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf