Michael, The prohibited statuses apply to client requests, which matches Case 2. The prohibited statuses can apply to client requests via multiple channels (e.g., EPP or Web UI). The prohibited statuses don't apply to server actions (e.g., auto renew, transitioning RGP statuses). Use of CDS/CDNSKEY records to signal a server-side change is an interesting case, where does posting CDS/CDNSKEY records represent a client request that is processed by the server asynchronously? I view the CDS/CDNSKEY as a new operation (e.g., DNSSEC automation update), supported by IETF RFCs, that does not apply to the existing EPP prohibited statuses. All domain changes come down to an update, but EPP included prohibited statuses on a per operation / command basis.
I would then define Case 3, where CDS/CDNSKEY records represent is a new client operation that does not apply to the existing EPP prohibited statuses. If we did want to prohibit this new operation via EPP, then a new prohibited status would be warranted. -- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 12/2/22, 6:41 AM, "regext on behalf of Michael Bauland" <regext-boun...@ietf.org on behalf of michael.baul...@knipp.de> wrote: Hello, I've recently come across a case in the context of CDS/CDNSKEY and I'm unsure what is the best/correct way to handle the situation. CDS/CDNSKEY records are meant to notify the registry about a change in the DS/DNSKEY records, similar to sending an EPP request. What should the registry do, if 1. the serverUpdateProhibited EPP state is set? 2. the clientUpdateProhibited EPP state is set? I tend to say that in Case 1, the domain may not be changed at all and as a consequence CDS/CDNSKEYs should be ignored. For Case 2 my preference is that this is only a kind of safeguard against unintended changes by the registrar, and the DNSSEC update is most likely intended and should go through. Furthermore, some registrars might set this state regularly, which would then take away the registrant's possibility to roll over their DNSKEY. This most likely is not intended. However, one could of course argue: update prohibited means update prohibited, and as long as that state is set, no changes (other than removing this state) should be possible. What do others think about these cases? Cheers, Michael -- ____________________________________________________________________ | | | knipp | Knipp Medien und Kommunikation GmbH ------- Technologiepark Martin-Schmeisser-Weg 9 44227 Dortmund Germany Dipl.-Informatiker Fon: +49 231 9703-0 Fax: +49 231 9703-200 Dr. Michael Bauland SIP: michael.baul...@knipp.de Software Development E-mail: michael.baul...@knipp.de Register Court: Amtsgericht Dortmund, HRB 13728 Chief Executive Officers: Dietmar Knipp, Elmar Knipp _______________________________________________ regext mailing list regext@ietf.org https://secure-web.cisco.com/1mEpKtXjsuVbK-xXNutAu2eLBX3bt-bjQqZChp1HEVcTMmoCcnfG_0hMFCo-Ofk6lXl_mTcEgh18oXp1y9xBCLBIC96tcHfPB2EzViMvxW7b5j7MPJ0Mmwlbi0E1p4cY-ho7Ovt1EDkg5DdwoskqCbaGAU0AEeESOH2-Zw3qYdWQruN3Wrvbt1WYQ7COdIo49RfNj5p2K_fzit1-pi_9yTtkVO8bl4Vok6E9VvpWGP2G8RhZhtB6Fr8LRi219iUiq6io42GCY1aX5J-qt52SPBvJsXQhqvz1q0GcNsZlPXX0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
