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

[Ted Lemon <[e-mail]>]

Yes, that's my recollection as well.   We've been working on some version
or another of this draft for kind of a long time, and that's why the
current document is as neutral as it is.   I think that neutrality really
does represent wg consensus, not in the sense that everybody is neutral,
but that there is nothing other than being neutral that will not raise
strong objections.

On Mon, May 9, 2016 at 2:31 PM, Howard, Lee <[e-mail]> wrote:

>
>
>
>
>
> 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.
>