Barry Leiba wrote:
Eliot Lear said the following:
By my recollection,
this topic alone has been discussed at at least two - and possibly three
- working group meetings. Please advise.
This topic has definitely been discussed a number of times.
The focus of my note wason the contents of the specification, not on previous
discussion.
I'll repeat that distinction: The current draft does not deal with exact-name
vs. sub-tree issues as an explicit point of distinction; it has bits of each
scattered around. As such, the specification is, at best, confusing on the
distinction, nevermind incomplete on the tree construct.
But with respect to the working group's history of discussing this topic I'll
first thank Eliot for citing the recently-closed Issue. It was quite
instructive to go back and read the associated mailing list thread.
I strongly encourage others also to do read that thread
<http://mipassoc.org/pipermail/ietf-dkim/2006q4/006377.html>
since I think it substantiates my concerns, rather than resolves them:
1. The cited thread shows a complete lack of anything one might call
consensus.
2. The cited thread pretty much shows a complete lack of coherence.
3. I have no idea what the basis was for the chairs declaring the matter
resolved. This is an inherent problem with closing items by fiat and without
explanation.
Bottom lines:
a. There is a difference between having discussed something and having
resolved it.
b. The current draft is, at best, confusing about the distinction of exact
vs. tree
c. There is no technical means for doing a clean, efficient and thorough
job of "protecting" a sub-tree, when using the DNS. It wasn't designed for
that
use and it doesn't handle it for scenarios such as DKIM needs. Consequently, it
is not surprising that the current specification's component mechanisms for
"protecting" a sub-tree are partial, at best.
The particular point in Dave's note that troubles me, and that I don't
think we have agreement on, is his third one:
3. At least one of the sub-tree mechanisms is attempting to glean
information
from the absence of publisher action. Let me explain:
...
c) Checking for the presence of an A record is intended to try
tell you
something in the absence of an explicit action by the domain owner. That's
it's
flaw: It is intuiting ADSP information from non-ADSP action.
While there is nothing wrong with checking the A record, it's
semantics
have literally nothing (directly) to do with ADSP.
I agree with that assessment, but more importantly, I think the working
group doesn't yet agree on whether he's right or not.
Right about what?
There is a factual assertion that an existing A record will have been created
for reasons other than ADSP. That's a statement of fact, not opinion. A
records are not created for any purpose having to do with ADSP.
If someone disagrees with the statement of fact, they need to substantiate it.
And, yes, if they force such an exercise, I'll substantiate my assertion of
objective fact.
Since the A record is not created for ADSP, how can its semantics have anything
to do with ADSP? Again, this is in the realm of objective fact, not opinion or
preference. So I'm unclear what the working group could disagree with. (I'm
concerned that we are in the realm of operating on the basis that the working
group could formulate a consensus that 2+2=5 and the fact that there is
consensus would resolve the matter.)
So, Barry, please clarify what you mean by "the working group doesn't yet agree
on whether he's right or not."
So let's clear
this up with a focused discussion that gets one of the following results:
* We have consensus that ADSP should explicitly say that in the absence
of an ADSP record you have no information, and you treat the message as
you did before DKIM/ADSP existed. Any other processing might be
proposed as an extension, in another document.
I believe I understand this choice.
* We have consensus that there IS a well-defined process that we
recommend following in the absence of an ADSP record, and that having
the ADSP document define this is within scope for the base document.
I am pretty sure I do not understand this alternative, but I'm pretty sure it
does not respond to the concerns I raised.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html