Thanks Pasi, FWIW, I think Pasi's suggestion moves us forward nicely so I'd be happy to see us agree to do that.
Stephen. On 03/11/2010 10:30 AM, [email protected] wrote: > 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
