Re: WG Review: Domain Keys Identified Mail (dkim)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]