Re: [DNSOP] Working Group Last Call draft-ietf-dnsop-isp-ip6rdns

["Howard, Lee" <[e-mail]>]

On 5/9/16, 2:15 PM, "DNSOP on behalf of 神明達哉" <[e-mail] on behalf of [e-mail]> wrote:

>At Fri, 6 May 2016 14:59:12 -0400,
>Ted Lemon <[e-mail]> wrote:
>
>> >   While a reverse mapping is generally useful for informational
>> >   purposes, some people use it even more aggressively, such as for
>> >   access control or host validation based on the existence of a
>> >   reverse mapping, and often also on matching between the reverse and
>> >   forward mapping.  It is believed that those practices are not very
>> >   effective at best, especially for their side effect of punishing
>> >   otherwise-legitimate users and their service providers.  Although an
>> >   ideal solution to this is to encourage stopping those harmful
>> >   practices possibly with replacing them with more effective ones,
>> >   the sad operational reality is that it's less likely that the
>> >   operators employing those practices will listen anytime soon.  Until
>> >   then, the victim end users and their service providers will pay the
>> >   cost of the practices, and the only realistic intermediate remedy is
>> >   to provide required reverse mappings and often ensure the
>> >   revers-forward match.  This document shows possible options on how
>> >   to do this for those latter types of operators.
>>
>> The problem with this text when it was proposed before (it was proposed
>> before!) is that not everybody agrees on it either.   So last time we had
>> this discussion (which we have had more than once already, not counting
>> this time), we decided to just be neutral, rather than either saying "this
>> is a bad idea" or "this is a great idea."   I think the document is still
>> useful, because honestly I do not think it is going to make much difference
>> as far as host name checking goes.   I think if we want host name checking
>> to die, we should talk to authors of open source software that support this
>> feature into taking it out.   I think, for example, that openssh does this.
>>   Maybe we should talk to them.
>
>To be clear, I didn't (yet) intend to suggest using the above text in
>the draft.  It was just to see whether we are basically on the same
>page if we described it without trying to be *too neutral* or whether
>we are in disagreement on some more fundamental point.  Interpreting
>the above response as it's the former, and hopefully some more share
>the same view, I'd personally like to propose including some text like
>this - it could be weakened if some part of it is considered
>controversial, but I'd at least like to do the harm as a result of
>being afraid of controversial and being too neutral (and therefore
>ambiguous).
>
>Of course, this is just one personal feedback.  As you said it may be
>that we can't simply agree on any kind of this text.  It's ultimately
>up to the wg to decide.

I think we tried this in 2006-2008 with reverse-mapping-considerations, and in 2009 with early versions of this draft, and occasionally in the following years. I think the existing document balances the considerations and represents, if not everyone's opinion, the best consensus that currently exists.

Lee

>
>--
>JINMEI, Tatuya
>
>_______________________________________________
>DNSOP mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/dnsop

________________________________

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.