+1 During my 14-year tenure on the registrar side, where we implemented almost every gTLD and many ccTLDs, I always felt well-informed by registries if they intended to make substantial changes. While this feature seems nice, I don’t know if the effort is worth it.
Best, Tobias > On 20. Mar 2024, at 12:59, Jody Kolker <jkolker=40godaddy....@dmarc.ietf.org> > wrote: > > Just adding my 2 cents. > > It seems that designing and implementing a discovery system seems to be a bit > complicated and will take some time to design and complete. Every registry > will be contacting registrars when a new system is enabled, or at least > should be. I don’t see a huge benefit of adding a service discovery system > compared to the amount of time it will take to design and implement. I would > rather we spend our time defining the separate transport system than > designing a discovery system. > > > Thanks, > Jody Kolker > 319-329-9805 (mobile) > > Please contact my direct supervisor Scott Courtney (scourt...@godaddy.com > <mailto:scourt...@godaddy.com>) with any feedback. > > This email message and any attachments hereto is intended for use only by the > addressee(s) named herein and may contain confidential information. If you > have received this email in error, please immediately notify the sender and > permanently delete the original and any copy of this message and its > attachments. > > From: regext <regext-boun...@ietf.org> On Behalf Of Steve Crocker > Sent: Wednesday, March 20, 2024 5:11 AM > To: Hollenbeck, Scott <shollenbeck=40verisign....@dmarc.ietf.org> > Cc: regext@ietf.org > Subject: Re: [regext] EPP Transport Service Discovery > > Caution: This email is from an external sender. Please do not click links or > open attachments unless you recognize the sender and know the content is > safe. Forward suspicious emails to isitbad@. > > > Scott, et al, > > This seems to me an excellent idea, but let me suggest adding a bit more > content. > > And before doing so, let me acknowledge that a registry will likely inform > its registrars well in advance of any changes and will likely provide a test > system for registers to use in advance of a cutover to a new transport > system. But rather than depending on this alone, an automated process for > discovering the transport will be very helpful. > > And now for the added content: > > If a registry upgrades to a new transport method, it will likely operate both > the old and new transport for a period of time. Indeed, it might even > support three or more transport methods during some periods. Accordingly, > the response to a service discovery query will likely contain multiple > answers. Each answer should also include a flag indicating whether it is a > preferred method. > > But wait, there's more. > > Each transport method will go through a lifecycle. The transport method > lifecycle has the following states. > > A. Announcement that the method will be supported in the future. (Including > the anticipated date is a good idea, but the date should be interpreted as a > guess, not a certainty.) > > B. Announcement that the method is now supported. Include the date it became > supported. (A transport method in this state is "preferred." There should > be at least one method in this state, but there could be more than one.) > > C. Announcement that the method that has been supported is scheduled to be > removed. Include the estimated date of removal. This will serve as notice > that any registrar still using the transport should move to another available > method that has reached state B. (And, of course, there should indeed > already be at least one method in state B.) > > D. Announcement that the method will become unavailable on a specific date. > (All use of a method in this state should have ceased. However, if the > method is still in use by a registrar, it will work. The registry's system > or other monitoring systems can take note and escalate attention to the > appropriate managers,) > > E. Removal of the transport method from the set of answers. > > Extension of the proposal to include these states is easy. Just add a flag > to indicate whether the transport method is in state A, B, C or D, and > include the date. > > Comments? > > Steve > > > On Tue, Mar 19, 2024 at 7:11 PM Hollenbeck, Scott > <shollenbeck=40verisign....@dmarc.ietf.org > <mailto:40verisign....@dmarc.ietf.org>> wrote: > As noted during this morning’s regext session, we need to consider how a > client can discover the transport services provided by an EPP server. > Opportunistic probing is one method, another is server capability publication > using something like an SVCB record that’s published in a DNS zone maintained > by the EPP server operator. Perhaps something like this: > > epp.example.net <http://epp.example.net/>. 7200 IN SVCB 3 epp.example.net > <http://epp.example.net/>. ( > alpn="bar" port="700" transport="tcp") > > There is no “transport” SvcParamKey currently registered with IANA, but > that’s easy to do. I think there’s a draft here that needs to be written. > > Scott > _______________________________________________ > regext mailing list > regext@ietf.org <mailto:regext@ietf.org> > https://www.ietf.org/mailman/listinfo/regext > > > -- > Sent by a Verified > <https://wallet.unumid.co/authenticate?referralCode=tcp16fM4W47y> > sender > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
