Subject: [DNSOP] Re: I-D ACTION:draft-ietf-dnsop-reverse-mapping-considerations-02.txt

From: Dean Anderson <[email-masked]>
Date: Tue, 6 Mar 2007 11:08:50 -0500 (EST)

FYI, I have submitted an alternate draft as an individual submission. It
was submitted after the meeting cutoff and so will not be processed
until Monday, March 19 at 9:00 AM ET, when Internet-Draft posting
resumes.

The draft can be found in the meantime at

http://www.av8.net/IETF-watch/Drafts/draft-anderson-reverse-dns-status-00.txt

If you compare the two drafts, and find them generally consistent, then
you have either not understood or not read closely the Sullivan/Senie
draft.  Particular attention should be paid to Sections 3.1, 3.3, and 4
of the Anderson draft and corresponding sections of the Sullivan/Senie
draft.

As previously indicated, I do not believe that
draft-ietf-dnsop-reverse-mapping-considerations-02.txt should move
forward because it continues to have very serious problems, as
previously discussed on the DNSOP list.  I strongly object to the
Sullivan/Senie draft, enough to write an alternative. The set of
problems with that draft are not new, but have been repeated in various
forms, often just by trivial word changes, since the original
in-addr-required draft was submitted 7 years ago.  I think the only way
forward is to abandon the Sullivan/Senie draft in favor of an
alternative that is more clearly written.

Thanks,

Dean Anderson
Av8 Internet, Inc

-- 
Av8 Internet   Prepared to pay a premium for better service?
www.av8.net         faster, more reliable, better service
617 344 9000   

_______________________________________________
DNSOP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dnsop

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 6 Mar 2007 12:23:56 -0500

Hi Dean,

> http://www.av8.net/IETF-watch/Drafts/draft-anderson-reverse-dns-status-00.txt

Thanks for the contribution to the discussion.  I have read this
draft, and I have some questions, and a comment.

> draft.  Particular attention should be paid to Sections 3.1, 

I don't understand what is in section 3.1 of -anderson- that is not in
-reverse-mapping- -02.  In particular, I don't see what any of

   Myth: "Registries require IP users to populate reverse mapping."

   Fact: Registries generally encourage, but do not require, customers
   to use reverse mapping.

   Fact: Registries may remove reverse mapping delegations on their own
   initiative if the delegated nameservers are lame.

say that is different from what is in the reverse-mapping draft.  The
-02 draft is, in my view, pretty clear that the RIRs do not -- indeed,
cannot -- require reverse mapping, that some of them encourage it, and
that they have their own policies.  Do you mean to suggest that what
is missing from the -02 reverse-mapping draft is the discussion of RFC
1788?  If so, please see my comment later.

> 3.3, 

I think you've been guilty here of the same charge you levelled at the
-01 reverse-mapping draft -- of using charged language to try to make
a point.  The "fact" subsection in 3.3 is actually a conclusion, and
one for which there is presented inadequate argument.  Moreover, you
have failed to make the distinction, made in the -02 reverse-mapping
draft as an outcome of your previous objections, between "matching"
and "existing" reverse data.  I think there is some discussion of this
topic in -reverse-mapping- -02 that is relevant to your objections.
I've asked for your feedback on that text, but I haven't received any.

> and 4

I believe I already addressed the issue of RFC 2119 keywords in
-reverse-mapping-.  In my view, the use of them in section 4 or any
other section of -anderson- would be just as mistaken: neither
document, as near as I can tell, proposes any standard of any kind for
the Internet community, and therefore RFC 2119 keywords are not
appropriate.  I did not receive a response from you in respect of that
argument; if you have one, I would be interested to hear it.

> forms, often just by trivial word changes, since the original

What would qualify as non-trivial word changes in your opinion?  It is
my rather strong belief that changing the words one uses changes the
meaning of the sentences in which one has used those words.  I do
believe that -reverse-mapping- -01 and -02 are saying substantially
the same thing, but the point of -02 was to clarify the parts of -01
that did not capture what the group was trying to say; and since you
were one of the people objecting, it would be nice to hear your
reaction to those attempts, to the extent that we have not already
collectively determined that a given objection cannot be accommodated.

