[regext] Re: Mahesh Jethanandani's No Objection on draft-ietf-regext-rdap-ttl-extension-10: (with COMMENT)

[Gavin Brown <[e-mail]>]

Hi Mahesh, thanks for your review!

The next version will address all of your points.

G.

On Mon, 18 May 2026, at 23:57, Mahesh Jethanandani via Datatracker wrote:
> Mahesh Jethanandani has entered the following ballot position for
> draft-ietf-regext-rdap-ttl-extension-10: No Objection
>
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
>
>
> Please refer to 
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
>
>
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-ttl-extension/
>
>
>
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> 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.
>
>
>
> _______________________________________________
> regext mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]