|
Re: WG Review: Domain Keys Identified Mail (dkim)
2005-12-20 19:51:59
Having this point in this charter mostly serves as a statement of
mistrust, rather than providing any useful education or constraint.
Fully disagree. There is plenty of recent evidence that WGs that are
formed around "charged" issues attract lots of active interest from
people who do not understand the IETF rules.
>
> Adding such a statement is all about education. It is perfectly
> reasonable to not trust that newcomers will understand IETF policy;
> heck, many folks who have been active for years don't.
1. You said you disagreed, but then provided an argument for not
trusting participants ("people who do not understand the IETF rules".)
2. You cannot seriously think that adding the language Ted suggests --
he *did* suggest specific language, didn't he? I've lost track -- will
make any difference to the working group process.
3. Adding such language is not a remedy for bad working group management
or participation, yet that is exactly what Ted and you seem to be
targeting. Since it does not target technical details of the work to be
specified -- remember you said "education" -- that means that we now
need to make charters bullet-proofed against an essentially infinite
range of misunderstandings, as well as presuming that participants are
not to be held responsible for reading basic IETF materials. But then
why should they be held responsible for charter contents?
Again, a nicely open-ended and universal requirement that applies to
all working groups. It is therefore meaningless, except for its
implicit threat at more overhead and undefined requirements to satisfy.
The same reasoning above applies here. Having people whose sole
involvement with the IETF is one new WG know that there is an
You are attempting to impose a new requirement for a charter, namely
that it be bullet-proofed against ignorant participants.
That sounds like an interesting item to pursue in the IETF process
enhancement discussions, because the expectation of such content in a
charter is not specified in any current IETF process documents.
expectation that some research will be done will hopefully reduce
tensions during IETF Last Call and IESG review when questions like "why
didn't you use this standards-track technology instead of inventing your
1. The question has been discussed and explained at length on the
mailing list, the two BOFs, and elsewhere, for the last year.
2. You are presuming that it is reasonable for someone to come in at the
end of a working group and require a defense of the initial position of
the work. Since such a question belongs at the beginning of the process
-- assuming that anyone has noticed that this work continues existing
work rather than creates new work -- it is not productive to have such
basic challenges lodged at the end of the process.
Having these things in the charter reduces the strain on the chairs when
the issues come up in the WG.
What wording changes, specifically do you believe will 'reduce the
strain on the chairs' for this particular working group?
Please provide examples of similar language having had similar benefit.
Again note that you seem to be arguing for charter language that does
not target specific technical work but, instead, seems to have some
other goal relating to difficult participants. (This is as opposed to
language that targets technical work in a way that constrains such
difficult people.) Remember that Ted has already acknowledged that he
is not seeking any change in the actual technical work of the group. He
is, therefore, merely seeking to burden the wording group with an
additional task that has nothing to do with the direct work at hand.
At 5:04 PM -0800 12/20/05, 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
And Eric seem to keep ignoring, the question of how much change to
target, when taking in existing technology, is an established point that
has been experienced a number of times already. Different choices have
been made. Those seeking to field DKIM have reached a consensus on
charter language that reflect their choice for this case. (In other
words, Eric, rough consensus has been established on this issue.)
The impression, at this point, is that those seeking to remove all
limits on the technical changes in fact have no interest in protecting
the existing work.
In that light, the folks who developed DKIM would be quite seriously
crazy to hand it over to the IETF.
the specification" is way too high for that.
Too high for what? Instead of arguing principles Eric, needs to
indicate what specific technical work that is excluded by this language
is actually essential to the goals of DKIM.
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.
And that is exactly what has been debated (and resolved) repeatedly over
the last 5 months.
It is fortunate that the Atompub WG didn't have language like this in
our charter, because we made many improvements from the widely-deployed,
pre-IETF Atom 0.3 spec.
And presumably that was the choice of those forming the working group,
doing the work, and/or planning to deploy the result. In the case of
DKIM, the decision came down in a different place.
d/
--
Dave Crocker
Brandenburg InternetWorking
+1.408.246.8253
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
|
|