Re: [regext] EPP Transport Service Discovery

[Jody Kolker <[e-mail]>]

>> .  . I believe the rate limiting and exclusivity or non-exclusivity on a single transport as server policy and out of scope for the definition of the transports.

+1 – that seems like server side policy and should not be handled here.

Thanks,
Jody Kolker
319-329-9805  (mobile)

Please contact my direct supervisor Scott Courtney ([e-mail]<mailto:[e-mail]>) 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 <[e-mail]> On Behalf Of Gould, James
Sent: Thursday, March 21, 2024 7:45 AM
To: ietf=[e-mail]; [e-mail]
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@.


We can look to add a section on signaling within the EoH and EoQ drafts that leverages the SVCB record.  I believe the rate limiting and exclusivity or non-exclusivity on a single transport as server policy and out of scope for the definition of the transports.

Thanks,

--

JG

[cid87442*image001.png@01D960C5.C631DA40]

James Gould
Fellow Engineer
[e-mail]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: regext <[e-mail]<mailto:[e-mail]>> on behalf of Kal Feher <ietf=[e-mail]<mailto:ietf=[e-mail]>>
Date: Thursday, March 21, 2024 at 8:37 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [EXTERNAL] Re: [regext] EPP Transport Service Discovery


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.

+1

this appears to be solving a problem that doesnt exist and is unlikely to exist.

for a multiple transport registry, I'd be more interesting in whether rate limit behaviour would be consistent between transports and whether clients are expected to be exclusively on a single transport at a time or can use both in parallel, which would be my preference.


On 21/3/2024 9:16 pm, Andrew Newton (andy) wrote:

Registries have a financial incentive to make sure registrars are kept

up to date, so your experience is almost certainly the norm. And I

agree that any service discovery mechanism that gets complicated is

not worth the effort in the registry/registrar space.



That said, George's idea of using an SVCB record seems pretty

straightforward and is low effort.



-andy





On Wed, Mar 20, 2024 at 9:14 PM Tobias Sattler

<tobias=[e-mail]><mailto:tobias=[e-mail]> wrote:



+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=[e-mail]><mailto:jkolker=[e-mail]> 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 ([e-mail]<mailto:[e-mail]>) 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 <[e-mail]><mailto:[e-mail]> On Behalf Of Steve Crocker

Sent: Wednesday, March 20, 2024 5:11 AM

To: Hollenbeck, Scott <shollenbeck=[e-mail]><mailto:shollenbeck=[e-mail]>

Cc: [e-mail]<mailto:[e-mail]>

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=[e-mail]><mailto:shollenbeck=[e-mail]> 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.  7200  IN SVCB 3 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

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/regext<https://secure-web.cisco.com/1CGrBi574rjgoLX16HhL8tJNpqrguaSIZ2pbFlJKmAaCutHwWxhlq1RJp839TYzs2BakkyH3JD5RCiUCi7Ak2330aNQDpsfKZpTVUSNJyiOUMNxMcIl0TmlJ2ozggfoLqiq-4uheVLzgvP4S5BtYOzJXGUt33NxMDxMKP_fLA-G_-iRaHz0_kRfVzhUudzI6LMTVY0C-jsLH_gHMBPuFEvR5gAAjagIHn88HF0HXJ00wuYF7_kI_aK_EE0RgCzkJwkBsfqFR4vZ5qN1gjcNcApLtYKmX2w30IhTNtCB4rBO0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>









--



Sent by a Verified



sender



_______________________________________________

regext mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/regext<https://secure-web.cisco.com/1CGrBi574rjgoLX16HhL8tJNpqrguaSIZ2pbFlJKmAaCutHwWxhlq1RJp839TYzs2BakkyH3JD5RCiUCi7Ak2330aNQDpsfKZpTVUSNJyiOUMNxMcIl0TmlJ2ozggfoLqiq-4uheVLzgvP4S5BtYOzJXGUt33NxMDxMKP_fLA-G_-iRaHz0_kRfVzhUudzI6LMTVY0C-jsLH_gHMBPuFEvR5gAAjagIHn88HF0HXJ00wuYF7_kI_aK_EE0RgCzkJwkBsfqFR4vZ5qN1gjcNcApLtYKmX2w30IhTNtCB4rBO0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>





_______________________________________________

regext mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/regext<https://secure-web.cisco.com/1CGrBi574rjgoLX16HhL8tJNpqrguaSIZ2pbFlJKmAaCutHwWxhlq1RJp839TYzs2BakkyH3JD5RCiUCi7Ak2330aNQDpsfKZpTVUSNJyiOUMNxMcIl0TmlJ2ozggfoLqiq-4uheVLzgvP4S5BtYOzJXGUt33NxMDxMKP_fLA-G_-iRaHz0_kRfVzhUudzI6LMTVY0C-jsLH_gHMBPuFEvR5gAAjagIHn88HF0HXJ00wuYF7_kI_aK_EE0RgCzkJwkBsfqFR4vZ5qN1gjcNcApLtYKmX2w30IhTNtCB4rBO0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>



_______________________________________________

regext mailing list

[e-mail]<mailto:[e-mail]>

https://www.ietf.org/mailman/listinfo/regext<https://secure-web.cisco.com/1CGrBi574rjgoLX16HhL8tJNpqrguaSIZ2pbFlJKmAaCutHwWxhlq1RJp839TYzs2BakkyH3JD5RCiUCi7Ak2330aNQDpsfKZpTVUSNJyiOUMNxMcIl0TmlJ2ozggfoLqiq-4uheVLzgvP4S5BtYOzJXGUt33NxMDxMKP_fLA-G_-iRaHz0_kRfVzhUudzI6LMTVY0C-jsLH_gHMBPuFEvR5gAAjagIHn88HF0HXJ00wuYF7_kI_aK_EE0RgCzkJwkBsfqFR4vZ5qN1gjcNcApLtYKmX2w30IhTNtCB4rBO0/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>