Hi Ben, Thank you for your time and questions. Let me address each point directlyy.
1) Why not document the de facto standard? Dyn published their "Remote Access API" specification in the late 1990s, and it became widely adopted. However: - Proprietary documentation: The specification lives on help.dyn.com (now Oracle). There's no open governance, no vendor-neutral stewardship, and no formal process for proposing changes or extensions. - IPv6 was not part of the original design: Dyn's own documentation states that "certified update clients only support dynamic updates to IPv4 host records" [1]. IPv6 support was added later through various non-standard extensions, some providers use a myipv6= parameter, others require separate endpoints, others rely on connection-based auto-detection. This fragmentation causes ongoing interoperability issues, as documented in ddclient issues #607 [2], #769 [3], and #715 [4]. - Which version to document? Each provider has their own interpretation. An Informational RFC would need to acknowledge significant variation between implementations and could not point to a single canonical source. The draft itself (Appendix E, page 23) details the technical improvements over legacy protocols: JSON responses instead of plain text, bearer token authentication instead of HTTP Basic, explicit capability negotiation, standardized error codes, native IPv6 support with separate fields, and bulk update support - features that cannot be retrofitted into the legacy protocol without breaking existing implementations. 2) Does apertodns have a realistic chance of overtaking the de facto standard? ApertoDNS is designed for coexistence, not replacement, and this is a deliberate strategic choice, not a limitation. The specification includes a mandatory legacy compatibility layer (/nic/update endpoint), allowing providers to support both protocols simultaneously. This means zero migration cost: existing clients continue to work while new clients can use modern features. This is exactly how ApertoDNS operates in production today. The adoption path is already in motion: ApertoDNS was merged into OpenWRT ddns-scripts package this week. OpenWRT run of routers worldwide, providing immediate access to a massive user base. As providers adopt the protocol and users upgrade their firmware, adoption grows organically without forcing anyone to abandon working infrastructure. This incremental approach has proven successful for protocol transitions before, HTTPS coexisted with HTTP for years before becoming dominant. 3) On starting with an informational RFC I'm genuinely open to this approach. If the WG believes an Informational RFC documenting current practices would help focus interest in the topic, I'd be willing to contribute to such an effort. I'd note that such a document would essentially codify a proprietary vendor's API without addressing its architectural limitations. It might serve as useful historical documentation, but it wouldn't provide a foundation for future improvements; the IPv6 fragmentation problem, for example, cannot be solved without breaking backward compatibility with some existing implementations. Perhaps both tracks could proceed in parallel: an Informational RFC documenting current practices, and a Standards Track document proposing a modern alternative? Best regards, Andrea Ferro [1] https://help.dyn.com/managing-dynamic-updates.html [2] https://github.com/ddclient/ddclient/issues/607 [3] https://github.com/ddclient/ddclient/issues/769 [4] https://github.com/ddclient/ddclient/issues/715
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
