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 -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
