Hi David, Good points. Here is my current take on this:
(1) that we only focus on changing the policy to “Expert Review” for the following registries: * IPv4 Locally-Served DNS Zone Registry * IPv6 Locally-Served DNS Zone Registry but keep untouched these ones: * Transport-Independent Locally-Served DNS Zone Registry * service.arpa Subdomain (2) Add under the “Designated Expert Guidance” of the new I-D an instruction to check that an entry is also present in the Special address space registries. (3) Consider adding a note to the “Special Address Space” registries to mirror entries that have specific characteristics (e.g., as a function of Forwardable/Globally Reachable values). If we can’t think of an automatic rule for IANA to mirror certain registrations based on current columns, then maybe consider also updating RFC6890 to add a new column that will be filled when adding an entry into the special registry space registries. For example: NEW: Eligible to Locally-Served DNS Zones: A boolean value indicating whether the IP address block is to be added to the Locally-Served DNS Zones IANA registry. IANA has to add relevant entries for “Eligible to Locally-Served DNS Zones” set to “True” in the IPvx Locally-Served DNS Zone Registry. The Designated Experts will help IANA to create the reverse zones for such entries. This also an aspect to be discussed in “Designated Expert Guidance” Section of the new I-D. Of course, these are suggestions. Cheers, Med De : David Farmer <[email protected]> Envoyé : vendredi 21 novembre 2025 23:18 À : BOUCADAIR Mohamed INNOV/NET <[email protected]> Cc : V6 Ops List <[email protected]>; dnsop <[email protected]> Objet : Re: [v6ops] Expanded IPv6 Documentation Address Space and the "Locally-Served DNS Zones" registry Looking at this a little deeper, there are four sub-registries for the Locally-Served DNS Zones. The first two sub-registries, the IPv4 and IPv6 Locally-Served DNS Zone Registries, should be changed to "Expert Review". However, with an additional restriction that allows only address blocks from one of the Special-Purpose Address Space registries to be added to the corresponding Locally-Served DNS Zones registry. Except when an address block is concurrently added to both registries. Adding an address block to one of the Special-Purpose Address Space registries requires "IETF Review." Following that, "Expert Review" is probably sufficient if it was forgotten to be added to the Locally-Served DNS Zones registry, as is the case with the Expanded IPv6 Documentation Address Space. However, adding an address block to the IPv4 or IPv6 Locally-Served DNS Zone Registries effectively makes it a special-purpose address block. So, requiring Special-Purpose Address Space designation before or concurrent with the addition to the Locally-Served DNS Zone Registries seems appropriate. However, I'm not sure that "Expert Review" is the appropriate registry procedure for the other two sub-registries, the Transport-Independent Locally-Served DNS Zone Registry, and the service.arpa Subdomain registry. Thanks. On Thu, Nov 20, 2025 at 3:26 AM <[email protected]<mailto:[email protected]>> wrote: Hi David, all, (also adding dnsop) Adding 3fff::/20 to "Locally-Served DNS Zones" registry makes sense. However, given the registration policy of that registry and lack of a rule that would allow us to automatically add prefixes with similar properties to that registry, I checked with IANA and also consulted with the IESG colleagues about how we better handle this. Given also that future similar issues may happen (the DNS registry may not be known for other WGs, in particular), the suggested approach is to relax the registration policy of "Locally-Served DNS Zones" registry to “Expert Review” instead of “IETF Review”. This would be similar to the fix in https://datatracker.ietf.org/doc/rfc9650/ but for another registry. If there is a volunteer to write a short draft to fix this, and there are no objections to relax the registration policy, I think that this is a document that we can fast track in DNSOP (or even as AD sponsored). Comments are welcome. Cheers, Med De : David Farmer <[email protected]<mailto:[email protected]>> Envoyé : vendredi 17 octobre 2025 19:33 À : Nick Buraglio <[email protected]<mailto:[email protected]>>; Geoff Huston <[email protected]<mailto:[email protected]>>; V6Ops Chairs <[email protected]<mailto:[email protected]>> Cc : V6 Ops List <[email protected]<mailto:[email protected]>> Objet : [v6ops] Expanded IPv6 Documentation Address Space and the "Locally-Served DNS Zones" registry V6ops Chairs and RFC9637 Authors, I have been reviewing several IANA registries and noticed that the Expanded IPv6 Documentation Address Space 3fff::/20 has not been added to the "Locally-Served DNS Zones" registry. Given that RFC 9637 updates RFC 3849, and RFC 6303 referenced RFC 3849 and included 2001:db8::/32 (8.B.D.0.1.0.0.2.IP6.ARPA) in the "Locally-Served DNS Zones" registry [1], I believe 3fff::/20 (0.F.F.F.3.IP6.ARPA) should also be added to that registry, but it has not been added. What is the proper procedure to correct this? I think, with RFC 9637 and the "IETF Review" registration procedure for that registry, it should simply be a request to the IESG and/or IANA. Thanks. [1] https://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xhtml#ipv6 -- =============================================== David Farmer Email:[email protected]<mailto:email%[email protected]> Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== ____________________________________________________________________________________________________________ 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. -- =============================================== David Farmer Email:[email protected]<mailto:email%[email protected]> Networking & Telecommunication Services Office of Information Technology University of Minnesota 2218 University Ave SE Phone: 612-626-0815 Minneapolis, MN 55414-3029 Cell: 612-812-9952 =============================================== ____________________________________________________________________________________________________________ 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]