By way of comment, while I think the discussion in -anderson- of RFC
1788 is interesting, I have the impression that you are trying to do
something other than what -reverse-mapping- is trying to do.  My
understanding is that -reverse-mapping- is trying to discuss the
reverse mapping feature of DNS as it exists and is used today on the
Internet.  It is undoubtedly true that there are other and possibly
better mechanisms for achieving the goals that the reverse tree was
originally designed to achieve.  It is entirely possible that a draft
intending to move the service described in RFC 1788 from experimental
to the standards track would be worthwhile.  But that is not the
point, in my understanding, of the work that the WG agreed to when
taking on -reverse-mapping-, and I think that it should be separated
as a work item.

Best regards,
Andrew

-- 
Andrew Sullivan                         204-4141 Yonge Street
Afilias Canada                        Toronto, Ontario Canada
<[email-masked]>                              M2P 2A8
jabber: [email-masked]                 +1 416 646 3304 x4110

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 6 Mar 2007 12:23:56 -0500

Hi Dean,

Best regards,
Andrew

---

From: Dean Anderson <[email-masked]>
Date: Tue, 6 Mar 2007 22:34:35 -0500 (EST)

On Tue, 6 Mar 2007, Andrew Sullivan wrote:

> that they have their own policies.  

We've had this discussion before over the years. What is stated about 
RIRs continues to change.

   Reverse mapping only works if
   all the intermediate delegations are correctly maintained.  As a
   result, RIRs find they cannot enforce policies requiring reverse
   mappings, because they sometimes do not have any relationship with
   the intermediate party on whom some end-point reverse mapping
   depends. 

The text from your -02 document, above, now implies that registries
desire in the future to, or have previously tried to, enforce reverse
mapping policies, but found an obstacle to the enforcement in the
intermediate parties. That implication is untrue.

My text describes what the registries have done, and could do,
without false implications.

> one for which there is presented inadequate argument. 

The fact subsection of 3.3 contains the evidence to support its
conclusion within its body.

The conclusion in 3.3 is that you have failed to offer proof of your
claims. That is a valid statement, and the section describes the actual
statements that were made. Obviously, if you could prove that your
claims, you could prove, by evidence, that 3.3 is false.  Your lack of
evidence is itself the necessary evidence that the 3.3 conclusion (which
is that there is no evidence supporting your view) is true.

You have merely claimed there is inadquate argument in 3.3, but again,
you haven't offered any evidence for your claim.

> Moreover, you have failed to make the distinction, made in the -02
> reverse-mapping draft as an outcome of your previous objections,
> between "matching" and "existing" reverse data.

My affirmative arguments don't depend on the distinction.  It was your
statements that were shown false by using the distinction. But I note
the strains on your -02 draft attempting to try to make true statements
by using the distinction.  Rather than follow the same rathole again, as
I did in previous years, I just wrote an alternative draft.

I am reminded of the court arguments reported recently regarding
Intelligent Design.  The Intelligent Design advocates claimed in their
documents that scientists had no evolutionary evidence for the immune
system. In court, a lawyer presented a stack of books and scientific
papers describing the evolutionary development of the immune system.  
Yet, faced with the stack of evidence refuting the claim, the
Intelligent Design person on the stand would not admit the claim about
the immune system was wrong.  Of course, the Jury found otherwise.  
Intelligent Design wasn't just bad science but a religon; a legal
strategy developed to teach Creationism is public schools in 1987 after
Creationism was found to be a religious view.  I've had exactly the same
kind of experiences with zealous anti-spammers.

> I think there is some discussion of this

I've submitted an alternate draft.  That might be considered entirely
alternate text. I don't believe you will change the meaning of the 
draft.

> > and 4 of the Anderson draft and corresponding sections of the
> > Sullivan/Senie draft.
> 

On January 8, 2007, I posted a list of examples of published
informational RFCs that include this language. That demonstrates that
RFC2119 language is allowed in informational RFC's.

On February 18th, 2007, I posted the text I just pasted in regarding the 
1/8/07 post.

2/18/07:
http://www1.ietf.org/mail-archive/web/dnsop/current/msg00149.html
1/8/07:
http://www1.ietf.org/mail-archive/web/dnsop/current/msg00062.html

On February 20, 2007, you responded that it was your opinion that
RFC2119 only applies to standards.  I did not respond to your message,
since there seemed to be nothing new to say. As already shown, in
contrast with your opinion, there is no text in RFC2119 that precludes
its use from information documents.  There are plenty of informational
documents that do cite RFC2119. Further, RFC2119 affirmatively states
that its defined terms are particularly relevent to security
considerations. Informational RFCs can have security considerations.  
The notion that informational RFCs are not technically 'standards'
appears, by all available evidence, to be irrelvent to RFC2119 purposes.

