Two things buried in Joe’s message I want to build on: From: DNSOP <dnsop-boun...@ietf.org> on behalf of Joe Abley <jab...@strandkip.nl> Date: Wednesday, January 31, 2024 at 03:17 > >However, that will require new metadata to be bundled with domain registration >in transactions between registrant and registrar and between registrar and >registry.
One of the topics discussed was the boundary of the work. We don’t want to alter the namespace, at least not at the start. (I say “at least” as other progress may enable future features.) We don’t want to alter the management model, that would upend operations, not improve the operability of the system. And we don’t want to alter the “stub resolver experience” so that applications are not required to change. DELEG is meant to address the pain of operating the current publication protocol, the warts and rough edges in the messages and message passing. The impact on the registration system wasn’t raised at the table. I think implicitly, there was a desire to alter it for the better, namely in elevating the role of a DNS operator within registration (in having a registrant designate an operator). But I suppose for the initial phase we can try to define DELEG within the constraints of the existing registration system. But keep in mind that you can divide the registration system three ways (of course, more), some TLDs are operated under a contract that requires a specific set of standard behaviors (consisting of most generic TLDs), some TLDs (or ‘like TLDs’) are operated under various environments (mostly the jurisdiction TLDs, RIR’s and some NIR’s), and then there are registrations in all other parts of the DNS name space. So - working within current registration data flows would help get the first DELEG out the door, one of the early desires of DELEG is to address the lack of presence of the operator in registration which suggests changes in registration data flows. >There are various reasons why that might take a while, even in the most >optimistic success scenario for DELEG. What the global public Internet lacks is a Project Manager, and this is one reason why deployments drag on for decades. Incremental improvements need to be self-justifying, which is often not the case when investing in future infrastructure. I don’t see an Internet Project Management Task Force ever being created - as in there are no Protocol Police - so it’s important to make sure the goals and motivation or justification, are clearly documented. It’s said there is no profit in running DNS, DELEG is about cost reduction (more manageable, etc.).
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
