(Re-posted to working group, with the complete original and an expanded response.)
Tim, On 3/10/2010 11:32 AM, Polk, William T. wrote: > Authors, > > While I am still reviewing documents for I have been thinking about an > alternative proposal to move dkim deployment forward. By making slight > revisions in the abstract and introduction indicating that this document is > not intended to be a stand alone specification, the errors of omission that > concern me become less important. Your note appears to be in response to my guess about the core concern you have. After one month of of blocking the discussion, and no response to the responses you were previously given, this the sort of change that you think is essential to prevent the "harm" that you cited in your Discuss? So, you think the word "considerations", in the Abstract, and "practical tips" and "organized around the key concepts", in the Introduction, might lead one to mistake the document as some sort of standalone, complete instructional missive? Is there perhaps a chance that you are carrying your concern for protecting the reader a bit too far, particularly for an Informational document and particularly since the document has had extensive review and you appear to be the first person confused about this? How does this justify a Discuss? As for the proposed title change, it too does not match the established practice that I've seen for other "deployment" RFCs, with no compelling benefit. d/ ps. why did you copy the SMTP working group? > P.S. The draft RFC Editor Note also proposes a tweak to the title. > I’ll admit the proposed title is way too long, and I think that is > less important than the changes to the Abstract and Introduction, but > it would help make it clear that more detail exists elsewhere. I > figured I’d throw it out there just in case... > > -----------draft RFC Editor Note---------- > > Title: > > OLD > DomainKeys Identified Mail (DKIM) Development, Deployment and Operations > NEW > Supplemental Development, Deployment and Operations Considerations for > DomainKeys Identified Mail (DKIM) > > In the Abstract: > > OLD > This document provides > implementation, deployment, operational and migration considerations > for DKIM. > NEW > This document supplements the DKIM overview and protocol > specifications with additional implementation, deployment, operational > and migration considerations. > > In the Introduction, insert the following as a new second sentence in the > first paragraph: > > This specification supplements initial guidance previously included in > [RFC4871], [RFC5585], [RFC5617], and [RFC5672]. > > The revised paragraph would read as follows: > DomainKeys Identified Mail (DKIM) allows an organization to claim > responsibility for transmitting a message, in a way that can be > validated by a recipient. This specification supplements initial > guidance previously included in [RFC4871], [RFC5585], [RFC5617], and > [RFC5672]. This document provides practical tips for: > those who are developing DKIM software, mailing list managers, > filtering strategies based on the output from DKIM verification, and > DNS servers; those who are deploying DKIM software, keys, mailing > list software, and migrating from DomainKeys [RFC4870]; and those who > are responsible for the on-going operations of an email > infrastructure that has deployed DKIM. > d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