You don't seem to have proven you case, despite your contrary opinion.  
You have certainly received responses.  However, I am not an authority,
either.  But, absent an authoritative response by the chairs or the RFC 
Editor or someone in authority, the available evidence supports my view.

However, my draft is submitted on a BCP track, which is a kind of
standard.

> What would qualify as non-trivial word changes in your opinion?  

This seemingly simple question is actually an astonishingly hard
question to answer.  It is truly very difficult to pin down people who
don't want to be pinned down. That's why lawyers make so much money.  I
think the simplest answer, in this particular case, is that you would
have to change your mind about some things you believe fervently.

> It is my rather strong belief that changing the words one uses changes
> the meaning of the sentences in which one has used those words.

Hmm.  I think it can go either way, depending on the choice of words.
Let me give it a try: [limiting to synonyms in the same sentence
structure]

"It is my preferably mighty credence that altering the terms one employs 
mutates the meaning of the sentences in which one has employed those 
terms."

This means the same as the original text. So you can change the words
without changing the meaning.  [synonyms thanks to Rogets and
Merriam-Webster].  But indeed, your statement can certainly be true
depending on the choice of words.  Lets try again:

"It is my somewhat healthy faith that converting the communications one 
applies transmutes the meaning of the sentences in which one has applied
those words."

This perhaps suggests that maybe, possibly, encoding changes the
meaning. So you can change the meaning by changing a few words. [again,
just a different set of synonyms in the same sentence structure--so, in
some sense, it does represent your statement.]

I think one probably needs a more complicated example to make a good
analogy to explain what is going on in these drafts over the last years.
It will be much easier to write an alternative draft. I should have done 
that years ago. Hindsight.

> I do believe that -reverse-mapping- -01 and -02 are saying
> substantially the same thing, but the point of -02 was to clarify the
> parts of -01 that did not capture what the group was trying to say;

In my view, you obviously aren't listening to anything the group is
trying to say, except to assure the group that you are listening, and to
assure that your current draft now agrees with their actually quite
different views.  They have to read the current draft very, very
carefully to discover that your draft isn't really much different from
the original in-addr-required draft.

> and since you were one of the people objecting, it would be nice to
> hear your reaction to those attempts, to the extent that we have not
> already collectively determined that a given objection cannot be
> accommodated.

I suggest you re-read my Feb 18 message.

> originally designed to achieve.  

The current status of reverse dns should include a report on the
currently on-going experimental work in progress regarding reverse DNS.

> It is entirely possible that a draft intending to move the service
> described in RFC 1788 from experimental to the standards track would
> be worthwhile.  But that is not the point, in my understanding, of the
> work that the WG agreed to when taking on -reverse-mapping-, and I
> think that it should be separated as a work item.

The question of whether RFC1788 and RFC4620 maturity status' should be
reviewed or altered is irrelevant to the fact of their current
existance.  

Of course, one of the effects of any status report is widening knowledge
of what is going on.  That people react to the document as "oh my, I
didn't know that' means that it was helpful and accomplished the purpose
of reporting.

		--Dean

---

From: Dean Anderson <[email-masked]>
Date: Tue, 6 Mar 2007 22:34:35 -0500 (EST)

2/18/07:

		--Dean

---

From: Shane Kerr <[email-masked]>
Date: Wed, 07 Mar 2007 16:35:14 +0100

> http://www.av8.net/IETF-watch/Drafts/draft-anderson-reverse-dns-status-00.txt

As someone who thinks reverse is a lot of work considering the actual (almost
nonexistent) benefit, I find this draft compelling. :)

The report on the state of reverse DNS is almost identical in these drafts IMHO,
but the recommendations (and tone of course) differ greatly.

Is it possible to separate the "findings of fact" from the recommendations in
both this and draft-ietf-dnsop-reverse-mapping-considerations-##.txt?

If we do want a single document with facts *and* recommendations, then maybe we
need to start from goals and say, "if your goal is A, then we recommend *this*;
if your goal is B, then we recommend *that*".

Personally, as long as I don't have to wait for a timeout an a PTR lookup I'm
happy. :)

- --
Shane

---

From: Shane Kerr <[email-masked]>
Date: Wed, 07 Mar 2007 16:35:14 +0100

- --
Shane