Re: [DNSOP] draft-fanf-dnsop-rfc2317bis-00 vs. draft-spacek-dnsop-update-clarif-01
Tony Finch <dot@dotat.at> Thu, 05 November 2015 11:08 UTC
Return-Path: <fanf2@hermes.cam.ac.uk>
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 364A01A8969 for <dnsop@ietfa.amsl.com>; Thu, 5 Nov 2015 03:08:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 QgAcx_lajHGC for <dnsop@ietfa.amsl.com>; Thu, 5 Nov 2015 03:08:11 -0800 (PST)
Received: from ppsw-50.csi.cam.ac.uk (ppsw-50.csi.cam.ac.uk [131.111.8.150]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02AE11A8965 for <dnsop@ietf.org>; Thu, 5 Nov 2015 03:08:11 -0800 (PST)
X-Cam-AntiVirus: no malware found
X-Cam-ScannerInfo: http://www.cam.ac.uk/cs/email/scanner/
Received: from hermes-2.csi.cam.ac.uk ([131.111.8.54]:59976) by ppsw-50.csi.cam.ac.uk (smtp.hermes.cam.ac.uk [131.111.8.158]:25) with esmtpa (EXTERNAL:fanf2) id 1ZuIOm-00074D-pg (Exim 4.86_36-e07b163) (return-path <fanf2@hermes.cam.ac.uk>); Thu, 05 Nov 2015 11:08:08 +0000
Received: from fanf2 by hermes-2.csi.cam.ac.uk (hermes.cam.ac.uk) with local id 1ZuIOl-0006zE-Vd (Exim 4.72) (return-path <fanf2@hermes.cam.ac.uk>); Thu, 05 Nov 2015 11:08:07 +0000
Date: Thu, 05 Nov 2015 11:08:07 +0000
From: Tony Finch <dot@dotat.at>
X-X-Sender: fanf2@hermes-2.csi.cam.ac.uk
To: Petr Spacek <pspacek@redhat.com>
In-Reply-To: <563ACAAC.4080209@redhat.com>
Message-ID: <alpine.LSU.2.00.1511051049300.959@hermes-2.csi.cam.ac.uk>
References: <563A69D0.7090208@gmail.com> <alpine.LSU.2.00.1511042144130.28816@hermes-2.csi.cam.ac.uk> <563ACAAC.4080209@redhat.com>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: Tony Finch <fanf2@hermes.cam.ac.uk>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/Z6kaqwGjVyKbwf0kwo2iYYBfS0Y>
Cc: dnsop@ietf.org
Subject: Re: [DNSOP] draft-fanf-dnsop-rfc2317bis-00 vs. draft-spacek-dnsop-update-clarif-01
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 05 Nov 2015 11:08:13 -0000
Petr Spacek <pspacek@redhat.com> wrote: Thanks for your thoughts! > > Note that my 2317bis draft has a slightly different take on UPDATE vs > > classless reverse DNS. The UPDATE section of my draft is entirely due to > > Petr's draft, so I'm very grateful to him for pointing out the problem. > > I'm interested in opinions about > > > > - should this be a separate draft or is it sensible to put it in rfc2317bis? > > It could be combined with rfc2317bis because there is very tight relation > between these two. However spacek-update-clarif is more generic and IMHO we > should extend rfc2317bis to incorporate the generic-ness before dropping > spacek-update-clarif. > > > - is the indirection problem specific to classless reverse DNS (which is > > the approach I took) or does it apply everywhere (which is what > > Petr Spacek's draft says)? > > Personally I do not see why it should be specific to ARPA sub-tree ... > Conceptually it is the question if client wants to update RR at the terminal > node or on the node client can name beforehand ("reverse DNS query name" is > one example of a name known beforehand). Right. I was partly reacting to Mark's comments (http://www.ietf.org/mail-archive/web/dnsop/current/msg15333.html) and I probably went too far in being specific rather than generic, sort of deliberately to give us a concrete alternative to think about. > Thinking about it a bit more ... I can see that RFC2317bis should make > canonicalization mandatory for reverse sub-trees and all other cases should be > left to the implementation to decide. Let's see if we can do it in one document. Good idea, yes. > > - is my detailed suggested UPDATE behaviour sensible? > > https://tools.ietf.org/html/draft-fanf-dnsop-rfc2317bis-00#section-9 > > Most importantly, I believe that limiting the new behavior ("canonicalize > first") to PTR RR type is a bad idea. We have DHCID, EUI48, EUI64 and people > are certainly using other RR types in the reverse sub-trees too (TXT comes to > mind...). > > Even if we decide in the end to mandate the new behavior to ARPA sub-tree we > surely should not limit ourselves to PTR. Absolutely, very good point. > I'm proposing to use following text (few nitpicks included): Thanks, I'll incorporate those suggestions. I'm trying to think of a good term for PTR-like records, or non-delegation-non-alias records, because I would like to be reasonably specific about what this does and doea not apply to. > Additionally, Security Considerations section does not mention risks mentioned in > https://tools.ietf.org/html/draft-spacek-dnsop-update-clarif-01#section-6 > > It would be nice to copy&paste/incorporate the text from there. These risks > should be explicitly mentioned. Yes. > I believe that we can drop draft-spacek-dnsop-update-clarif in favor of > rfc2317bis if concerns above can be resolved. Groovy :-) Tony. -- f.anthony.n.finch <dot@dotat.at> http://dotat.at/ East Dogger, Fisher, German Bight, Humber: Southerly or southwesterly 4 or 5, increasing 6 at times. Slight or moderate. Rain or showers, fog patches. Moderate or good, occasionally very poor.
- [DNSOP] Agenda and Slides upload Tim Wicinski
- Re: [DNSOP] Agenda and Slides upload Tony Finch
- Re: [DNSOP] draft-fanf-dnsop-rfc2317bis-00 vs. dr… Petr Spacek
- Re: [DNSOP] draft-fanf-dnsop-rfc2317bis-00 vs. dr… Tony Finch
- Re: [DNSOP] Agenda and Slides upload Bob Harold