> > > > 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. > > > > I'd like to see us go straight to a 4871bis (option 2). The extra > editorial effort involved in merging the versions seems well worth it, > to have a single normative document for DKIM signatures. > > The question that I still have is whether this 4871bis document would be > limited to "erratum" sorts of changes. There has been a significant > amount of deployment experience since 4871 was published, and IMO it > would be beneficial to address that as well. No, I don't have anything > particular in mind; I'm just trying to understand the ground rules. Or > would the deployment experience be incorporated into 4871ter that you > refer to? > > I don't have any experience with the types of changes that would be > allowed in 4871 and still progress the next revision to Draft Standard. > I realize that is important to many, but I'm more interested in getting > the spec right than whether it's PS or DS. >
While I'm not at all opposed to doing a -bis document, I think that a number of people are vastly underestimating the time required to take one to completion. My preference would be to declare consensus for the Errata document, and then work the contents from that document and any other relevant errata into a more polished -bis document. (I haven't been around for a whole lot of ietf votes, but 2/3 sure sounds about as close as a working group is likely to get towards consensus on issues like these.) That approach gets the gist of the Errata clarifications out in a much more timely manner (i.e., almost immediately), and does not preclude the generation of the -bis document as rapidly as the process allows. Ellen ------------------ Ellen Siegel Constant Contact _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
