Re: [DNSOP] draft-fanf-dnsop-rfc2317bis-00 vs. draft-spacek-dnsop-update-clarif-01

Tony Finch <> Thu, 05 November 2015 11:08 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 364A01A8969 for <>; Thu, 5 Nov 2015 03:08:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.211
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QgAcx_lajHGC for <>; Thu, 5 Nov 2015 03:08:11 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 02AE11A8965 for <>; Thu, 5 Nov 2015 03:08:11 -0800 (PST)
X-Cam-AntiVirus: no malware found
Received: from ([]:59976) by ( []:25) with esmtpa (EXTERNAL:fanf2) id 1ZuIOm-00074D-pg (Exim 4.86_36-e07b163) (return-path <>); Thu, 05 Nov 2015 11:08:08 +0000
Received: from fanf2 by ( with local id 1ZuIOl-0006zE-Vd (Exim 4.72) (return-path <>); Thu, 05 Nov 2015 11:08:07 +0000
Date: Thu, 05 Nov 2015 11:08:07 +0000
From: Tony Finch <>
To: Petr Spacek <>
In-Reply-To: <>
Message-ID: <>
References: <> <> <>
User-Agent: Alpine 2.00 (LSU 1167 2008-08-23)
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: Tony Finch <>
Archived-At: <>
Subject: Re: [DNSOP] draft-fanf-dnsop-rfc2317bis-00 vs. draft-spacek-dnsop-update-clarif-01
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 05 Nov 2015 11:08:13 -0000

Petr Spacek <> 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
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?
> >
> 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
> It would be nice to copy&paste/incorporate the text from there. These risks
> should be explicitly mentioned.


> I believe that we can drop draft-spacek-dnsop-update-clarif in favor of
> rfc2317bis if concerns above can be resolved.

Groovy :-)

f.anthony.n.finch  <>
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.