Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

ssaging Engineer Cox Communications, Inc 404-847-6397 -Original Message- From: ietf-dkim-boun...@mipassoc.org [mailto:ietf-dkim-boun...@mipassoc.org] On Behalf Of Michael Thomas Sent: Friday, March 20, 2009 9:39 PM To: John R. Levine Cc: ietf-dkim@mipassoc.org Subject: Re: [ietf-dkim] Moving to con

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

Jim Fenton wrote: > 1. Introduction. The introduction, particularly paragraphs 2 and 3, assert > that the payload (the output of DKIM verification) is only a validated > signing domain. The output of DKIM verification is considerably more than > that: The Errata draft carefully documents the b

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

Hi Eliot, At 00:30 22-03-2009, Eliot Lear wrote: >This would be reaching goals for the sake of reaching goals. I >would note that an update isn't in the charter at all. I'm not >saying don't do it. I'm saying that I would rather Without goals, we don't have a clear path stating what we want t

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

SM, all, > It > would be better for the DKIM WG to meet its goals before starting a > discussion about Draft Standard. > This would be reaching goals for the sake of reaching goals. I would note that an update isn't in the charter at all. I'm not saying don't do it. I'm saying that I wou

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

At 13:42 20-03-2009, Barry Leiba wrote: >What path we take to publish the errata beyond the ID that it is now, >and whether the WG is behind publishing it without Pasi's (or the >IESG's) approval, are things we'll be discussing in San Francisco and >on the mailing list. I hope that when we leave S

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

John Levine wrote: >> The output of DKIM verification is considerably more than that: >> there are a great many values, such as the list of signed header >> fields, that may be useful to an assessor and that must be made >> available to the assessor if the verifier is to be as interoperable >> with

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

On 3/20/09, Michael Thomas wrote: > John R. Levine wrote: >> Assessors know whether a message is signed, and if it has valid >> signature(s), the domain(s) that signed them. All that other stuff in the >> signature is implementation details. > > RFC 4871 gives no precise definition of what an "a

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

> If assessors can't be bothered to assess the supposedly "self-limiting" > "implementation details", then reputation systems can not take them into > account. By definition. Right. That's a feature. It's not my job to work around or even identify crappy signatures. If there's junk in your s

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

John R. Levine wrote: >>> We seem to have a fairly basic disconnect here. As far as I'm >>> concerned, an assessor has better things to worry about than the >>> internal details of the signature. Trying to reverse engineer or guess >>> what the signer had in mind would be a hopeless swamp even if

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

>> We seem to have a fairly basic disconnect here. As far as I'm >> concerned, an assessor has better things to worry about than the >> internal details of the signature. Trying to reverse engineer or guess >> what the signer had in mind would be a hopeless swamp even if it were >> desirable. ...

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

John Levine wrote: >> The output of DKIM verification is considerably more than that: >> there are a great many values, such as the list of signed header >> fields, that may be useful to an assessor and that must be made >> available to the assessor if the verifier is to be as interoperable >> with

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

> The output of DKIM verification is considerably more than that: > there are a great many values, such as the list of signed header > fields, that may be useful to an assessor and that must be made > available to the assessor if the verifier is to be as interoperable > with as many assessors as po

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

On Fri, 20 Mar 2009 16:42:30 -0400 Barry Leiba wrote: >Mike says... >> Dave CROCKER wrote: > Based on Pasi's comments, I had thought we were going the RFC route. >>> >>> Well, he has a preference for /only/ going that route, but he can't >>> actually veto our issuing the Errata under the Errat

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

>> So while I'm on the cooperation and productivity bit >> To everyone: Please say what you mean calmly and clearly, so there's >> less chance of misunderstanding or the taking of offense where none >> was meant.  And please don't mean offense, either, of course.  "Digs", >> snarkiness, and pas

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

On March 10, 2009, I wrote: > DKIM Chair wrote: > >> To those who voted against draft-ietf-dkim-rfc4871-errata: given, now, that >> we >> will be using draft-ietf-dkim-rfc4871-errata to move forward, and the other >> choices are off the table, can you accept draft-ietf-dkim-rfc4871-errata as

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

