IETF Logo Mail Archive

Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers

神明達哉 <jinmei@wide.ad.jp> Wed, 05 November 2014 18:20 UTC

Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0CE61A90CD for <dnsop@ietfa.amsl.com>; Wed, 5 Nov 2014 10:20:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.977
X-Spam-Level:
X-Spam-Status: No, score=-0.977 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jM0HIHT-iHvO for <dnsop@ietfa.amsl.com>; Wed, 5 Nov 2014 10:20:01 -0800 (PST)
Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 01B441A903F for <dnsop@ietf.org>; Wed, 5 Nov 2014 10:20:00 -0800 (PST)
Received: by mail-wi0-f171.google.com with SMTP id r20so848631wiv.10 for <dnsop@ietf.org>; Wed, 05 Nov 2014 10:19:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=ZLCpVRolOI4RXUMLxinfnA/ViB7Dl6j85LIHVa6dAAw=; b=zwoPy8ylPPoW8+wQ5Dy1Ji3cQcMvbYGQWF53DBdfuuSew5o540s06WsuLNvVHa0vcr 53uvdyNIr74XNE6Iumccdp+tuhfcv/HjxQjZLkJ7ldkieqt7weZb8Tb5HWr6VbVtBE33 7UvRy3Y1R4w9uaZg0kjnd8V6z1KrE3hLdUBbJljuFPOWkXacQIeula5bUmGb6AU3aq30 WhTGpVx5i6aBbvY1tStxZCgPCkU4FJZ1WA4eSUmvMiaDPuju2S1o9TE6D2ijR5XAg9Pb IHaKtcNYCD3y1IR83KMGdJDiW9CoJxCUg6+erk9N+Xaxy3GtOHL7YRK9O5mI5DxJ/vsc Wt1w==
MIME-Version: 1.0
X-Received: by 10.180.108.43 with SMTP id hh11mr7737161wib.80.1415211599658; Wed, 05 Nov 2014 10:19:59 -0800 (PST)
Sender: jinmei.tatuya@gmail.com
Received: by 10.194.19.136 with HTTP; Wed, 5 Nov 2014 10:19:59 -0800 (PST)
In-Reply-To: <54556D3B.4020505@redbarn.org>
References: <20141101205101.66019.qmail@ary.lan> <54556D3B.4020505@redbarn.org>
Date: Wed, 05 Nov 2014 10:19:59 -0800
X-Google-Sender-Auth: JAo5tHt1lehpE-HBzyj-WSBeuz8
Message-ID: <CAJE_bqe5iRtRCj3eVC13LBk3PLPFQuO0zkfmYvS+MHdHwYQ+Kg@mail.gmail.com>
From: 神明達哉 <jinmei@wide.ad.jp>
To: Paul Vixie <paul@redbarn.org>
Content-Type: multipart/alternative; boundary="089e0122950aae0551050720a0a7"
Archived-At: http://mailarchive.ietf.org/arch/msg/dnsop/bpcwf_K--KWsv2k44j7Av-9B9d0
Cc: dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Draft Reverse DNS in IPv6 for Internet Service Providers
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 05 Nov 2014 18:20:03 -0000

At Sat, 01 Nov 2014 16:31:07 -0700,
Paul Vixie <paul@redbarn.org> wrote:

> if there were an RFC (let's be charitable and assume it would have to be
> an FYI due to lack of consensus) that gave reasons why PTR's would be
> needed and reasons why the absence might be better (so, internet access
> vs. internet service), then that RFC might give our last-mile industry
> buddies the air cover they need to be first movers in dropping PTR's for
> both V6 and V4 "internet access" addresses. [...]

I guess
https://tools.ietf.org/html/draft-ietf-dnsop-reverse-mapping-considerations-06
(also in the references section of draft-howard-dnsop-ip6rdns-00, but
doesn't seem to be actually referenced from the draft body) tried to
become this kind of RFC (ignoring subtle implication differences).
Unfortunately the draft was dead in a lot of controversy, and I think
we're seeing the same type of varied opinions on this thread.  I
personally think if we can agree on the content this time, such a
document will be very useful, but we should carefully learn from the
previous failure so we won't repeat it.

--
JINMEI, Tatuya

v2.23.0 | Report a Bug | By Email