Re: [regext] Fwd: New Version Notification for draft-regext-brown-epp-ttl-01.txt

Gavin,

Just a +1 for having this extension cover both the domain and host objects.

The sibling glue model has enough deployment that having the extension cover both models makes sense.

One other thing… and this is not a call for a change, just concurrence to an existing design choice that is in the draft.  I like the behavior described for Server Processing of TTL Values (Section 4, paragraph 2) where the description covers the scenario where the TTL values are outside the range.

The doc says to reject the command with a 2004 “Parameter value range error”.  I was wondering if this might be “too aggressive” for a <create> (it clearly makes sense for an <update>), but after some thought, I agree with the current behavior.

First, it’s consistent.  Second, since the extension is optional (and since hosts links are optional on domain::create, the extension is “2x-optional”), it is better to “fast fail” due to validation enforcement.  Because to let the <domain::create> go through and have the invalid values flagged with only a warning is more likely to lead to confusion in the future.  That is, a client that is not properly respecting the limits of the TTL values is also unlikely to be heading a hypothetical warning value.

So, bottom line, after some thought, I like the way that this works.

Thanks
Rick

From: regext <regext-bounces@ietf.org> on behalf of Gould, James <jgould=40verisign.com@dmarc.ietf.org>
Date: Monday, September 19, 2022 at 9:48 AM
To: gavin.brown@centralnic.com <gavin.brown@centralnic.com>, Thomas.Corte@knipp.de <Thomas.Corte@knipp.de>
Cc: regext@ietf.org <regext@ietf.org>
Subject: [EXTERNAL] Re: [regext] Fwd: New Version Notification for draft-regext-brown-epp-ttl-01.txt
CAUTION: This email came from outside your organization. Don’t trust emails, links, or attachments from senders that seem suspicious or you are not expecting.

Gavin,

The TTL for the A/AAAA records need to be applied to the host object and the TTL for the NS and DS records need to be applied to the domain object. Setting the A/AAAA TTL at the host object level would apply to registries that implement sibling glue as well as CentralNic and TANGO that implement in-bailiwick only glue.

--

JG

James Gould
Fellow Engineer
jgould@Verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/<https://protect-us.mimecast.com/s/iFMsCG6o18iJzJqC1Y5hZ?domain=verisigninc.com>>

On 9/16/22, 9:17 PM, "regext on behalf of Gavin Brown" <regext-bounces@ietf.org on behalf of gavin.brown@centralnic.com> wrote:

Hi Thomas,

Thanks for the suggestions. I will add them to the next version.

G.

> On 15 Sep 2022, at 01:11, Thomas Corte (TANGO support) <Thomas.Corte@knipp.de> wrote:
>
> On 9/14/22 13:35, Gavin Brown wrote:
>
>> Greetings all,
>>
>> Many years ago CentralNic had a proprietary EPP extension for managing
>> the TTL values of domain names. ...
>>
>> However I've had a bit of feedback about the draft since then, so I've
>> just published a new version and am now sharing it with the WG for
>> feedback.
>
> I have two comments:
>
> 1) The specification should probably address the effect of the TTLs on
> IDN variants. If a registry supports IDN variants as attributes of a
> domain name (either automatically added or via an extension), they will
> usually add some DNS records dedicated to these variants to the TLD zone,
> so the spec should specify that the same TTL is applied to these
> dedicated records as well. If IDN variants are managed as their own
> objects, they can receive their own specific TTL values.
>
> 2) I'd suggest to add this boilerplate text (or something similar) to the
> draft:
>
> "EPP uses XML namespaces to provide an extensible object management
> framework and to identify schemas required for XML instance parsing
> and validation. These namespaces and schema definitions are used to
> identify both the base protocol schema and the schemas for managed
> objects. The XML namespace prefixes used in examples (such as the
> string "ttl" in "xmlns:ttl") are solely for illustrative purposes. A
> conforming implementation MUST NOT require the use of these or any
> other specific namespace prefixes."
>
> This is a pet peeve of mine, as some registries still haven't managed to
> implement this correctly.
>
>> In our implementation, glue records are only published if the
>> superordinate domain is delegated to them, and the current
>> specification assumes the same design choice. However this is
>> obviously not true for other registries, so being able to change the
>> TTL on a host object independently of the superordinate domain may be
>> needed to account for scenarios where the client wishes to change the
>> TTL of all NS records *except* those of the superordinate domain.
>> However I am not sure if this is a scenario that justifies the
>> additional complexity entailed - but I'd appreciate the list's input
>> on that point.
>
> Our own TANGO system's zone generation also suppresses glue records if
> they're unnecessary, so I'd agree that the extra complexity shouldn't be
> required.
>
> Best regards,
>
> Thomas
>
> --
> TANGO REGISTRY SERVICES®
> Knipp Medien und Kommunikation GmbH Thomas Corte
> Technologiepark Phone: +49 231 9703-222
> Martin-Schmeisser-Weg 9 Fax: +49 231 9703-200
> D-44227 Dortmund E-Mail: Thomas.Corte@knipp.de
> Germany
>
>
>
>
>