Barry Leiba wrote: > So while I'm on the cooperation and productivity bit > To everyone: Please say what you mean calmly and clearly, so there's > less chance of misunderstanding or the taking of offense where none > was meant. And please don't mean offense, either, of course. "Digs", > sna

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

Barry Leiba wrote: > Mike says... >> Dave CROCKER wrote: > Based on Pasi's comments, I had thought we were going the RFC route. >>> Well, he has a preference for /only/ going that route, but he can't >>> actually veto our issuing the Errata under the Errata mechanism. Anyone can >>> post anyth

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

Mike says... > Dave CROCKER wrote: Based on Pasi's comments, I had thought we were going the RFC route. >> >> Well, he has a preference for /only/ going that route, but he can't >> actually veto our issuing the Errata under the Errata mechanism.  Anyone can >> post anything they want under the

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

c.org] On Behalf Of SM > Sent: Friday, March 20, 2009 2:39 PM > To: DKIM Mailing List > Subject: Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871- > errata > > At 09:41 20-03-2009, Siegel, Ellen wrote: > >OK, now I'm confused. Can someone define IETF rou

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

Dave CROCKER wrote: >>> Based on Pasi's comments, I had thought we were going the RFC route. > > Well, he has a preference for /only/ going that route, but he can't actually > veto our issuing the Errata under the Errata mechanism. Anyone can post > anything they want under the Errata mechanism

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

At 09:41 20-03-2009, Siegel, Ellen wrote: >OK, now I'm confused. Can someone define IETF rough consensus? The errata had >a 2/3 majority after the last round of discussion... does the IETF >ever get a better >consensus than that? The Standards Process requires that a proposed standard be reviewed

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

On Mar 20, 2009, at 9:55 AM, Barry Leiba wrote: > > Pasi's point is that what you're quoting is from the DKIM working > group only, and, at that, only from some 20 participants or so. > There are a lot more people who participate in the IETF, and the > normal process of review by the IESG a

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

On Mar 19, 2009, at 11:22 PM, DKIM Chair wrote: > The chairs appreciate the view that the "errata" draft makes a lot > of changes. > Nevertheless, the view that those changes are too great... is quite > a minority > view. The only concrete objection we've seen in this latest round > is abo

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

Siegel, Ellen wrote: > OK, now I'm confused. Can someone define IETF rough consensus? The errata had > a 2/3 majority after the last round of discussion... does the IETF ever get a > better > consensus than that? There's a difference between "IETF rough consensus" versus "Working Group rough

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

DKIM Chair wrote: > Beyond that, I've seen no clear objections and no alternative text proposed. > Rough consensus appears to be with the "errata" draft, with the "AUID" change > made to it. So there it is. I've placed a revised draft errata at: which associates

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

From: ietf-dkim-boun...@mipassoc.org [ietf-dkim-boun...@mipassoc.org] On Behalf Of Jim Fenton [fen...@cisco.com] Sent: Friday, March 20, 2009 10:56 AM To: DKIM Chair Cc: DKIM Mailing List Subject: Re: [ietf-dkim] Moving to consensus on

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

> OK, now I'm confused. Can someone define IETF rough consensus? The errata had > a 2/3 majority after the last round of discussion... does the IETF ever get a > better > consensus than that? Pasi's point is that what you're quoting is from the DKIM working group only, and, at that, only from som

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

DKIM Chair wrote: > My apologies for the delay in this; I meant to send this early this week, > after > getting back in town, but... then I didn't get to it. > > The chairs appreciate the view that the "errata" draft makes a lot of > changes. > Nevertheless, the view that those changes are too

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

DKIM Chair wrote: > My apologies for the delay in this; I meant to send this early this week, > after > getting back in town, but... then I didn't get to it. > > The chairs appreciate the view that the "errata" draft makes a lot of > changes. > Nevertheless, the view that those changes are too

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

My apologies for the delay in this; I meant to send this early this week, after getting back in town, but... then I didn't get to it. The chairs appreciate the view that the "errata" draft makes a lot of changes. Nevertheless, the view that those changes are too great... is quite a minority vie

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

