Hello Gavin,
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
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
