Re: [regext] EPP Transport Service Discovery

[Steve Crocker <[e-mail]>]

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]> 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]
> https://www.ietf.org/mailman/listinfo/regext
>


-- 
Sent by a Verified
[image: Sent by a Verified sender]
<https://wallet.unumid.co/authenticate?referralCode=tcp16fM4W47y>
sender