At 2:44 PM -0800 12/20/05, Dave Crocker wrote:
Ted,
implies the need to be clarify the charter in two ways. The charter
needs to reaffirm that the IETF has change control over the
We could choose to have every charter repeat every premise for all IETF work.
That would be wasteful, at best.
It's also a principle of good engineering that you don't make unnecessary
changes to deployed code. This working group charter sees a necessity
to repeat that position in the charter. That's fine by me. I think adding in
that it is the working group that decides when that necessity hits is a good
idea
in that case. That's not mistrust of anyone, it's ensuring that everyone,
including
those who join *after* this long, repeated charter development process
understand how that statement in the charter fits into the rest of our
assumptions.
Note that very similar language was in the XMPP charter
(http://www.ietf.org/html.charters/OLD/xmpp-charter.html), which had a
relationship
to the deployed jabber code:
Although not encouraged, non-backwards-compatible changes to the
basis specifications will be acceptable if the working group
determines that the changes are required to meet the group's
technical objectives and the group clearly documents the reasons for
making them.
I personally believe that clarity helped the XMPP working group and the jabber
community.
Having this point in this charter mostly serves as a statement of mistrust,
rather than providing any useful education or constraint.
charter also needs to indicate that the working group will consider
the relationship of this work to other, existing IETF technologies.
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.
I had hoped the sentences following the one you snipped were
clear, but apparently not. As Eric Rescorla has several times
pointed out
(http://www.educatedguesswork.org/movabletype/archives/2005/07/comments_on_dra.html),
the IETF has done work on message signing before,
and some of those earlier efforts (like CMS in detached signature mode) look
enough like pieces of DKIM that there is question of whether DKIM not using
them indicates that they do not work, that this message signing is
a better point solution, that this message signing mechanism would be
better over all, or none of the above.
Again, I'm not suggesting a change in what DKIM wants to do--I'm suggesting
the WG tell the IETF what, if anything, is wrong with the bits the IETF had
already
done. "Doesn't fit, here's why" would be one answer, and there are several
logical places to do it. I think that's pretty actionable, and that it would
be a
useful, timely contribution to the relevant area of Internet engineering.
regards,
Ted Hardie
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf