Re: What problem were we trying to solve again? (was Re: Radical

[JINMEI Tatuya / $B?@L@C#:H(B <jinmei@isl.rdc.toshiba.co.jp>]

>>>>> On 27 Mar 2003 18:28:52 +0000, 
>>>>> Paul Vixie <vixie@vix.com> said:

>> I wanted to see a consensus (if we can reach it) on how much we should
>> (continue to) rely on reverse mapping.  In particular, I'd like to
>> know cases where reverse mapping must be provided and other approaches
>> cannot apply.

> the reverse mapping function provided by PTR RR's in both ipv4 and ipv6
> provides an unauthenticated but still useful indication of the strength of
> the relationship between the operator of a network and the operator of a
> host on that network.  icmp, for example, wouldn't do this.

I understand that.  My question is, in which case and how much we
should rely on the useful indication.

> very few host//network configuration errors shown by a failure in reverse
> mapping are limited to just reverse mapping failures -- there's almost
> always something else wrong, of which a reverse mapping failure is the
> mere "tip of the iceberg."

From my own, of course limited, experiences, this is not necessarily
true (that's why I don't think the current situation provides a good
tradeoff).  But I don't have a statistical evidence and thus can only
make an apriori argument, so I'll stop here on this point.

> problems related to maintaining the reverse mapping, either via synthesis
> or dynamic update or preallocation or whatever, are really just problems
> in trying to support a strong enough relationship between the operator of
> a network and the operators of hosts on that network, if the number of
> hosts grows the way we expect it to.  that's a technical problem, let's
> solve it, rather than declaring a priori that the gain isn't worth the pain.

Sure, I don't oppose to making reverse mapping robust as long as the
effort is effective and can provide a good tradeoff.  (And I don't
think I declared the gain isn't worth the pain, though I surely said I
don't understand the gain is worth the pain in the current operational
practice.)

At the same time, I still believe it is good for us to study cases
where we should really rely on reverse mapping and cases where we
don't have to (but we currently do), as a part of solving the
"technical problem."  In this sense, I want the
draft-ietf-dnsop-inaddr-required draft to be discussed further.

And also, I believe there should be cases where we don't have to rely
on reverse mapping and can apply other approaches, as a part of
solving the technical problem.

All of three are ongoing efforts to solve the same problem, and none
of them can reject pursuing others at this moment.  Of course, if some
of the efforts complete, it may affect the others.  For example, if
the first approach can provide a perfect solution, the rest may be
unnecessary.  Similarly, if we can agree on some applicability in the
second approach (this is my main opinion in this thread), it may make
the first approach easier and more effective.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					jinmei@isl.rdc.toshiba.co.jp

#----------------------------------------------------------------------
# To unsubscribe, send a message to <dnsop-request@cafax.se>.