Re: [regext] EPP and DNAME records?

Patrick Mevzek <pm@dotandco.com> Sat, 13 January 2018 23:50 UTC

Return-Path: <pm@dotandco.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 916FE12D88C for <regext@ietfa.amsl.com>; Sat, 13 Jan 2018 15:50:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.8
X-Spam-Level:
X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=dotandco.com header.b=mgDBniY7; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=TsvPYAHs
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 ohAP9FWpjgEp for <regext@ietfa.amsl.com>; Sat, 13 Jan 2018 15:50:14 -0800 (PST)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47C35126DED for <regext@ietf.org>; Sat, 13 Jan 2018 15:50:14 -0800 (PST)
Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.nyi.internal (Postfix) with ESMTP id 9076120D80 for <regext@ietf.org>; Sat, 13 Jan 2018 18:50:13 -0500 (EST)
Received: from web3 ([10.202.2.213]) by compute3.internal (MEProxy); Sat, 13 Jan 2018 18:50:13 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dotandco.com; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm1; bh=TzqmHfBsnTXnCT1v/fqEwTrP9G0km G1/MJVlW2dlQkw=; b=mgDBniY7fbUH21zQiEfzykph5Ac1m++Soz9eshBgbwwNP VaJUnaVgBN1dtn0RklJkc+HPhz1mJ1+9tuIcd68TaAFKVTDYmDKojuF+J9bpKLnu Tsbd5H49D3FO7BnJuSQ/NOvtsBdmMrTTTHXEX9EWdwg7X20n04W7Wfs/hHtRbw9J e1P+V/XPftEwP96XT7cKJSQdfOUaSsRtjNQiPPqtswuFA7twZ4N8NvUJknZVVsmB wFvFR0YxvyasJkquf7RvJrsa0s7hPm473cdJm3kvnr1hI4oFLpa7cNbBMbpNzj7E voUoBiwpX0ov9vofnFF87xzEUmnn2O8pe/IXkIm1Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=TzqmHf BsnTXnCT1v/fqEwTrP9G0kmG1/MJVlW2dlQkw=; b=TsvPYAHsUs+63n4Qt8vNkq /CStk8FJe7jt6ksM5OzIdx3023MbaNcpV1JMh+hAMWEYlvxWQNuZpmQ8NpoTcOWs av+s1bIx6c6AKNAXK4jlr9Eq6Z2Ga3M77t67ghoJ9g/rR628mDTWN2FMSPATnT9l e6VOC5h0xgGhp8+/5V0eEMwsnmKA5QUEpDklOgrxix3wgSAp3hwl4VmpKOK6sMSn RjYKirX2qhbSqt322QMcwHHY+z8gHzMU6CX5vL5bhDqVXH8CViSOWSth4NJIh08q ssjhPAcDNhd/NipKz79UMRkzhbiej6pcm1ifh2XwhWNBZZAPuyb9wkE+1T12jnVA ==
X-ME-Sender: <xms:NZtaWlCjVuq9XD4Msvt-NM-lyFGrZs1WgFlxjIZMKeWbob601UPpnmUke6Y>
Received: by mailuser.nyi.internal (Postfix, from userid 99) id 4D0899E4A6; Sat, 13 Jan 2018 18:50:13 -0500 (EST)
Message-Id: <1515887413.808127.1234484296.080BABE2@webmail.messagingengine.com>
From: Patrick Mevzek <pm@dotandco.com>
To: regext@ietf.org
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-75de3051
References: <20171112130006.GA31496@laperouse.bortzmeyer.org> <20180105111014.52tdcpky3hy3imth@nic.fr> <1515265262.3643892.1226402104.2E04C9FC@webmail.messagingengine.com> <20180108135102.mf2ykp6tszqinp4b@nic.fr>
Date: Sun, 14 Jan 2018 00:50:13 +0100
In-Reply-To: <20180108135102.mf2ykp6tszqinp4b@nic.fr>
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/QPHsB140KFcoTdg7CC2-J6hHEiY>
Subject: Re: [regext] EPP and DNAME records?
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 13 Jan 2018 23:50:15 -0000

On Mon, Jan 8, 2018, at 14:51, Stephane Bortzmeyer wrote:
> On Sat, Jan 06, 2018 at 08:01:02PM +0100,
>  Patrick Mevzek <pm@dotandco.com> wrote 
>  a message of 77 lines which said:
> 
> > as soon as we add one RR through EPP, as James stated there is the
> > question about all others.
> 
> Yes, and I clearly do not want to go into that: too complicated for
> me.

Have you seen draft-ietf-dnsop-aname?

Seems to be closely related in the sense that it could be as useful to have
DNAME as to have ANAME (of course the difference is that one already exists
the other not yet or never)


> > There is even already an extension for that.  It had URN
> > http://www.verisign.com/epp/zoneMgt-1.0 and I have the code
> > implementing it in my client, but I do not find it anymore on
> > Verisign website.
> 
> It is not in the IANA EPP extensions registry either.

There are many EPP extensions in the wild not in the extensions registry.
 
> > * On issue #3 and the issue of feature discoverability per domain, I
> > do not think the EPP check command is appropriate for that. The
> > DNAME record is not an object per se in the registry data model and
> > hence no operations would apply to it.
> 
> The idea was not to use the DNAME record as the object but the domain
> name, with an extension. Something like:
> 
> <domain:check
>        <domain:name>example.com</domain:name>
>        <dnameDeleg:if>foo.bar.example.net</dnameDeleg:if>
> </domain:check>

I am not sure you could easily extend the current core EPP to do that.
AFAIR I have never seen an extension like that.
  
> > * On issue #6 I feel it not necessary for the client to explicitely signal it wants the info back for the following reasons:
> 
> I agree also.
> 
> > If you really want to signal no data in all cases, you can also
> > reply with an empty dNameTarget
> 
> Note that it is not permitted if we switch from EPP string to
> eppcom:labelType.

Except if you derive from it and/or you have a different type for update than for create.

-- 
  Patrick Mevzek