--On Thursday, July 17, 2014 20:09 -0700 Dave Crocker
<dhc@xxxxxxxxxxxx> wrote:
> On 7/17/2014 7:50 PM, John C Klensin wrote:
>> I'm not recommending this but, if the documents said "this is
>> for parked domains,
> You mean, like www.ietf.org, which is never a legitimate email
> target hostname, but is rather easily specified in error?
Dave,
Please see the first part of that sentence, i.e., "I'm not
recommending this". The note to which I was responding appeared
to me to have the premise "this is mostly for parked domains"
and appeared to reason on that basis. There is certainly no
doubt that it is useful for the type of parked to which I
believe he was referring, independent of whether one believes
that is the primary use. I believe that the author of that note
is both competent and sincere and deserved a response on that
same basis. I was temporarily accepting his premise, following
it to what seemed to be its implications, and suggesting that,
if it were the case, then some things would be different and a
slightly different approach would be in order.
If you find a flaw in that style of reasoning, please explain.
To repeat what I said initially and which I hoped was clear in
the original wording: I have some concerns about this mechanism,
especially when it is used with domains that may appear in
backward-pointing addresses (see Tony Finch's recent note about
the reasons for doing that), I do not oppose its approval ("its"
referring to the mechanism) [1]. However, I think the document
needs work -- particularly in the areas of problematic
terminology (with "NULL MX Resource Record" in the document
title, section title, and elsewhere being an important
illustration), explanation of likely issues and how they should
be handled (with systems with separated sending and receiving
hosts as a case of particular importance), some document
organization issues (e.g., buried terminology definitions and
issues in Security Considerations that really deserve separate
treatment), and so on.
I don't consider any of those issues earthshaking, they just
suggest the draft needs a little work before it is approved.
For the sake of clarity because most of what I've written in the
last few weeks seems, from your remarks, to have been
incomprehensible, the list of items mentioned above are just
examples. The absence of something from that list that appears
in my original posted review on this draft does not indicate
I've lost interest in it, merely that I did not include it in
the illustrative examples above.
If some part of that is still difficult for you to understand,
please just tell me what it was and I will try to clarify. My
hope is that we are all working together to improve this (and
other) specifications, rather than trying to accomplish
something (I am disinclined to speculate on what) by
discrediting postings that try to identify issues.
best,
john
[1] You also questioned my "distasteful" remark on the basis,
IIR, that no one else had said so. While there have been some
recent trends toward organizing groups to propose or comment on
some actions (trends that I believe are inconsistent with IETF
principles about individual participation, but YMMD), I've never
been aware that one was required to demonstrate support for a
position or comment before making it, especially on an IETF Last
Call. I had not intended to explain the reason for my distaste
because I think it a distraction from getting this spec to an
appropriate quality level. However, because your remarks appear
to call for it, I believe (in agreement with what this document
just about says) that this mechanism is a back-door workaround
to requiring MX records for any host that is willing to accept
incoming email. Such a requirement would be architecturally
reasonable and would permit some nuance that MX records pointing
to the root do not such as allowing address records to be for
empty reverse path notification messages but not normal ones
with usable reverse paths (not saying that would be a good idea,
only mentioning the possibility). Several WGs and document
review discussions have rejected the approach of imposing that
requirement, probably for good reasons even though we might have
been able to work out a plan for deprecating the fallback with
sufficient notice. While some of us started writing SMTP
server simulators that would simply generate 5xy replies as soon
as someone tried to open a port 25 connection and installing
them on machines that did not accept mail, there is an apparent
consensus that remedy is inadequate because of the retry
problem. With one of those solutions rejected and the other
judged inadequate, the current mechanism is a reasonable
candidate for the best approach for dealing with the issues.
That doesn't mean I have to like it or think it is
architecturally elegant. Hence "distaste".