Hi all,
This new version reflects feedback received including Jim's regarding the
server behaviour when processing commands.
Two "modes" are defined: the default mode and the "policy" mode:
* default mode ( absent or with policy=false): include elements
for non-default values only, no
Internet-Draft draft-ietf-regext-epp-ttl-06.txt is now available. It is a work
item of the Registration Protocols Extensions (REGEXT) WG of the IETF.
Title: Extensible Provisioning Protocol (EPP) mapping for DNS Time-To-Live
(TTL) values
Author: Gavin Brown
Name:
Gavin,
Thank for posting -06. I have reviewed the draft and updated the
implementation of it. Below is my feedback:
1. Nit - The last example in section 2.1.1.1 is mislabeled and should be
“Example host response…”. Also, do you want the TTL value for the “A”
record to match that of
On 1 March 2024 22:31:30 CET, rep.dot@gmail.com wrote:
>We've implemented this, but it's just..
churn.
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
On 28 February 2024 13:03:10 CET, "Andrew Newton (andy)" wrote:
>Hi James,
>
>RFC 7483 did not require the 'value' attribute, however when the
>standard was revised in RFC 9083 this attribute became required.
>
And, as said elsewhere, this was a very bad idea indeed.
Is there any client, that
Hi all,
Following a few off-list discussions, I’m going to hold on including the root
in the DNS bootstrap file at this time.
The intention is to enable RDAP clients to be able lookup the contact
information for TLDs, as suggested or implied by the following sentence in
RFC9224, Section 4.
Andy,
The new gTLD Response profile
(https://www.icann.org/en/system/files/files/rdap-response-profile-21feb24-en.pdf)
says … “a value with the RDAP lookup path that generated the RDAP response.”,
requirements 2.6.3 and 2.10. Unless you are referring to another document, this
is quite
