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

Thanks Rick and Jim for the feedback. I am happy to accept the idea of the extension working for both domain and host objects and will work towards making that a part of the next version.

One point for possible further discussion is the "priority" of TTL values: I am going to state that the TTL value of the host object takes priority over the TTL of the superordinate domain. So if:

	com default TTL: 172800
	example.com TTL: 3600:
	ns1.example.com TTL: (undefined)

then the TTL for NS records delegating to ns1.example.com should be 3600, but if

	com default TTL: 172800
	example.com TTL: 3600:
	ns1.example.com TTL: 86400

then the TTL should be 86400.

G.

> On 26 Sep 2022, at 13:41, Rick Wilhelm <Rwilhelm@PIR.org> wrote:
> 
> 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/>
> 
> 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
> 
> Cal: https://secure-web.cisco.com/1hJ_Ypbd5OAM--cIUke4ujR8-8LTMV4cqpfYs9QUL3-xaEmFm7OPW_RKJa5TaJZ-HneITtwkOeMVSKTCbmrMbjcErDdz8Dn9s8KdDKMHHT_n0P5y-9uAWYPonAmrg9XVm72gORCQ9yh_SEzHxdAInQcg2pxTqBSDiW21bw4Msfzp7DQlftiKFeHB_z6wxjFlsu1gkcEBSt3buj5OUNEPih8pWx70nO2sXSue_OSN30cn26q27kvkyDHix9BcqlRSV/https%3A%2F%2Fcnic.link%2Fgbcalendar
> 
> 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
> 
> _______________________________________________
> 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
> 
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
> 

--
Gavin Brown
Head of Registry Services
CentralNic Group plc (LSE:CNIC)
https://centralnicregistry.com

Cal: https://cnic.link/gbcalendar

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://www.centralnic.com