I'm getting the impression that this debate is starting to be about proving points rather than making progress. In the interest of getting this document moving forward, I have entered the following RFC editor note:
Please add a new paragraph to Section 1, after the first paragraph: The reader is encouraged to read the DKIM Service Overview document [RFC5585] before this document. More detailed guidance about DKIM and ADSP can also be found in the protocol specifications [RFC4871], [RFC5617], and [RFC5672]. Authors and Barry: if you think this is unacceptable, please yell ASAP and propose better text. Tim: unless you feel that the scope of this document is dangerously unclear even with this addition, please clear. Best regards, Pasi > -----Original Message----- > From: ext Dave CROCKER [mailto:[email protected]] > Sent: 11 March, 2010 01:59 > To: Polk, William T. > Cc: DKIM IETF WG; Eronen Pasi (Nokia-NRC/Helsinki); IESG; draft-ietf- > [email protected]; [email protected]; Sean Turner > Subject: Re: An alternative way forward for dkim-deployment... > > Tim, > > On 3/10/2010 3:18 PM, Polk, William T. wrote: > > Dave, > > > > First, I do think it is harmful when document content does not match > the > > (explicit or implied) scope. > > And since I quoted text that made clear that the scope was constrained, > what is > the problem? > > Again the question: just how much bullet-proofing against careless > reading is > required? > > > > I certainly had different expectations > > based on the title and introductory material. In retrospect, I should > > have brought my discuss up another level of abstraction but I > apparently > > got focused on the details (what was missing) instead of why it > mattered. > > And yet even your original and later notes detail lacked detail, since > there was > no way of knowing exactly what problem you were trying to address /or/ > what > would satisfy and you did not provide clarification. > > > > Personally, I would prefer to see this document expanded and either > > address the various topics that are covered elsewhere or explicitly > > reference the various bits of the DKIM overview and protocol specs > where > > the rest of this information resides. > > Since the document is loaded with citations, including the other DKIM > documents, > once again I have no idea what you mean. > > > > Is there a chance that I am carrying my concern for the reader too > far? > > Not only "too far". As two of my earlier responses suggested, > implementing > additional text in line in response to the concern you initially stated > a likely > downside, given the intended audience. It would have been helpful for > you to > address that point, over the last 5 weeks. > > > > Perhaps... If you assume that the reader has already consumed the > > protocol specs, then I am way off base. It certainly is not > surprising > > that the wg members weren't confused. I just don't make that > assumption. > > Again, the text I quoted you earlier today is rather pointed in > declaring the > role of this document as being to augment, rather than replace, other > documents. > > > > My concern for the reader is based on my perspective at NIST. > Deployment > > guidance is actually something we do here, and sometimes we may even > do > > it well. > > The IETF has some history here, too. RFCs with the word "deployment" > in them > date back to 1992. Interestingly, the first was about X.500 and X.400. > > In any event, your statement here suggests that you are relying on the > NIST > culture for your concern, rather than the IETF culture. > > > > However, they might use google to search on dkim and deployment > > and try to use this document. > > People "might" choose to do an infinite number of unreasonable things. > Taking a > document out of context is only one of them. We cannot protect against > every > unreasonable action by a reader. > > And, again, the document states its nature and goals explicitly. > > > > I don't like holding this document up, especially when there are a > > variety of simple solutions. > > To say "solution" is to take as a given that there is a problem. You > have not > responded to the responses that critique that assumption. > > > > It > > is clear this document will not evolve into "some sort of standalone, > > complete instructional missive" so let's be clear about the document > > scope, and move on. > > The document /is/ already clear Tim, per the text that I quoted. It > merely > needs the reader to be paying attention. > > d/ > -- > > Dave Crocker > Brandenburg InternetWorking > bbiw.net _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