Folks, Two days later. Still haven't seen any other issues raised with the draft. d/ Dave CROCKER wrote: > Folks, > Question to the working group... > DKIM Chair wrote: >> To those who voted against draft-ietf-dkim-rfc4871-errata: given, now, that >> we >> will be using draft-ietf-dkim-rfc4871

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

Scott Kitterman wrote: > I won't propose any. I don't have time to do a proper job of rewriting it. > I think it alters > the IETF conensus view via errata and adds needless complexity. > > Silence or lack of change proposals does not equate to thinking the current > draft is good. +1 I t

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

On Wed, 11 Mar 2009 08:54:35 -0700 Dave CROCKER wrote: >Folks, > >Question to the working group... > > >DKIM Chair wrote: >> To those who voted against draft-ietf-dkim-rfc4871-errata: given, now, that we >> will be using draft-ietf-dkim-rfc4871-errata to move forward, and the other >> choices

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

Stephen Farrell wrote: >> Is that (editorial) work ongoing? > > I think it'd be great if Dave were willing to do that, but I could > understand if he'd rather not. I'm fine with continuing to edit the draft-ietf-dkim-rfc4871-errata for the working group. d/ -- Dave Crocker Brandenburg

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

Jim Fenton wrote: > Dave CROCKER wrote: >> Are there other changes to draft-ietf-dkim-rfc4871-errata being proposed? > > I believe the Chairs requested that the other, non-controversial, errata > be incorporated into this draft. Is that (editorial) work ongoing? No, they didn't: > DKIM Chair

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

Jim Fenton wrote: > Dave CROCKER wrote: >> Are there other changes to draft-ietf-dkim-rfc4871-errata being proposed? >> > > I believe the Chairs requested that the other, non-controversial, errata > be incorporated into this draft. I think we suggested it as an option rather than requested

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

Dave CROCKER wrote: > > Are there other changes to draft-ietf-dkim-rfc4871-errata being proposed? > I believe the Chairs requested that the other, non-controversial, errata be incorporated into this draft. Is that (editorial) work ongoing? -Jim ___

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

Dave CROCKER wrote: > > One of the tricks in choosing labels is to make sure they each have > useful meaning, but also that they are different enough to avoid > confusion. Labels are intended to have mnemonic benefit. [...] > >> User Agent Identifier (UAID) > ... >> the user or agent on behalf o

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

Folks, Question to the working group... DKIM Chair wrote: > To those who voted against draft-ietf-dkim-rfc4871-errata: given, now, that > we > will be using draft-ietf-dkim-rfc4871-errata to move forward, and the other > choices are off the table, can you accept draft-ietf-dkim-rfc4871-errata

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

Eliot Lear wrote: > As to the chair's request, FWIW I *have* given Dave suggested > changes, and I believe he has accepted some of them. I must admit > some confusion about the process at this point. It seems that there > is an outstanding request of Pasi about whether this draft can > proceed.

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

Dave, all, I think the problem isn't so much that you aren't being precise with UAID, but rather two fold: 1. UA has an existing connotation that people will grab onto. This in itself is mnemonically confusing. 2. If you're going to add acronyms, let them be ones that either can be easily p

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

Jim Fenton wrote: > I have a particular problem with the term "User Agent Identifier (UAID)" > because it doesn't necessarily represent a user agent -- it could, for > example, represent a mailing list manager. I greatly prefer the term > "signing identifier" (which replaces signing identity)

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

DKIM Chair wrote: > To those who voted against draft-ietf-dkim-rfc4871-errata: given, now, that > we > will be using draft-ietf-dkim-rfc4871-errata to move forward, and the other > choices are off the table, can you accept draft-ietf-dkim-rfc4871-errata as > written? If not, will you post spec

Re: [ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

> I can do that, but it will probably take a few days.  But for > clarification, is the new terminology cast in stone?  I have a > particular problem with the term "User Agent Identifier (UAID)" because > it doesn't necessarily represent a user agent -- it could, for example, > represent a mailing

[ietf-dkim] Moving to consensus on draft-ietf-dkim-rfc4871-errata

This thread has been split from Dave's long note. Here's what I want to try, in order to convert the "majority vote" into what Stephen and I would be happy to call "rough consensus". I have not discussed this yet with Stephen, in the interest of getting it out here more quickly, so he may fee