ietf-dkim
[Top] [All Lists]

Re: [ietf-dkim] An alternative way forward for dkim-deployment...

2010-03-11 08:53:43

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, Pasi(_dot_)Eronen(_at_)nokia(_dot_)com 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:dhc(_at_)dcrocker(_dot_)net]
Sent: 11 March, 2010 01:59
To: Polk, William T.
Cc: DKIM IETF WG; Eronen Pasi (Nokia-NRC/Helsinki); IESG; draft-ietf-
dkim-deployment(_at_)tools(_dot_)ietf(_dot_)org; 
dkim-chairs(_at_)tools(_dot_)ietf(_dot_)org; 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