[ietf-dkim] Handling the errata after the consensus call

[Hector Santos]

DKIM Chair wrote:

> 1. Include the other errata into Dave's draft, leave the whole thing as "old text 
> / new text" format, and put it out as an RFC that updates 4871.  There would be 
> no rev of 4871, and implementors would need to use both documents.  Work on 
> 4871-bis from there.
>
> 2. Include the other errata and Dave's draft into a 4871-bis, which would 
> obsolete 4871 and make sure that implementors get the right version.  Nothing 
> would go out as "old / new"; the merged document would be a rev of 4871.  Work on 
> 4871-ter from there.

Personally, I am not all familiar with procedure, but from a marketing 
standpoint, I would like to suggest that if Dave's errata is going go 
forward, that an abstract be updated to include an executive summary 
of what is the key/fundamental changes and if possible, the effects 
and repercussions. i.e. don't force people to read deep into the 
errata to find out if any of this matters and/or applies to them.

> Then there's the question of where ADSP stands, and whether it can proceed as is, 
> or needs to be changed in light of the "errata".  Pasi may have some comments on 
> this, and I know the working group will.  We've been holding ADSP up for a while, 
> and we need to release it and move it forward.

+1.  This is our own holdup on moving forward with DKIM.

I just to make a final statement here to reiterate I think the #1 
benefit is exclusive signings (where I believe the highest payoff will 
be with private domains), and ADSP will offer some assistance in this 
area.  ADSP will allow us to provide the technical selling and 
incentive, a reason to explore DKIM to our customers.

Thanks

--
Hector Santos
http://www.santronics.com