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 <[email protected]> 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 <[email protected]> on behalf of Gould, James
> <[email protected]>
> Date: Monday, September 19, 2022 at 9:48 AM
> To: [email protected] <[email protected]>,
> [email protected]<[email protected]>
> Cc: [email protected] <[email protected]>
> 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
> [email protected]
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
>
> 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"
> <[email protected] on behalf of [email protected]> 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)
> > <[email protected]> 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: [email protected]
> > 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
> [email protected]
> 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
> [email protected]
> 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
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
