Thanks to the authors and the working group for producing this clear and concise draft. 

I have one comment I'd like the authors to consider.

Section 3.1 states:
  "The DNS record type mnemonics that appear as the property names in
   values objects MUST be in all capitals and MUST be registered with
   IANA in [IANA-RRTYPES].  TTL values MUST be unsigned integers in the
   range 0-2147483647 as per Section 8 of [RFC2181]."

How should a client deal with an invalid mnemonic or TTL value?

Section 3 states:
  "As per Section 2.1 of [RFC9083], clients which do not implement this
   specification SHOULD ignore the "ttl0_data" member."

Should clients similarly ignore one with ith an invalid mnemonic or TTL value?

Thank you to the authors for a concise and cogent draft.  I have no additional comments beyond existing AD comments.

Thanks for the work done for this simple but useful extension.

Thanks also to Ralf Weber for the DNS directorate review at https://datatracker.ietf.org/doc/review-ietf-regext-rdap-ttl-extension-10-dnsdir-telechat-weber-2026-05-18/

One MAJOR comment and I am trusting the responsible AD to ensure that this point is acted upon. There are many "SHOULD" in this document without the required guidance per https://datatracker.ietf.org/doc/statement-iesg-statement-on-clarifying-the-use-of-bcp-14-key-words/ Please consider using a "MUST" (especially for interoperation), or the plain English "should" (which is still normative).

Thanks to the author and the WG for their work on this document.

I understand there are no concerns at the transport layer. I have no additional comments (please note Ketan's comments).

Thanks to the author and the WG for their work on this document.

I have a few comments and suggestions to offer.

1) Section 4.2 says "As a result, RDAP clients which use these frameworks may SHOULD explicitly carve out the "values" property of "ttl0_data" elements." ... I am guessing this is just a "SHOULD" and not a "may SHOULD" ?

2) RFC9499 perhaps needs to be a normative reference since it describes the TTL term that is used in the context of this document? I don't know enough of the provenance of DNS documents and terminologies and hence providing as a comment for the authors/WG and others to consider.

Section 3, paragraph 0
>    Servers that support this extension MAY include a "ttl0_data"
>    property in any domain (Section 5.3 of [RFC9083]) and nameserver
>    (Section 5.2 of [RFC9083]) objects included in RDAP responses.  As
>    per Section 2.1 of [RFC9083], clients which do not implement this
>    specification SHOULD ignore the "ttl0_data" member.

The introduction gives the motivation for the TTL value as an extension 
for debugging "DNS configuration." However, this section never 
explicitly states that the TTL values in ttl0_data reflect the registry's 
provisioned values rather than live DNS TTL observations (which decrement 
toward zero during the TTL lifetime). These two values will frequently differ. 
Implementations that query live DNS and report the observed TTL would be 
technically non-conformant, but the specification as written provides no 
textual basis to reject such an implementation. A single normative sentence 
in this and Section 4.1 would close this gap:

The TTL values included in ttl0_data MUST reflect the TTL values as 
provisioned in the registry database, not the remaining TTL of DNS records 
as observed from live DNS queries.

Section 3, paragraph 2
>    As specified in Section 8 of [RFC2181], a TTL value is a "an unsigned
>    number, with a minimum value of 0, and a maximum value of 2147483647.
>    That is, a maximum of 2^31 - 1.".  TTL values are represented as JSON
>    numbers.

The normative requirement (Section 3.1) is that the TTL value MUST be 
an unsigned integer in the range 0–2,147,483,647. RFC 8259 (JSON) does not 
define a separate integer type; all numeric values use the same "number" 
type, which encompasses floats. If anything, the text in this document 
should explicitly state that the  JSON number MUST NOT contain a fractional 
component (e.g., 3600.5 is invalid). As written, a conformant JSON parser 
will accept 86400.5 without complaint, creating a gap between what JSON 
allows and what this specification intends.
Suggested addition to Section 3.1:

TTL values MUST be represented as JSON integers with no fractional component 
and no exponent notation.

Section 6, paragraph 1
>    This document only concerns itself with the representation of
>    configured TTL values for domain and host objects.  Such
>    configuration is out of scope.  Readers may refer to Section 6 of
>    [RFC9803] for the security implications of configuring those values.

The sentence "Such configuration is out of scope" after "This document 
only concerns itself with the representation of configured TTL values" 
is easy to misread — it sounds like the configured value itself is out 
of scope, not just the act of configuring it. Suggested rewording:

This document specifies how provisioned TTL values for domain and host 
objects are represented in RDAP responses. The security implications 
of how those TTL values are determined, assigned, or modified within 
a registry system are out of scope. Readers are directed to Section 6 
of [RFC9803] for that discussion.

# IESG review of draft-ietf-regext-rdap-ttl-extension-10

CC @MikeBishop

## Comments

### Section 1, paragraph 1

A sentence expanding RDAP (Registration Data Access Protocol) and
giving a brief definition/description would be helpful context.

### Section 3, paragraph 3

This implies that all records of a given type have the same TTL across
a given domain. Is that necessarily the case?

## Nits

All comments below are about very minor potential issues that you may choose to
address in some way - or ignore - as you see fit. Some were flagged by
automated tools (via https://github.com/larseggert/ietf-reviewtool), so there
will likely be some false positives. There is no need to let me know what you
did with these suggestions.

### Typos

#### Section 8.1, paragraph 3
```
-    2.  Made [RFC9499] a normative reference (thanks Ketan Talaulika)
+    2.  Made [RFC9499] a normative reference (thanks Ketan Talaulikar)
+                                                                    +
```

#### Section 9, paragraph 2
```
-    K.  Gurbani, Di Ma, Nabeel Cocker, Ketan Talaulika.
+    K.  Gurbani, Di Ma, Nabeel Cocker, Ketan Talaulikar.
+                                                      +
```

### Grammar/style

#### Section 3, paragraph 3
```
ection 8 of [RFC2181], a TTL value is a "an unsigned number, with a minimum v
                                      ^
```
Use "an" instead of "a" if the following word starts with a vowel sound, e.g.
"an article", "an hour".

You don't need an article both inside and outside the quotes.

#### Section 3, paragraph 4
```
483647. That is, a maximum of 2^31 - 1.". TTL values are represented as JSON 
                                     ^^^^
```
Unless punctuating an abbreviation or acronym, periods should not appear both
inside and outside of a quote.

Thank you to Vijay Gurbani for the GENART review.