At 2:44 PM -0800 12/20/05, Dave Crocker wrote:
The charter
needs to reaffirm that the IETF has change control over the
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. We certainly saw this in
the Atompub WG, and it seems likely that you will see it in any WG
relating to spam. Adding this type of wording to charters of WGs
which come with existing protocols helps set the expectations of the
participants and therefore could help the WG act more gracefully.
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.
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.
The same reasoning above applies here. Having people whose sole
involvement with the IETF is one new WG know that there is an
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 own", or "why did you pick this standards-track
technology over that standards-track technology", are asked.
Having these things in the charter reduces the strain on the chairs
when the issues come up in the WG.
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
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.
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. Having such language would
have made it harder to get them in the final spec, and therefore
would have degraded the quality of the WG's output.
--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf