Re: [DNSOP] Call for Adoption: draft-fanf-dnsop-rfc2317bis

Andreas Gustafsson <gson@araneus.fi> Sun, 17 January 2016 12:36 UTC

Return-Path: <gson@gson.org>
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 05BC71A1A0C for <dnsop@ietfa.amsl.com>; Sun, 17 Jan 2016 04:36:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.601
X-Spam-Level:
X-Spam-Status: No, score=-0.601 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] 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 AHfOqAq0sDlN for <dnsop@ietfa.amsl.com>; Sun, 17 Jan 2016 04:36:01 -0800 (PST)
Received: from gusto.araneus.fi (gusto.araneus.fi [185.55.84.130]) by ietfa.amsl.com (Postfix) with ESMTP id BAC591A19EF for <dnsop@ietf.org>; Sun, 17 Jan 2016 04:36:00 -0800 (PST)
Received: from guava.gson.org (unknown [10.0.1.240]) by gusto.araneus.fi (Postfix) with ESMTP id F06FE8BE36F; Sun, 17 Jan 2016 12:35:57 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=araneus.fi; s=mail; t=1453034158; bh=9pDWIA/FkwSsidvOyFp0+eRThsbPD4vQHnZ1BGAweHE=; h=Date:To:Cc:Subject:In-Reply-To:References:From; b=nbpCQvXroMOA8aiLGItK0xyDLMS0jIh0l5LUon7KsbYfSmVU6wr8Rv6iKsue5vxhJ pIIMRDAIkTLpuShWzqXQQaDu/266b65qerRvQF1UcV2++zA1Y6R4Tt7eZsNjrwVTwg NNcR27nsZ5Z0Mn/mVF2oLyKNKLBTI/Iwgq6Tvw08=
Received: by guava.gson.org (Postfix, from userid 101) id 1823174508B; Sun, 17 Jan 2016 14:35:55 +0200 (EET)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-ID: <22171.35498.720284.788325@guava.gson.org>
Date: Sun, 17 Jan 2016 14:35:54 +0200
To: Tony Finch <dot@dotat.at>
In-Reply-To: <alpine.LSU.2.00.1601141306000.8365@hermes-2.csi.cam.ac.uk>
References: <566E329D.7010007@gmail.com> <CAJE_bqeR5nVGOnLWQ3CzWKR86===VoXWNsqyas3yJEG5zX2n=Q@mail.gmail.com> <alpine.LSU.2.00.1601131007410.8365@hermes-2.csi.cam.ac.uk> <CAJE_bqc53vizG54TS9yRCfP62EdnzyP=5piDRVKixAWB+_C+kw@mail.gmail.com> <alpine.LSU.2.00.1601141306000.8365@hermes-2.csi.cam.ac.uk>
X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd)
From: Andreas Gustafsson <gson@araneus.fi>
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/TcEOTKEYkckvTDbDi2N6fra_LRo>
Cc: Tim Wicinski <tjw.ietf@gmail.com>, dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Call for Adoption: draft-fanf-dnsop-rfc2317bis
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: Sun, 17 Jan 2016 12:36:13 -0000

Tony Finch wrote:
> 神明達哉 <jinmei@wide.ad.jp> wrote:
> 
> > - Does rfc2317bis really "update" RFC2136 in the first place?  It
> >   certainly provides some additional client behavior that uses
> >   RFC2136, but it doesn't seem to require any change to RFC2136 itself
> >   (am I overlooking something?).
> 
> The purpose of that part of the RFC is to impose extra requirements on
> UPDATE clients which are necessary for interoperability. I don't know
> exactly how that intent should translate into RFC metadata labels, which
> is why I have a question about it in the appendix. So I would really like
> advice and opinions from others.

Here's my opinion: Section 9 of the draft should not refer to the
requirements as "requirements for UPDATE clients", but something like
"requirements for entities that update endpoint records in the reverse
tree".  I would consider these entities to be on a higher layer of the
protocol stack than the UPDATE protocol itself.  They may happen to
use UPDATE as the lower-layer mechanism to effect the changes, but
that does not make this a change to the UPDATE protocol, an update to
RFC2136, or a requirement on UPDATE clients in general.

I would even say that the requirement to follow CNAME and DNAME
redirections should apply equally when the updates are not performed
using the RFC2136 UPDATE protocol at all, but using some other
mechanism.
-- 
Andreas Gustafsson, gson@araneus.fi