The question is whether RPP would need to support 2 steps nevertheless, out of a factual reason that a client would want or need to complete step 1 without completing the step 2.
Kind Regards, Pawel On 04.11.25 17:22, James Galvin wrote:
I don’t know why either. I wasn’t involved in this early work directly. I’ll also note that ICANN processes were not quite as formal back then as they are today, so there are historical details that just aren’t available. What I will suggest though, is if the RPP doesn’t believe it needs the 2 step process and you’d like to go forward without it, the larger architectural question the IETF/RPP needs to ask is if it will ensure supporting transitioning from the use of it to not using it. This is a technical backwards compatibility question not an ICANN policy question. Is backwards compatibility with legacy systems a desired goal, or not? Jim On 4 Nov 2025, at 10:42, Hollenbeck, Scott wrote:-----Original Message----- From: Maarten Wullink <[email protected]> Sent: Tuesday, November 4, 2025 10:06 AM To: Hollenbeck, Scott <[email protected]> Cc: [email protected]; [email protected]; [email protected] Subject: [EXTERNAL] Re: [regext] [rpp] RGP (RFC3915) Restore report why? Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Scott, et al. reading the referenced documents i have a hard time finding what the actual arguments were for the 2 step process. would it also not have been possible to do a single restore operation that contains the report? the registrar, at the time of restore request, already knows the previous registration data and the current registration data ( registrant) and this is not something ICANN ORG mandates of course, its a result of the community process. so updating RGP should also be driven by ICANN community.[SAH] I don't know what the rationale was, either. We were just stuck with the outcome. Scott_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