--
Gavin Brown
Head of Registry Services
CentralNic Group plc (LSE:CNIC)
https://secure-web.cisco.com/14iQKw6gpSA8BoJOmhv6QjiaCTMGaV1jtoe_uIp8bRMky-K_waMharMEg1LYAtlWQzbHVPm2AmR56O6ydcDKobgVBEd8Mp95GJ4pfxuUZclcuaVBTXohuG6UFiZL8xJ3nqGu2mdmXKQsJPMkec8furVUgjMJNBPl8lwD5Bq0rklXDq-hFZXWTKZmWa5fb8Uwnk0OsfYNX4uZhal8J_rCVACHGBTdRrXemWcsjenM7fbYJzUttkEdStu8R7PY547eg/https%3A%2F%2Fcentralnicregistry.com<https://protect-us.mimecast.com/s/6mYGCJ6r4Qi8j8yuykDda?domain=secure-web.cisco.com>

Cal: https://secure-web.cisco.com/1hJ_Ypbd5OAM--cIUke4ujR8-8LTMV4cqpfYs9QUL3-xaEmFm7OPW_RKJa5TaJZ-HneITtwkOeMVSKTCbmrMbjcErDdz8Dn9s8KdDKMHHT_n0P5y-9uAWYPonAmrg9XVm72gORCQ9yh_SEzHxdAInQcg2pxTqBSDiW21bw4Msfzp7DQlftiKFeHB_z6wxjFlsu1gkcEBSt3buj5OUNEPih8pWx70nO2sXSue_OSN30cn26q27kvkyDHix9BcqlRSV/https%3A%2F%2Fcnic.link%2Fgbcalendar<https://protect-us.mimecast.com/s/zJX_CKrvgQHqRq9C2G4VT?domain=secure-web.cisco.com>

CentralNic Group plc is a company registered in England and Wales with company number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 6BR.

https://secure-web.cisco.com/1dbi9wWVJ28DEfKsxyfgDEQU-jFqu7mdY6XAsqbxvETOtZUTia8UHVG3wWzYeRemA7OPimBJnEWIQ_chpT9e5Sa-J20mZ-lg7OKtsrHauuCHNraZIrO2sRn6I4uLLUnXzu7GzOmhVsqGk-bob53BCqaJDheGvFW_lx1FJtJFFdvwqJk7jnOmAXoXJh9o7jqHERzAzFZQabrHdQPUpCk_gViXXZQ3itKXVeka3mdJHHng6f07BY0VfTk3jZ8prKebY/https%3A%2F%2Fwww.centralnic.com<https://protect-us.mimecast.com/s/BfVxCL9wjJFPzPXC5zYfd?domain=secure-web.cisco.com>

_______________________________________________
regext mailing list
regext@ietf.org
https://secure-web.cisco.com/17iGVT_AU5IsvLflCUT5ypMVunmm1fTgnPxEcMeRIVbSjVZJoJIWdWHyw157N9qknJiHgZkxVaZWRtrflXFk_7WtXpCWF_Gwe7PdF_lmQJh07SRN5vMVGi3XbZKgIdtWTMfx3R-diYwdR5a2_tC-ByoLYtPrGe7Mnivy3oZbVWZlEGNeiP0fE_5Nccxc5kNkVoPC0hdk-f9gyPQAaiVMskLu5OoHGs-thMpK2RAklTTuW5nbCC9f53GvnO4SlCwKo/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext<https://protect-us.mimecast.com/s/yCPWCM8xk1S5n59CN_7zO?domain=secure-web.cisco.com>

_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext<https://protect-us.mimecast.com/s/IsCzCNkyl0FNgN9hlofzP?domain=ietf.org>