Hi Med, Thank you for the guidance and for pointing to DCONN as an example, that's exactly the kind of path I was hoping might be possible:
a focused, small WG to standardize an already working protocol. What is currently the best way to use the mailing list? Should I: - Wait
for more community feedback on the current thread? - Provide additional technical details or clarifications? Or take a different approach?
I’m happy to answer questions and provide any information that would help the community evaluate whether this work is worth pursuing. Thank
you for your time and support. Best regards, Andrea Ferro On Jan 14, 2026, at 7:05 AM, [email protected] wrote: Hi Andrea, Thank
you for reaching out dnsop for this work. I have one comment about “Which path makes sense?” part below. As with current WG charter, DNSOP
is responsible for DNS dispatch in the IETF. Here is the relevant charter excerpt: “DNS-related I-Ds that don't have an obvious WG which
could adopt them can be submitted to the DNSOP WG for consideration. The DNSOP WG will advise on the appropriate way to progress these
I-Ds, for instance by suggesting the most suitable WG or recommending the chartering of a new WG” With that in mind, I suggest that you
continue the discussion here in dnsop (including requesting a slot in the DISPATCH part of IETF#125) to hopefully converge on a recommended
next step for your draft. Cheers, Med (as DNSOP Area Director) PS: You may look at https://datatracker.ietf.org/group/dconn/about/ for an
example of a recently chartered tiny WG to exemplify which kind of changes may happen if the community decodes to take this work. De :
Andrea Ferro <[email protected]> Envoyé : mardi 13 janvier 2026 20:08 À : Joe Abley <[email protected]> Cc : [email protected] Objet
: [DNSOP] Re: Introducing draft-ferro-dnsop-apertodns-protocol-00.txt Hi Joe, Thank you for your thoughtful questions; they have helped me
clarify my thoughts. What is my goal? I want to establish a modern, open standard for dynamic DNS updates that can eventually replace the
current fragmented landscape. You described the problem perfectly "devices hand-picking from proprietary provider lists, each with
their own protocols". The current de facto "standard" is dyndns2, which Dyn documented on their website but never published
as a vendor-neutral specification. There's no RFC, just one company's API that others adopted by imitation. This space hasn't seen
meaningful evolution in 15 to 25 years, and I believe it deserves a proper, open standard. The protocol specification is published on
GitHub as a vendor-agnostic document, intentionally separate from ApertoDNS itself ( https://github.com/apertodns/apertodns-protocol ). It
includes compliance tests. There are already working implementations. I’m not proposing something theoretical, I'm looking to formalize
something that already works in production, and ideally see it grow into something the broader community can adopt and build upon. Why am I
doing this? Honestly, because I believe connectivity should be accessible to everyone. My guiding principle with ApertoDNS has been
"No Walls": no paywalls, no artificial restrictions. I'm not looking for commercial gain. I want to contribute something useful
that outlasts any single project or company. Which path makes sense? This is where I'd genuinely appreciate your guidance. Since my goal is
maximum adoption, becoming the standard that vendors actually implement,, it sounds like working group adoption might be the stronger path.
I'm open to that, but I'll admit I'm uncertain how the process works in practice. If a WG adopts the draft, what typically happens? Do
authors remain involved as editors? What kinds of changes are common? I raised this in dnsop because I wasn't sure where else to start. You
mentioned dnssd might be more natural. I'm happy to take it there if that's more appropriate. Or if you think ISE is actually the better
fit for what I'm describing, I'm open to that perspective too. I appreciate any guidance you can offer. Best regards, Andrea Ferro Il
giorno 13 gen 2026, alle ore 14:58, Joe Abley < [email protected] > ha scritto: Hi Andrea, I have often wished for a standard way
to do this kind of thing. It has always seemed crazy to see devices like consumer home gateways having to hand-pick from a large list of
ddns providers, each with their own protocols, in order to provide this kind of functionality. The ability so select an arbitrary,
interoperable provider (and potentially to discover one, based on some suitable heuristic) always seemed like an obvious thing to want. The
closest I ever found was wide-area bonjour (as described in this page, which I sense has not been updated in a long time, <
https://dns-sd.org/ClientSetup.html >). This worked for me quite nicely on Mac OS X up until some point 10-15 years ago when it didn't.
I remember opening my laptop in random IETF meetings and having my remote backup minions connect successfully over ssh to rsync copies of
my data back home. Back in those days this even seemed like a safe and sane thing to do. I had a quick skim through your draft, and the
immediate question that sprang to mind was: what is your goal, here? If the goal is to document an existing, useful protocol in the RFC
series, there are other avenues for that: you could find an AD willing to sponsor it or you could try the ISE. I presume your goal is to
create a stable reference that encourages interop? Have you considered why the RFC series is a good place for this, compared to (say) a web
page that you maintain yourself? What was your thinking? If the goal is to take an existing protocol as a starting point but then hand over
change control to an IETF working group, understanding that they might well change it in ways you would probably not have done yourself,
then finding a working group willing to adopt it is a good first step. Is that what you are doing? If a working group is the right venue
for this, why dnsop? I'm not saying dnsop would be the wrong place necessarily, but I'm interested in your thinking. Your protocol is
certainly DNS-adjacent but it's not really concerned with the operation of the DNS protocol, more in the provisioning of the namespace. To
be clear I am asking these questions because I am interested in your answers, not because I am criticising your instincts or dislike your
draft. I'm sure both your instincts and your draft are magnificent. :-) Joe On 13 Jan 2026, at 13:03, Andrea Ferro < [email protected] >
wrote: Hi DNDOP, My name is Andrea Ferro. I recently submitted an I-D proposing a standardized protocol for consumer Dynamic DNS services.
There is also an TXT version available at: https://www.ietf.org/archive/id/draft-ferro-dnsop-apertodns-protocol-00.txt The IETF datatracker
status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ferro-dnsop-apertodns-protocol/ There is also an HTML
version available at: https://www.ietf.org/archive/id/draft-ferro-dnsop-apertodns-protocol-00.html The motivation is simple: consumer DDNS
has been around for 25+ years (ddclient, inadyn, countless routers and IoT devices), but there's never been a formal specification.
Everyone just reverse-engineered the dyndns2 protocol and built their own variations. This has led to inconsistent implementations,
fragmented IPv6 support, and vendor lock-in. The draft proposes a RESTful alternative using well-known URIs (RFC 8615), JSON, and bearer
tokens. It's designed to be provider-agnostic - any DDNS service can implement it. I have a working implementation in production at
apertodns.com , so this isn't just theoretical. I'm looking for feedback on whether this is appropriate work for DNSOP, and whether there's
interest in adoption. Happy to present at a future session if useful. Best regards, Andrea Ferro [email protected]
_______________________________________________ DNSOP mailing list -- [email protected] To unsubscribe send an email to [email protected]
_________________ ______________________________ ______________________________ ______________________________ _ Ce message et ses pieces
jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans
autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les
messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou
falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they
should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and
delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or
falsified. Thank you.
_______________________________________________
DNSOP mailing list -- [email protected]
To unsubscribe send an email to [email protected]
