Re: [regext] CALL FOR ADOPTION: draft-hollenbeck-regext-epp-delete-bcp
+1. As I said in my original request: "The authors believe it's in good shape given the feedback received to date and it may be close to ready for working group last call if the working group agrees with our descriptions of the documented practices and recommendations for those that we consider "best"." Scott > -Original Message- > From: regext On Behalf Of Antoin Verschuren > Sent: Monday, January 29, 2024 10:18 AM > To: regext > Subject: [EXTERNAL] [regext] CALL FOR ADOPTION: draft-hollenbeck-regext- > epp-delete-bcp > > 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. > > This is the formal adoption request for Best Practices for Deletion of Domain > and Host Objects in the Extensible Provisioning Protocol (EPP): > > https://secure- > web.cisco.com/1_UAAjuyS968d0PfUDQplLlEbM2HrAeqyPFDacDcY1TVg86ZG > jtuwGTxBIat8ByrDzv6iZipevaCJC-r1Dz7ow8zLxHYzKkpGmfM- > vBO175j_vPXjd06ew4aEL55EE9UbfD41AeAR7roUMcRSvcI29t3hSrUYCDcs0V > vbH6FEQ8JmG142LFXxHDOoDF8kwEef76oNOHiF4ksfCneeC6V2tznbeLnlcWf > YfEusus15SeR8qP3NkXmLPI5sbrTahc73Yz6fkkeIuPQpceEk_I1h91nK2mUYA8 > 3vfHMHWtpY4l- > iyuYoaGEHoKhc6feFHEzb/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdr > aft-hollenbeck-regext-epp-delete-bcp%2F > > Please review this draft to see if you think it is suitable for adoption by > REGEXT > and comment to this message on the list, clearly stating your view. > Andy Newton already volunteered to be a document shepherd this item will > be adopted. > > This Call For Adoption will close on Monday 12 February. > > If there are no objections, the chairs will consider this document adopted. > > Thanks, > > Your REGEXT co-chairs Jim and Antoin > > ___ > regext mailing list > regext@ietf.org > https://secure-web.cisco.com/1o5csDW0rnh- > iAPWNUpdQq33BxnAEya4jlO6c4ml3AKI788O3MH2DM0Q4gFDdgYHXqJGv- > RlAWWSQs- > 27cK0EhNm3RxBzzPLtSCAldnq4hlTuh60ME9PU0BWF4ZMHCRFYgGUYUwUa > u5bq2ExFK78iI0Pc55mO_vvZ5wA2EpDL78Dq1hjgkzZEICpURFK5g-OSv- > AfcLCIiJhMghsMsmE5HhwaQVE6F6BLIIPiCWroO-_YnOjj-iAwUq_0B- > NzKsToAEjZMqq_siAcRfwpGf7SBq5n52Xh8AHPNW2- > JiQyVrbwMdUmA168KN_iZlc2IEz- > /https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] The REGEXT WG has placed draft-newton-regext-rdap-x-media-type in state "Candidate for WG Adoption"
The REGEXT WG has placed draft-newton-regext-rdap-x-media-type in state Candidate for WG Adoption (entered by Antoin Verschuren) The document is available at https://datatracker.ietf.org/doc/draft-newton-regext-rdap-x-media-type/ ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] The REGEXT WG has placed draft-newton-regext-rdap-simple-contact in state "Candidate for WG Adoption"
The REGEXT WG has placed draft-newton-regext-rdap-simple-contact in state Candidate for WG Adoption (entered by Antoin Verschuren) The document is available at https://datatracker.ietf.org/doc/draft-newton-regext-rdap-simple-contact/ ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] The REGEXT WG has placed draft-newton-regext-rdap-extensions in state "Candidate for WG Adoption"
The REGEXT WG has placed draft-newton-regext-rdap-extensions in state Candidate for WG Adoption (entered by Antoin Verschuren) The document is available at https://datatracker.ietf.org/doc/draft-newton-regext-rdap-extensions/ ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] The REGEXT WG has placed draft-gould-regext-rdap-versioning in state "Candidate for WG Adoption"
The REGEXT WG has placed draft-gould-regext-rdap-versioning in state Candidate for WG Adoption (entered by Antoin Verschuren) The document is available at https://datatracker.ietf.org/doc/draft-gould-regext-rdap-versioning/ ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] ACTION REQUESTED: Re: RDAP-X draft adoption
As a reminder, the Chairs have suggested having an interim meeting as described below. There were no objections to this suggestion and 4 expressions of support. However, the Chairs have found themselves unable to find time to schedule this meeting. Here is what we propose. Next week, the Chairs will start a WG Adoption request for the following three documents as a package: https://datatracker.ietf.org/doc/draft-gould-regext-rdap-versioning/ https://datatracker.ietf.org/doc/draft-newton-regext-rdap-extensions/ https://datatracker.ietf.org/doc/draft-newton-regext-rdap-x-media-type/ These documents will then form the starting point for the discussion to be had. The Chairs will open the discussion at the REGEXT meeting during IETF119. Unfortunately, we won’t have a lot of time for an extended working session; what we will seek to accomplish is an understanding of what problem we want to solve. In addition, we will plan for an interim meeting during April that will be a working session to continue this discussion in detail. If anyone has any questions or concerns about this path please do reply on list. If there are no objections this is how the Chairs will proceed. Thanks, Antoin and Jim On 11 Dec 2023, at 9:09, James Galvin wrote: The Chairs have caught up on this thread and have the following proposal for the working group We suggest that the working group take on the problem space of considering negotiation, signaling, and versioning in RDAP. To properly consider this problem space we should adopt as working group documents the following three drafts, all of which address at least part of this problem space: https://datatracker.ietf.org/doc/draft-gould-regext-rdap-versioning/ (-02 just posted) https://datatracker.ietf.org/doc/draft-newton-regext-rdap-extensions/ https://datatracker.ietf.org/doc/draft-newton-regext-rdap-x-media-type/ In general, our goal as a working group is to have one solution on the standards track to a problem. After we have adopted these documents the working group will have to answer at least two questions: 1. Is there one problem to be solved or more than one? 2. Is there one solution or, if there are multiple problems, do we need multiple solutions? These are technical questions based on use cases that have been discussed. The Chairs also suggest that we have an interim meeting, perhaps in late January or early February, during which we have a focused discussion seeking answers to those two questions, studying the value and benefits of each of the proposals in the documents above. The Chairs will address the logistics of an interim meeting after we have adopted these documents. In addition, there is the question of whether or not the solution(s) to be proposed impact the following two documents: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/ https://datatracker.ietf.org/doc/draft-newton-regext-rdap-simple-contact/ The Chairs suggest that the simple-contact document should also be adopted, to move forward on the Experimental track with jsContact, and that we consider if either is impacted by the solution(s) to be proposed. Thanks, Antoin and Jim On 14 Nov 2023, at 18:26, Jasdip Singh wrote: Hello Antoin, Jim, Given the ongoing discussion on how to negotiate extensions between RDAP clients and servers (using HTTP headers versus query parameters), be it for SimpleContact [1], JSContact [2], or versioning in RDAP [3], Andy and I want to request a call for WG adoption of the RDAP-X draft [4]. We believe that the HTTP headers-based approach could help unify extensions negotiation across the RDAP ecosystem. Thanks, Jasdip & Andy [1] https://datatracker.ietf.org/doc/draft-newton-regext-rdap-simple-contact/ [2] https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/ [3] https://datatracker.ietf.org/doc/draft-gould-regext-rdap-versioning/ [4] https://datatracker.ietf.org/doc/draft-newton-regext-rdap-x-media-type/ ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] CALL FOR ADOPTION: draft-hollenbeck-regext-epp-delete-bcp
This is the formal adoption request for Best Practices for Deletion of Domain and Host Objects in the Extensible Provisioning Protocol (EPP): https://datatracker.ietf.org/doc/draft-hollenbeck-regext-epp-delete-bcp/ Please review this draft to see if you think it is suitable for adoption by REGEXT and comment to this message on the list, clearly stating your view. Andy Newton already volunteered to be a document shepherd this item will be adopted. This Call For Adoption will close on Monday 12 February. If there are no objections, the chairs will consider this document adopted. Thanks, Your REGEXT co-chairs Jim and Antoin ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
[regext] The REGEXT WG has placed draft-hollenbeck-regext-epp-delete-bcp in state "Call For Adoption By WG Issued"
The REGEXT WG has placed draft-hollenbeck-regext-epp-delete-bcp in state Call For Adoption By WG Issued (entered by Antoin Verschuren) The document is available at https://datatracker.ietf.org/doc/draft-hollenbeck-regext-epp-delete-bcp/ ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search
I'd very much prefer to stay with a literal reading of what's in RFC 9083: "A response to a "help" request will include identifiers for all of the specifications supported by the server. A response to any other request will include only identifiers for the specifications used in the construction of the response. The set of returned identifiers MAY vary depending on the authorization level of the client." Scott > -Original Message- > From: regext On Behalf Of James Galvin > Sent: Monday, January 29, 2024 9:59 AM > To: Tom Harrison > Cc: Mario Loffredo ; Antoin > Verschuren ; regext > Subject: [EXTERNAL] Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir- > search > > 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. > > Speaking as your Chairs: > > Mario brings up an interesting question for which the Chairs need to hear > some other opinions. > > On the one hand, there does seem to be some ambiguity regarding the proper > use of the rdapConformance array. If this is a concern, then the Chairs > believe > that the WG needs to decide which way they would like to resolve this > question. More importantly, the question is substantive and we will need to > close the WG Last Call, resolve the issue, and then proceed with another WG > Last Call. > > On the other hand, this ambiguity does not seem to be of broad concern. If > that’s true, then the document as currently written could be left as is, the > WG > Last Call could be closed, and if the remaining changes are confirmed to be > editorial then the document can be submitted to the IESG. > > Do WG members believe this issue is of concern and needs to be resolved? > > Please respond on the list. If there are no concerns then the document will > be > left as is and the WG Last Call will be closed on Sunday, 4 February 2024. > > Antoin and Jim > > > > On 28 Jan 2024, at 19:36, Tom Harrison wrote: > > > Hi Mario, > > > > On Fri, Jan 26, 2024 at 09:21:16AM +0100, Mario Loffredo wrote: > >> Il 26/01/2024 04:29, Tom Harrison ha scritto: > >>> On Thu, Nov 30, 2023 at 08:21:42AM +0100, Mario Loffredo wrote: > 2) Per what is stated in section 4.1 0f RFC9083, the > rdapConformance array in the examples Section 4 should include only > the extensions used in the response. > For sure the response including the ipSearchResults array will > never include the autnumSearchResults array and viceversa ;-) The > same goes for the responses including the links about ips or > autnums. Instead, the help response should include all the > extensions implemented. As a result of this, the first two > paragraphs of Section 6 should be modified as well. > >>> > >>> We think that the existing text/behaviour should be left as-is in > >>> this respect. Section 4.1 of 9083 says: > >>> > >>> A response to a "help" request will include identifiers for all of > >>> the specifications supported by the server. A response to any > >>> other request will include only identifiers for the specifications > >>> used in the construction of the response. > >>> > >>> and that any response which makes use of any part of the RIR search > >>> specification should therefore include all of the identifiers > >>> defined by the RIR search specification, since each of those > >>> identifiers will be "for [one of] the specifications used in the > >>> construction of the response". An alternative reading along the > >>> lines of your suggestion would require associating identifiers with > >>> specific functionality in the document. While that's relatively > >>> straightforward in this case, it would require extra, possibly > >>> unintuitive guidance in the document as to when identifiers should > >>> be included. It's also not clear that it yields much benefit for > >>> the client, either: while it would be possible in theory for a > >>> client to implement/understand only part of an extension, such that > >>> a response with a subset of the available identifiers could be > >>> processed without having to go to the trouble of > >>> implementing/understanding the whole extension, that doesn't seem > >>> like something that would come up much in practice, given that most > extensions are quite short/straightforward. What do you think? > >> > >> Think it would be good to involve the WG in the diiscussion. > >> Literally RFC 9083 states that only the identifiers of those > >> extensions used in building a response can be included in the > >> rdapConformance array. > >> > >> Have always thought that its purpose was to inform clients about the > >> extension prefixes they should be ready to recognize when > >> deserializing the response. > > > > I'm not sure that it's limited to extension prefixes for the purposes > > of deserialisation only. For example, the core extension identifier > > for the NRO
Re: [regext] WG LAST CALL draft-ietf-regext-rdap-rir-search
Speaking as your Chairs: Mario brings up an interesting question for which the Chairs need to hear some other opinions. On the one hand, there does seem to be some ambiguity regarding the proper use of the rdapConformance array. If this is a concern, then the Chairs believe that the WG needs to decide which way they would like to resolve this question. More importantly, the question is substantive and we will need to close the WG Last Call, resolve the issue, and then proceed with another WG Last Call. On the other hand, this ambiguity does not seem to be of broad concern. If that’s true, then the document as currently written could be left as is, the WG Last Call could be closed, and if the remaining changes are confirmed to be editorial then the document can be submitted to the IESG. Do WG members believe this issue is of concern and needs to be resolved? Please respond on the list. If there are no concerns then the document will be left as is and the WG Last Call will be closed on Sunday, 4 February 2024. Antoin and Jim On 28 Jan 2024, at 19:36, Tom Harrison wrote: > Hi Mario, > > On Fri, Jan 26, 2024 at 09:21:16AM +0100, Mario Loffredo wrote: >> Il 26/01/2024 04:29, Tom Harrison ha scritto: >>> On Thu, Nov 30, 2023 at 08:21:42AM +0100, Mario Loffredo wrote: 2) Per what is stated in section 4.1 0f RFC9083, the rdapConformance array in the examples Section 4 should include only the extensions used in the response. For sure the response including the ipSearchResults array will never include the autnumSearchResults array and viceversa ;-) The same goes for the responses including the links about ips or autnums. Instead, the help response should include all the extensions implemented. As a result of this, the first two paragraphs of Section 6 should be modified as well. >>> >>> We think that the existing text/behaviour should be left as-is in this >>> respect. Section 4.1 of 9083 says: >>> >>> A response to a "help" request will include identifiers for all of >>> the specifications supported by the server. A response to any >>> other request will include only identifiers for the specifications >>> used in the construction of the response. >>> >>> and that any response which makes use of any part of the RIR search >>> specification should therefore include all of the identifiers defined >>> by the RIR search specification, since each of those identifiers will >>> be "for [one of] the specifications used in the construction of the >>> response". An alternative reading along the lines of your suggestion >>> would require associating identifiers with specific functionality in >>> the document. While that's relatively straightforward in this case, >>> it would require extra, possibly unintuitive guidance in the document >>> as to when identifiers should be included. It's also not clear that >>> it yields much benefit for the client, either: while it would be >>> possible in theory for a client to implement/understand only part of >>> an extension, such that a response with a subset of the available >>> identifiers could be processed without having to go to the trouble of >>> implementing/understanding the whole extension, that doesn't seem like >>> something that would come up much in practice, given that most >>> extensions are quite short/straightforward. What do you think? >> >> Think it would be good to involve the WG in the diiscussion. >> Literally RFC 9083 states that only the identifiers of those >> extensions used in building a response can be included in the >> rdapConformance array. >> >> Have always thought that its purpose was to inform clients about the >> extension prefixes they should be ready to recognize when >> deserializing the response. > > I'm not sure that it's limited to extension prefixes for the purposes > of deserialisation only. For example, the core extension identifier > for the NRO RDAP profile (i.e. nro_rdap_profile_0) is not used as a > prefix for any response fields, but is still included in most > responses from a server that implements that profile, since the > behaviour defined there affects how the response is > constructed/interpreted. > >> For this reason, including in the rdapConformance array an extension >> identifier that is not used in the response could be misleading for >> clients. >> >> Besides, mentioning in rdapConformance only the extensions used in >> the response doesn't mean that either the server or the client can >> have a partial knowledge of the specification defining them. > > It's at least possible to imagine a scenario where this is the case, > even if it may be unlikely to happen in practice. Under the approach > you have set out, a specification that defines two or more extension > identifiers needs to describe when those extension identifiers should > be included in responses. If one identifier is used for behaviour > that is specific to that
[regext] regext - New Meeting Session Request for IETF 119
A new meeting session request has just been submitted by Antoin Verschuren, a Chair of the REGEXT Working Group. - Working Group Name: Registration Protocols Extensions Area Name: Applications and Real-Time Area Session Requester: Antoin Verschuren Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 50 Conflicts to Avoid: Chair conflict: dnsop dance saag tigress sidrops savnet grow Key participant conflict: dispatch secdispatch Participants who must be present: Resources Requested: Special Requests: - ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] Call for agenda items IETF119
I don't need presentation timer, but I would like to ask that my request for working group adoption of "draft-hollenbeck-regext-epp-delete-bcp" be discussed if it's not addressed before the meeting. Scott > -Original Message- > From: regext On Behalf Of Antoin Verschuren > Sent: Saturday, January 27, 2024 10:08 AM > To: regext > Subject: [EXTERNAL] [regext] Call for agenda items IETF119 > > 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. > > Hi all, > > It is time to schedule our session for IETF 119 next week. > Since we had too little time scheduled for IETF 118 where we filled our > complete 1,5 hour time slot, we are thinking of requesting 2 hours this time > if > people come up with enough agenda items. > We see enough reasons on the list that may justify a longer slot this time, > and > he chairs also suggested to organise an interim meeting to discuss the > negotiation, signalling, and versioning in RDAP, which we unfortunately failed > to do due to prolonged and conflicting holiday scheduling over the new year > by the chairs, so we may schedule that in Brisbane too. > > So if you already have agenda items, please let the chairs know, so we can > justify requesting 2 hours of meeting time in Brisbane. > > Regards, > > Your REGEXT co-chairs Jim and Antoin > > > > > > ___ > regext mailing list > regext@ietf.org > https://secure-web.cisco.com/19CWuXwISndZ6V3DKAJO_Ohqg2Ey-skq- > 2H8Z0d9PTVPajXndKAw6wqCujh5a79hlM1wFNccL4KzbRkIzen4xcjXaC02mH > aTPTsKxVY3bSwvrPqaMMdym1AXzCDaOhkPfGH_07U8U8J5Of8Npr1VWuX > m8cTyFiLBvsJWNmo5- > IebUFMfDNimpEQCGbMiTIEkwjGoEF6I9T9JnVbAYhfxOfImzgD8hSjQC6BrrB1 > 1HgXs8zhHwiKTRB1nRvyYBahkteLHh7qNVkA2NDfqPe3DspgvmGLtotXV0YwT > PfnYOus4/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] [Ext] Call for agenda items IETF119
Hi Antoin and Jim, I would like to present the following: * draft-ietf-regext-epp-ttl (5 mins should be enough) * draft-brown-rdap-ttl-extension (5 mins) * draft-brown-epp-deleg[1] (5-10 mins) I am happy to yield on the latter two if others need time for their presentations. [1] is also being discussed during the DNSOP interim on Wednesday. G. > On 27 Jan 2024, at 15:08, Antoin Verschuren > wrote: > > Hi all, > > It is time to schedule our session for IETF 119 next week. > Since we had too little time scheduled for IETF 118 where we filled our > complete 1,5 hour time slot, we are thinking of requesting 2 hours this time > if people come up with enough agenda items. > We see enough reasons on the list that may justify a longer slot this time, > and he chairs also suggested to organise an interim meeting to discuss the > negotiation, signalling, and versioning in RDAP, which we unfortunately > failed to do due to prolonged and conflicting holiday scheduling over the new > year by the chairs, so we may schedule that in Brisbane too. > > So if you already have agenda items, please let the chairs know, so we can > justify requesting 2 hours of meeting time in Brisbane. > > Regards, > > Your REGEXT co-chairs Jim and Antoin > > > > > > ___ > regext mailing list > regext@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/regext__;!!PtGJab4!-R8-coMHyTpJs2cx1rrT50_63TuWXTB3nHIfKQZT-qxGeD_MQDL0sxn6nsC7BfXDu3YYIR0MVYZ1LHCS3o62qEyQf9x5I7YfVYD2XIoB$ > [ietf[.]org] -- Gavin Brown Principal Engineer, Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) https://www.icann.org ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
Re: [regext] [Ext] I-D Action: draft-ietf-regext-epp-ttl-05.txt
Hi all, This version updates the extension with Jim's feedback, so that the min/default/max attributes on elements are only included in responses if the client includes in the command. I haven't received much feedback other than Jim's, so apart from fixing any minor issues that may be found and reported, I think this document may be ready for WGLC, although I am expecting the DNS Directorate may have some suggestions. If you have implemented this extension in a client or server, please let me know so I can details to the "Implementation Status" section of the draft. I am in the process of adding support to Pepper[1], after which we'll have two independent implementations which IIRC is the preferred minimum number. So if you have feedback, speak now or lose your right to say "I told you so" in future :) G. [1] https://github.com/gbxyz/pepper > On 26 Jan 2024, at 14:24, internet-dra...@ietf.org wrote: > > Internet-Draft draft-ietf-regext-epp-ttl-05.txt is now available. It is a work > item of the Registration Protocols Extensions (REGEXT) WG of the IETF. > > Title: Extensible Provisioning Protocol (EPP) mapping for DNS > Time-To-Live (TTL) values > Author: Gavin Brown > Name:draft-ietf-regext-epp-ttl-05.txt > Pages: 26 > Dates: 2024-01-26 > > Abstract: > > This document describes an extension to the Extensible Provisioning > Protocol (EPP) that allows EPP clients to manage the Time-To-Live > (TTL) value for domain name delegation records. > > About this draft > > This note is to be removed before publishing as an RFC. > > The source for this draft, and an issue tracker, may can be found at > > https://urldefense.com/v3/__https://github.com/gbxyz/epp-ttl-extension__;!!PtGJab4!_DepdCBuQNU9w6ND2zQe5XDlZbAu2n5vHRWy8p3aQ8IDqC0AuYVlCHl0xDgKlGI9BPLrHP_sYzzV8Zq28SiTGlPyjC3VaYPVTA$ > [github[.]com]. > > The IETF datatracker status page for this Internet-Draft is: > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-ietf-regext-epp-ttl/__;!!PtGJab4!_DepdCBuQNU9w6ND2zQe5XDlZbAu2n5vHRWy8p3aQ8IDqC0AuYVlCHl0xDgKlGI9BPLrHP_sYzzV8Zq28SiTGlPyjC1SM_JvMA$ > [datatracker[.]ietf[.]org] > > There is also an HTMLized version available at: > https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-ietf-regext-epp-ttl-05__;!!PtGJab4!_DepdCBuQNU9w6ND2zQe5XDlZbAu2n5vHRWy8p3aQ8IDqC0AuYVlCHl0xDgKlGI9BPLrHP_sYzzV8Zq28SiTGlPyjC0Bw5LmWA$ > [datatracker[.]ietf[.]org] > > A diff from the previous version is available at: > https://urldefense.com/v3/__https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-epp-ttl-05__;!!PtGJab4!_DepdCBuQNU9w6ND2zQe5XDlZbAu2n5vHRWy8p3aQ8IDqC0AuYVlCHl0xDgKlGI9BPLrHP_sYzzV8Zq28SiTGlPyjC0sxk-WpA$ > [author-tools[.]ietf[.]org] > > Internet-Drafts are also available by rsync at: > rsync.ietf.org::internet-drafts > > > ___ > regext mailing list > regext@ietf.org > https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/regext__;!!PtGJab4!_DepdCBuQNU9w6ND2zQe5XDlZbAu2n5vHRWy8p3aQ8IDqC0AuYVlCHl0xDgKlGI9BPLrHP_sYzzV8Zq28SiTGlPyjC1cKEx7Pw$ > [ietf[.]org] -- Gavin Brown Principal Engineer, Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) https://www.icann.org ___ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
