Re: [DNSOP] New Version Notification for draft-fanf-dnsop-rfc2317bis-01.txt

Petr Spacek <> Tue, 10 November 2015 16:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 53F6E1B3A4E for <>; Tue, 10 Nov 2015 08:24:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.911
X-Spam-Status: No, score=-6.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rEbumi3lsD0i for <>; Tue, 10 Nov 2015 08:24:37 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CA2A41B3A4F for <>; Tue, 10 Nov 2015 08:24:37 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTPS id 69B5FC0AF3D3; Tue, 10 Nov 2015 16:24:37 +0000 (UTC)
Received: from ( []) by (8.14.4/8.14.4) with ESMTP id tAAGOZWU020608 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Nov 2015 11:24:36 -0500
To: Tony Finch <>,
References: <>
From: Petr Spacek <>
X-Enigmail-Draft-Status: N1110
Organization: Red Hat
Message-ID: <>
Date: Tue, 10 Nov 2015 17:24:35 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.68 on
Archived-At: <>
Subject: Re: [DNSOP] New Version Notification for draft-fanf-dnsop-rfc2317bis-01.txt
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: Tue, 10 Nov 2015 16:24:39 -0000

On 10.11.2015 15:22, Tony Finch wrote:
> I have published a new version of my Classless IN-ADDR.ARPA draft. This
> incorporates some miscellaneous suggestions from before the IETF meeting,
> and Petr's suggestions from last week.
> All comments and suggestions welcome!
> Petr, I've cut down your security considerations fairly viciously; please
> shout if you think I have cut too much! I dropped the paragraph about
> UPDATE security since that is covered in RFC 2136. I also dropped the last
> paragraph since the earlier part seems to just repeat what the previous
> paragraph said, and the later part seems to suggest some special server
> side processing; if server-side processing is a real suggestion it needs a
> real spec.

Good. The mention about server-side checks was just an example showing that
unauthenticated updates might be good enough in certain situations but this
example is pointless because you have removed references to plain RFC 2136
updates. I'm fine with that.

To answer some of questions from the draft:
> Appendix B. Questions for reviewers
> Is the $GENERATE section a good idea? Should it be ditched? Or
> maybe promoted to its own document?

I would prefer a separate document because this is really a separate issue.

> RFC 2317 is BCP 20. Should this document be moved to the standards
> track, since it updates RFC 2136? Or should the UPDATE amendment be
> a separate document?

Yes, I believe that standards track is appropriate. It can stay in one
document so readers have the context and understand why we are making the change.

> Is the indirection problem specific to classless reverse DNS (which
> is the approach I took) or does it apply to the forward DNS as well?
> Suggestions for wording welcome.

Personally I would mention that this problem is generic to make application
developers aware of it. In the previous exchange I was proposing text similar
to this:

   Please note that this problem is generic. For names outside of
   IN-ADDR.ARPA or IP6.ARPA sub-trees it is up to implementation
   to decide if it is necessary to update alias itself or if it is
   necessary to update endpoint records and thus the method described
   in the section 9.2 needs to be applied.

Is there something wrong with it? It should be just informational.

> Is the detailed UPDATE behaviour sensible?
Definitely yes :-)

Petr Spacek