On 05/04/2011 09:15 AM, Murray S. Kucherawy wrote: >> -----Original Message----- >> From: Michael Thomas [mailto:m...@mtcc.com] >> Sent: Wednesday, May 04, 2011 9:03 AM >> To: Murray S. Kucherawy >> Cc: Rolf E. Sonneveld; dcroc...@bbiw.net; ietf-dkim@mipassoc.org >> Subject: Re: [ietf-dkim] Output summary - proposing ODID "Originating Domain >> Identity" >> >> My sense is that what Rolf is asking at its base is that the there is >> a conflict between the two documents and it's not clear why they >> exist, and which should be believed. If 4686 is inconsistent, then >> we should make a case for why it's wrong and document that. It >> may be process-wise "informational", but it served at the time as >> a guiding document for the creation of 4871, and had working >> group consensus at a time of extremely high scrutiny. We do not >> have anywhere close to that level of scrutiny now, and as such >> any changes made should be viewed with a very high level of >> caution and scepticism. >> > My read is that Rolf is objecting to RFC4871bis on the grounds that it > conflicts with RFC4686. (He can and should correct me if I'm wrong.) > > If his concerns would be satisfied by a change (perhaps an appendix?) that > simply acknowledges some evolution in thinking based on experience since > RFC4686 was published, I imagine that wouldn't meet with much resistance. > > But if the point is to use RFC4686 to compel some change in something trying > to get to DS (or even PS), that's a non-starter. >
"Compel" and "non-starter" are not helpful. Everything past publication of 4871 should be viewed in the light that fewer and fewer people were paying attention. The set of people paying attention now are extremely few, and many of them have self-interest in revisiting and/or changing the previous consensus -- taking advantage of the much smaller set of participants. Not that 4686 and 4871 are some sort of ideal residing in a platonic cave, but they do have the virtue that they were widely reviewed and in the case of 4871, implemented. We risk screwing things up with every edit; the law of unintended consequences isn't being given the respect it deserves. Mike _______________________________________________ NOTE WELL: This list operates according to http://mipassoc.org/dkim/ietf-list-rules.html
