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]
