The Chairs would suggest that this question of the scope of the document can be considered after adoption. The authors have proposed a scope and any additional technical issues that you would like considered can be debated within the working group.
Thanks, Jorge, Antoin, Jim On 8 May 2026, at 9:08, Gould, James wrote: > I find it unusual that the working group would be working on rfc3915bis > without considering all the implementation issues of RFC 3915 based on the > concern of changing the XML namespace. If changing the XML namespace is the > issue, can we look to include some functionality that doesn't require a > change to the XML namespace, such as below? > > 1. Reference the use of the Change Poll Message with the RGP extension to > indicate to the registrar that the restore will expire and that it has > expired due to the lack of receiving the restore report with a two-step > restore. Use of the Change Poll Message for a future change is something new > but could be leveraged without changing the RGP XML schema and its XML > namespace. This would eliminate the need for a custom EPP extension, such as > https://www.verisign.com/assets/epp-sdk/verisign_epp-extension_rgp-poll_v01.html. > 2. Define the optional feature of including the RGP status expiry in the > status text message. This is not as good as having an "expiry" attribute, > but it would provide the feature without having to change the RGP XML schema > and its XML namespace. An example is <rgp:rgpStatus > s="addPeriod">endDate=2026-05-13T13:01:31Z</rgp:rgpStatus>. > 3. Make the use of the restore report optional and based on server policy. > The RGP State Diagram would need to be updated and the execution of the > single step restore request could be signaled to the client using a standard > EPP successful response without the inclusion of the RGP extension, which is > only used to indicate the setting of the "pendingRestore" RGP status when > using a two-step restore. This would be backward compatible and would not > require a change to the RGP XML schema and its XML namespace. > > Thanks, > > -- > > JG > > > > James Gould > Fellow Engineer > [email protected] > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > > > > On 5/8/26, 5:58 AM, "Pawel Kowalik" <[email protected] > <mailto:[email protected]>> wrote: > > > Hi, > > > As far as I can now notice, the document now does not change XML > namespace. This is IMHO a good choice. > > > In this form I support adoption with the small scope without any added > functionality. > > > Kind Regards, > Pawel > > > On 04.05.26 12:55, James Galvin wrote: >> Folks, >> >> IMPORTANT: PLEASE READ AND RESPOND IF APPROPRIATE FOR YOU. >> >> >> Strictly speaking, based on the fact that no one outside of the authors have >> indicated support for adopting this document, the adoption of this document >> should be rejected. However, this working group often makes exceptions, in >> large part because the number of working group members who are active is >> quite small compared to the typical IETF working group. In this case, the >> authors are all active participants, leaving extremely few others to express >> an opinion. >> >> So here’s the exception. >> >> The Chairs would suggest this document be adopted. Although we do not >> ordinarily base our decisions only on document author preferences, this is >> an update to an existing standard that should progress, in our opinion of >> course. If we adopt this document the working group will still have a >> decision point at which it can reject or revise these changes. >> >> Since this is an exception, we have not changed the status of the document >> just yet. While we will consider this document adopted, we are going to >> allow an additional week for any working group member to object this >> decision. If anyone objects, then this document will not be adopted and will >> revert to remaining on the list of “Candidate for Working Group Adoption”. >> The Chairs will work with the authors to consider the best path forward at >> that time. >> >> If no one objects during this week, the document status will change on 11 >> May 2026 and the Chairs will ask the authors to submit a draft named for the >> working group. >> >> The opportunity to object to the adoption of this draft, closes on Monday, >> 11 May 2026. >> >> Please reply to the list if you want to object and please indicate why you >> do not believe we should adopt this document. >> >> Thanks, >> >> Jim, Antoin, Jorge >> >> >> On 20 Apr 2026, at 15:33, James Galvin via Datatracker wrote: >> >>> This message starts a regext WG Call for Adoption of: >>> draft-carney-regext-rfc3915bis-02 >>> >>> This Working Group Call for Adoption ends on 2026-05-04 >>> >>> Abstract: >>> This document describes an Extensible Provisioning Protocol (EPP) >>> [RFC5730] extension mapping for the management of Domain Name System >>> (DNS) domain names subject to "grace period" policies. Grace period >>> policies exist to allow protocol actions to be reversed or otherwise >>> revoked during a short period of time after the protocol action has >>> been performed. This mapping extends the EPP domain name mapping >>> [RFC5731] to provide additional features required for grace period >>> processing. >>> >>> This document replaces the extension mapping for grace periods >>> described in [RFC3915], rendering that document obsolete. >>> >>> Please reply to this message and indicate whether or not you support >>> adoption >>> of this Internet-Draft by the regext WG. Comments to explain your preference >>> are greatly appreciated. Please reply to all recipients of this message and >>> include this message in your response. >>> >>> Authors, and WG participants in general, are reminded of the Intellectual >>> Property Rights (IPR) disclosure obligations described in BCP 79 [2]. >>> Appropriate IPR disclosures required for full conformance with the >>> provisions >>> of BCP 78 [1] and BCP 79 [2] must be filed, if you are aware of any. >>> Sanctions available for application to violators of IETF IPR Policy can be >>> found at [3]. >>> >>> Thank you. >>> [1] >>> https://secure-web.cisco.com/1znt267tr3-h8zizddMwtjeXudDSIHO1jB2ASeXQcVKwuHWotKpIVFE_PtZ4VDiXMBsUMLpo00ztHXjh2giWLhZJt39rhVjPLumXqVqFtwIzSsBVyVbaKNk00PMbyqbSWO0Dg5ZTanWWg44Hv_0EKb0-dsgpPb9dfcBD2Pp9G5fCt8e64-zegtLFdQml0pfV6VxE_qAfDwDSQVNTDn3PArGb0sz8x1yAqECCzNgF_CN1J3F3iAolIwtOtWe71YBjVCfgJnnc9XZnPYIRuKLSLSf2vXALaeB7X5zYyP75j6-kH7nqil3HoM_FWIPChSFN5/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fbcp78%2F >>> >>> <https://secure-web.cisco.com/1znt267tr3-h8zizddMwtjeXudDSIHO1jB2ASeXQcVKwuHWotKpIVFE_PtZ4VDiXMBsUMLpo00ztHXjh2giWLhZJt39rhVjPLumXqVqFtwIzSsBVyVbaKNk00PMbyqbSWO0Dg5ZTanWWg44Hv_0EKb0-dsgpPb9dfcBD2Pp9G5fCt8e64-zegtLFdQml0pfV6VxE_qAfDwDSQVNTDn3PArGb0sz8x1yAqECCzNgF_CN1J3F3iAolIwtOtWe71YBjVCfgJnnc9XZnPYIRuKLSLSf2vXALaeB7X5zYyP75j6-kH7nqil3HoM_FWIPChSFN5/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fbcp78%2F> >>> [2] >>> https://secure-web.cisco.com/1x513dYPAYRXvu6CEBRNFPNwtuGs1EXKwrt66LXuUNN9R2Qi3Jqs_bThx0RGaqpAhKl89LvjNUV4bs0MU3Nig_WQooNmMuaPzNr-L7kfTn5YF9bytO5ovJzQBGV2VJFTP7lyobHc1He6ak0qcah7SuwJ-9YNPcAj3AUoEUb1cYlqH7CarT6oag1NLj3KE9ci67rOGNeVZys-Tm8KyaLOSAFmkwGUna2QhT5TQlKNr9cGAXgr2vGFQAXNUTrIymFGViznm0nNPJcKQvOHF_zvZkQOH9eQFhsAl8fCQHYjxvfTikoMZm3qfDTFs3j9hGlHR/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fbcp79%2F >>> >>> <https://secure-web.cisco.com/1x513dYPAYRXvu6CEBRNFPNwtuGs1EXKwrt66LXuUNN9R2Qi3Jqs_bThx0RGaqpAhKl89LvjNUV4bs0MU3Nig_WQooNmMuaPzNr-L7kfTn5YF9bytO5ovJzQBGV2VJFTP7lyobHc1He6ak0qcah7SuwJ-9YNPcAj3AUoEUb1cYlqH7CarT6oag1NLj3KE9ci67rOGNeVZys-Tm8KyaLOSAFmkwGUna2QhT5TQlKNr9cGAXgr2vGFQAXNUTrIymFGViznm0nNPJcKQvOHF_zvZkQOH9eQFhsAl8fCQHYjxvfTikoMZm3qfDTFs3j9hGlHR/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fbcp79%2F> >>> [3] >>> https://secure-web.cisco.com/1CpalABMvSHZw5u9rPXVGcUGfCSdVFJ-sJSJGtzRmEjbR4uBySfLpT4_VtaQed2Pazr57MMN4_VFcPgCYeXJEQKw4PkHi7pPB80cjhUV7zB1cKQC81T8T-SnN1C6HOf5J8rHDSOtWebQyFTbgJzTelvKmFAUTasp0CYEoR-52dWi3-wGJyXA1-Zs8FEoohYlm7YWkhszA-VwWP7FH8BolakvhdZroAdWaNGi0DhtD-A7GE5_wb1xEZJstp6QwhQD8GdySPjJcAClmvjkLs2NePSzh_WXwXCIr4_U8-4BiPeFyHrcr0DksWSIAMQEjZRGd/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Frfc6701%2F >>> >>> <https://secure-web.cisco.com/1CpalABMvSHZw5u9rPXVGcUGfCSdVFJ-sJSJGtzRmEjbR4uBySfLpT4_VtaQed2Pazr57MMN4_VFcPgCYeXJEQKw4PkHi7pPB80cjhUV7zB1cKQC81T8T-SnN1C6HOf5J8rHDSOtWebQyFTbgJzTelvKmFAUTasp0CYEoR-52dWi3-wGJyXA1-Zs8FEoohYlm7YWkhszA-VwWP7FH8BolakvhdZroAdWaNGi0DhtD-A7GE5_wb1xEZJstp6QwhQD8GdySPjJcAClmvjkLs2NePSzh_WXwXCIr4_U8-4BiPeFyHrcr0DksWSIAMQEjZRGd/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Frfc6701%2F> >>> >>> The IETF datatracker status page for this Internet-Draft is: >>> https://secure-web.cisco.com/1vS_dNa08PwzkwBf6UXdEdYyEDjM4CkN_WXrVuCPdAxm-imEq6h1Q6rG4PWUTFgvA7lADfaO53Cl-e96vD9PebxVgFH9H9t6KsHzGkW5XVdXud1ysd9d3-KeouoZ9xVjN_Z5i5Ku77F9yzlnhbZ0kBkDAVXTkLmkw3ROjblOrLHiXK8JOAmf9kgbZk3CKH7QLs3IcjZ514vQZVCxHz22RcyW5UvvW1x_MWgzn7yCN_weNexH_awhJSEWeHimBGIGYNfnx6YUsSdVdYxfRl_XYsa9EkzsHNDlhbBwAx7dW1zUzpu97BQ6OUDjmFnQJmY2b/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-carney-regext-rfc3915bis%2F >>> >>> <https://secure-web.cisco.com/1vS_dNa08PwzkwBf6UXdEdYyEDjM4CkN_WXrVuCPdAxm-imEq6h1Q6rG4PWUTFgvA7lADfaO53Cl-e96vD9PebxVgFH9H9t6KsHzGkW5XVdXud1ysd9d3-KeouoZ9xVjN_Z5i5Ku77F9yzlnhbZ0kBkDAVXTkLmkw3ROjblOrLHiXK8JOAmf9kgbZk3CKH7QLs3IcjZ514vQZVCxHz22RcyW5UvvW1x_MWgzn7yCN_weNexH_awhJSEWeHimBGIGYNfnx6YUsSdVdYxfRl_XYsa9EkzsHNDlhbBwAx7dW1zUzpu97BQ6OUDjmFnQJmY2b/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-carney-regext-rfc3915bis%2F> >>> >>> There is also an HTMLized version available at: >>> https://secure-web.cisco.com/1a-X6dNoSTbcNDmp834xfPbnr0uAP8rPlxycZ1AzMkAn2CvV0PABJQM7DOmIHU8Fcb4n7UeefiKpMwiQdIbapNbGQm9_zIkNSqXXSypyR_ZblNl0EvRW8Hzj1iq7UEv_fyHYi3GEieWAWtYbX7P3P2Uva8SqL9mCbFDHxvC7PHBXTT2Tru5EuSAk_f09mE-XMW9hs_PoqqWMkAsvzne-3JWlOFbI857xgzXHwMHIsdiDDhK98Y5s9ie5yX0COPdJYH7Rh7e4ykuWp1v29JtTdQF7aR-tJ0gRFYihAvIK706ofZRej_bVKeUUVB6o2cH0L/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-carney-regext-rfc3915bis-02 >>> >>> <https://secure-web.cisco.com/1a-X6dNoSTbcNDmp834xfPbnr0uAP8rPlxycZ1AzMkAn2CvV0PABJQM7DOmIHU8Fcb4n7UeefiKpMwiQdIbapNbGQm9_zIkNSqXXSypyR_ZblNl0EvRW8Hzj1iq7UEv_fyHYi3GEieWAWtYbX7P3P2Uva8SqL9mCbFDHxvC7PHBXTT2Tru5EuSAk_f09mE-XMW9hs_PoqqWMkAsvzne-3JWlOFbI857xgzXHwMHIsdiDDhK98Y5s9ie5yX0COPdJYH7Rh7e4ykuWp1v29JtTdQF7aR-tJ0gRFYihAvIK706ofZRej_bVKeUUVB6o2cH0L/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-carney-regext-rfc3915bis-02> >>> >>> A diff from the previous version is available at: >>> https://secure-web.cisco.com/1LojbVgGLdL3mPJ8c1SWDybaldSWkcG4XmSCCjGkZFfPZN7Fj_feKBlC6yEuZNyqWOpie-wMk0KiEZ_Kfi97NAIVSpUC5-5xv77Vfbi85xmmV6DVGdyryd7MQNR90g_X24OACnpxTDlSZgWJ1SqE_XI7yFlInqDf2b8Natq5BGkGcrk8_BEqRtqAM3lEgXFD7O8JrYzhyVrR2Kcr6xYo-6lj1adTzxY5dxMt5qOOEX14YjbnK5lsa1GucqW9Ztj8gF_V-dMPObbVYsa4j9IWEq8LbJki_Ahm23UTg8exY7VxaUXjjP5FYa2QCNDiJsqx-/https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-carney-regext-rfc3915bis-02 >>> >>> <https://secure-web.cisco.com/1LojbVgGLdL3mPJ8c1SWDybaldSWkcG4XmSCCjGkZFfPZN7Fj_feKBlC6yEuZNyqWOpie-wMk0KiEZ_Kfi97NAIVSpUC5-5xv77Vfbi85xmmV6DVGdyryd7MQNR90g_X24OACnpxTDlSZgWJ1SqE_XI7yFlInqDf2b8Natq5BGkGcrk8_BEqRtqAM3lEgXFD7O8JrYzhyVrR2Kcr6xYo-6lj1adTzxY5dxMt5qOOEX14YjbnK5lsa1GucqW9Ztj8gF_V-dMPObbVYsa4j9IWEq8LbJki_Ahm23UTg8exY7VxaUXjjP5FYa2QCNDiJsqx-/https%3A%2F%2Fauthor-tools.ietf.org%2Fiddiff%3Furl2%3Ddraft-carney-regext-rfc3915bis-02> >> _______________________________________________ >> regext mailing list -- [email protected] <mailto:[email protected]> >> To unsubscribe send an email to [email protected] >> <mailto:[email protected]> _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
