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