We have had three proposal for some text on changes to prior work, the
current proposed charter, the text from the XMPP charter, and the text Keith
provided below.
The question that I think IESG should be asking themselves is how is this
similar and/or different from other groups the have charter
On Thu, Dec 22, 2005 at 07:22:52AM +0100, Frank Ellermann allegedly wrote:
> Arvel Hathcock wrote:
>
> > the list of domains running DKIM is over 35. I'll exceed
> > your "< 100" by the time I'm done writing this message.
>
> That's fine, and as we know about 1,000,000 domains and 10
> independe
Arvel Hathcock wrote:
> the list of domains running DKIM is over 35. I'll exceed
> your "< 100" by the time I'm done writing this message.
That's fine, and as we know about 1,000,000 domains and 10
independent interoperable implementations are good enough
for "experimental". 3 steps or 4 steps
Dave Crocker wrote:
and now the chairs quickly concede the change, even before getting
support from the rest of the group.
'scuse me; it seemed to me that Tony Hansen and Jim Fenton counted as
some of the rest of the group. It also seems to me that no one has made
me the boss, so what I sugges
On Dec 21, 2005, at 9:39 PM, Arvel Hathcock wrote:
Although I also agree with Jim (and others) that the XMPP text is
just about
the same as our existing text, watching these events unfold has
drawn into
question my understanding of the rules so I need some clarification
(sorry,
I'm a newb
So they re-assert their concerns again during the IETF charter last call,
and now the chairs quickly concede the change, even before getting support
from the rest of the group.
Although I also agree with Jim (and others) that the XMPP text is just about
the same as our existing text, watching th
Here is rough idea as how a recognition scheme could be implemented.
http://www.sonic.net/~dougotis/id/draft-otis-dkim-options-00.txt
http://www.sonic.net/~dougotis/id/draft-otis-dkim-options-00.html
Although this appears to be more complex, there should be
significantly less overhead associat
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 agre
Fellow DKIMers,
Barry Leiba wrote:
> I suggest that the IESG replace that paragraph in the proposed DKIM
> charter with the paragraph above, and that we move on from this topic
> to any others that need to be dealt with.
Well, I guess no one else is concerned about the sequence that has just
t
Ted Hardie wrote:
I would be happy with the text that was used in the xmpp charter:
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
I'll stand by the figure that number of sites sending DKIM email is < 100
Go ahead and do that then but know this: 10 minutes ago I sent out an email
to a 200 count sampling of my customer base asking "who's using DKIM". So
far, I've received 2 responses and already the list of domains runni
Ted Hardie wrote:
At 9:07 AM -0500 12/21/05, Tony Hansen wrote:
I would be happy with the text that was used in the xmpp charter:
Although not encouraged, non-backwards-compatible changes to the
basis specifications will be acceptable if the working group
determines t
On Wed, 21 Dec 2005, Arvel Hathcock wrote:
There is no wide deployment of DKIM. What is there are several test
machines on the order of couple dozen.
Either the person who made that statement is visiting all our customer
sites and uninstalling / reconfiguring our software or this is evidence
Jim,
Today I'll publish a rough-cut draft for the recognition options that
have been suggested. Here is a quick review of your threat summary.
1.1. Terminology and Model
It would be better to put a place holder for the signer-practices
query as well. An alternative to an authorization
On Wed, Dec 21, 2005 at 03:38:26PM -0600, Arvel Hathcock allegedly wrote:
> > There is no wide deployment of DKIM. What is there are several test
> > machines on the order of couple dozen.
>
> Either the person who made that statement is visiting all our customer sites
> and uninstalling / recon
There is no wide deployment of DKIM. What is there are several test
machines on the order of couple dozen.
Either the person who made that statement is visiting all our customer sites
and uninstalling / reconfiguring our software or this is evidence of the
ignorance of the speaker on the topic
> It's a significant precedent that IETF charters have included language
> of this sort when there has been a deployed base at the time the WG is
> chartered. But can someone explain what's different in this wording
> that warrants departing from the version on which there seems to be
> rough cons
> >> 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.
Dave,
You keep making statements like that without a sh
> 1. As interesting as such a discussion might be, it has no effect on the
> technical work. The choices made were the choices made. The goal is to
> make as few new ones as we can, not to spent time reviewing past
> choices.
That is almost never an appropriate goal for an IETF working group
crea
> It's also a principle of good engineering that you don't make unnecessary
> changes to deployed code.
I think that's an overgeneralization. There's neither a wide enough
deployment of DKIM, nor sufficient evidence of DKIM's suitability for
the diverse user community, for the current DKIM spec
> > >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 suc
A new revision of the DKIM threats document is now available. New in
this revision:
o Reorganized description of bad actors.
o Greatly expanded description of attacks against DKIM and SSP.
o Added "derived requirements" section.
If anyone wants the HTML version to read, you can get it
On Wed, 21 Dec 2005, Harald Tveit Alvestrand wrote:
--On onsdag, desember 21, 2005 05:36:08 -0800 "william(at)elan.net"
<[EMAIL PROTECTED]> wrote:
I also think that if allowed to be presented alternatives to putting
public keys in DNS, those would technically be found superior and less
damag
--On onsdag, desember 21, 2005 05:36:08 -0800 "william(at)elan.net"
<[EMAIL PROTECTED]> wrote:
I also think that if allowed to be presented alternatives to putting
public keys in DNS, those would technically be found superior and less
damaging to internet. Other aspects of proposal also had
John,
As I am sure you will recall, I've been very concerned since you
first proposed this about the notion of a WG that starts on the
assumption that almost all of the work is done and proven in the
field and that the IETF's role is limited to fine-tuning that
really does not change anything...
On Wed, 21 Dec 2005, John C Klensin wrote:
(i) you are obligated to demonstrate that sufficient
production-level deployment actually exists to justify
such a request and that it has been successful in
There is no wide deployment of DKIM. What is there are several test
Ted,
Ted Hardie wrote:
I believe the text here:
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
27 matches
Mail list logo
