IETF Logo Mail Archive

Re: [regext] TLD Phase Discovery

Patrick Mevzek <pm@dotandco.com> Thu, 03 August 2017 16:31 UTC

Return-Path: <patrick@shaktot.patoche.org>
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 842C8132495 for <regext@ietfa.amsl.com>; Thu, 3 Aug 2017 09:31:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 k270ztp97cOU for <regext@ietfa.amsl.com>; Thu, 3 Aug 2017 09:31:51 -0700 (PDT)
Received: from shaktot.patoche.org (shaktot.patoche.org [212.85.152.86]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 75F02132496 for <regext@ietf.org>; Thu, 3 Aug 2017 09:31:51 -0700 (PDT)
Received: from shaktot.patoche.org (localhost.localdomain [127.0.0.1]) by shaktot.patoche.org (8.14.3/8.14.3/Debian-9.4) with ESMTP id v73GVeiJ015554; Thu, 3 Aug 2017 18:31:40 +0200
Received: (from patrick@localhost) by shaktot.patoche.org (8.14.3/8.14.3/Submit) id v73GVeQL015553; Thu, 3 Aug 2017 18:31:40 +0200
Date: Thu, 03 Aug 2017 18:31:38 +0200
From: Patrick Mevzek <pm@dotandco.com>
To: "regext@ietf.org" <regext@ietf.org>
Message-ID: <20170803163138.GA13214@home.patoche.org>
References: <8CC3F09A-084F-41A1-9BE7-F44A293BA665@verisign.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <8CC3F09A-084F-41A1-9BE7-F44A293BA665@verisign.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Scanned-By: shaktot_dot_patoche_dot_org on 212.85.152.86
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/yeWlJeoQmAhBaR5yrfmPcITy4dA>
Subject: Re: [regext] TLD Phase Discovery
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: Thu, 03 Aug 2017 16:31:53 -0000

Gould, James <jgould@verisign.com> 2017-08-03 18:13
> I believe TLD level EPP policies is relevant, but is best suited for something outside of the Launch Phase or Registry Fee command-response extensions.   An example policy EPP mapping is the Registry Mapping (https://www.verisign.com/assets/epp-sdk/verisign_epp-extension_registry_v00.html) that does provide launch phase schedule information at the TLD (zone) level.  Something like the Registry Mapping with extensions to define the features and policies of EPP extensions like the Launch Phase or Registry Fee extensions is best suited for defining and discovering the features and policies.

I agree with Roger that auto-discovery should be a problem to be
tackled and replied with solutions. For TLD phases but also for a lot
of other "knobs" and options in EPP.

And I totally agree with James on the Registry Mapping extension, that
could be suited for this task.

I would even be very happy if VeriSign
could push forward to make this EPP extension a standard, to be used
by many registries.

-- 
Patrick Mevzek

v2.23.0 | Report a Bug | By Email