Re: [regext] EPP Transport Service Discovery

[Jody Kolker]

>> .  . 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 
(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  On Behalf Of Gould, James
Sent: Thursday, March 21, 2024 7:45 AM
To: ietf=40feherfamily@dmarc.ietf.org; 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@.


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
jgo...@verisign.com

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

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

From: regext mailto:regext-boun...@ietf.org>> on 
behalf of Kal Feher 
mailto:ietf=40feherfamily@dmarc.ietf.org>>
Date: Thursday, March 21, 2024 at 8:37 AM
To: "regext@ietf.org<mailto:regext@ietf.org>" 
mailto:regext@ietf.org>>
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

<mailto:tobias=40tobiassattler@dmarc.ietf.org>
 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 
<mailto: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 <mailto:regext-boun...@ietf.org> On 
Behalf Of Steve Crocker

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

To: Hollenbeck, Scott 
<mailto:shollenbeck=40verisign....@dmarc.ietf.org>

Cc: regext@ietf.org<mailto: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,

Re: [regext] EPP Transport Service Discovery

[Gould, James]

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
jgo...@verisign.com

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

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

From: regext  on behalf of Kal Feher 

Date: Thursday, March 21, 2024 at 8:37 AM
To: "regext@ietf.org" 
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

<mailto:tobias=40tobiassattler@dmarc.ietf.org>
 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 
<mailto: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 <mailto:regext-boun...@ietf.org> On 
Behalf Of Steve Crocker

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

To: Hollenbeck, Scott 
<mailto:shollenbeck=40verisign@dmarc.ietf.org>

Cc: regext@ietf.org<mailto: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 b

Re: [regext] EPP Transport Service Discovery

[Kal Feher]

+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
  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  
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) 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  On Behalf Of Steve Crocker
Sent: Wednesday, March 20, 2024 5:11 AM
To: Hollenbeck, Scott
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  wrote:

As no

Re: [regext] EPP Transport Service Discovery

[Andrew Newton (andy)]

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
 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  
> 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) 
> 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  On Behalf Of Steve Crocker
> Sent: Wednesday, March 20, 2024 5:11 AM
> To: Hollenbeck, Scott 
> 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 

Re: [regext] EPP Transport Service Discovery

[Hollenbeck, Scott]

> -Original Message-
> From: regext  On Behalf Of Hollenbeck, Scott
> Sent: Thursday, March 21, 2024 1:53 AM
> To: g...@algebras.org
> Cc: regext@ietf.org
> 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.
> 
> > -Original Message-
> > From: George Michaelson 
> > Sent: Wednesday, March 20, 2024 11:00 PM
> > To: Hollenbeck, Scott 
> > Cc: regext@ietf.org
> > 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.
> >
> > I very much tend to believing that SVCB is the way to do this. Not to
> > emebed, not to invent, to use the existing mechanisms to find
> > transports with flagging to rank server side preferences.
> >
> > This also serves to bootstrap TLS and so is a "two birds with one stone"
> > solution.
> >
> > * its how other applications do it
> > * it works
> > * it can direct you into a secure transport without the transition
> > through insecure state (mostly, as I understand it)
> 
> [SAH] Thanks, George. I understand that "word of mouth", or "described in an
> agreement", information exchange has worked in our current tcp/700-only
> operating environment. What got me thinking is the possibility of a server
> operator that supports multiple transports. Which one should a client choose?
> Is one preferred over the other? A service discovery protocol would allow us 
> to
> answer those questions in-band. I recognize that the answers will generally
> remain static, and out-of-band communication may suffice. Since we're now
> giving serious consideration to additional transport mappings, though, we
> need to challenge the status quo bias. I'd really like to understand if there 
> are
> environments in which clients and servers are more loosely coupled, too.

[SAH] Most importantly, we need to remember that while EPP is currently used 
primarily by the domain name industry, it's not limited to use in that 
industry. We can't assume that registry-registrar norms are universal. Service 
discovery is thus part of the price we're going to have to pay if we specify 
new transport mappings.

Scott

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] EPP Transport Service Discovery

[Hollenbeck, Scott]

> -Original Message-
> From: George Michaelson 
> Sent: Wednesday, March 20, 2024 11:00 PM
> To: Hollenbeck, Scott 
> Cc: regext@ietf.org
> 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.
> 
> I very much tend to believing that SVCB is the way to do this. Not to emebed,
> not to invent, to use the existing mechanisms to find transports with flagging
> to rank server side preferences.
> 
> This also serves to bootstrap TLS and so is a "two birds with one stone"
> solution.
> 
> * its how other applications do it
> * it works
> * it can direct you into a secure transport without the transition through
> insecure state (mostly, as I understand it)

[SAH] Thanks, George. I understand that "word of mouth", or "described in an 
agreement", information exchange has worked in our current tcp/700-only 
operating environment. What got me thinking is the possibility of a server 
operator that supports multiple transports. Which one should a client choose? 
Is one preferred over the other? A service discovery protocol would allow us to 
answer those questions in-band. I recognize that the answers will generally 
remain static, and out-of-band communication may suffice. Since we're now 
giving serious consideration to additional transport mappings, though, we need 
to challenge the status quo bias. I'd really like to understand if there are 
environments in which clients and servers are more loosely coupled, too.

Scott
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] EPP Transport Service Discovery

[George Michaelson]

I very much tend to believing that SVCB is the way to do this. Not to
emebed, not to invent, to use the existing mechanisms to find
transports with flagging to rank server side preferences.

This also serves to bootstrap TLS and so is a "two birds with one
stone" solution.

* its how other applications do it
* it works
* it can direct you into a secure transport without the transition
through insecure state (mostly, as I understand it)

-G

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] EPP Transport Service Discovery

[Tobias Sattler]

+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  
> 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  On Behalf Of Steve Crocker
> Sent: Wednesday, March 20, 2024 5:11 AM
> To: Hollenbeck, Scott 
> 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 
>  <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 

Re: [regext] EPP Transport Service Discovery

[Gould, James]

+1

We’ve had experience of adding and removing transports many years ago and it 
was done with adequate notice to the registrars.

--

JG

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

James Gould
Fellow Engineer
jgo...@verisign.com

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

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

From: regext  on behalf of Jody Kolker 

Date: Wednesday, March 20, 2024 at 7:59 AM
To: Steve Crocker , "Hollenbeck, Scott" 

Cc: "regext@ietf.org" 
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.

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  On Behalf Of Steve Crocker
Sent: Wednesday, March 20, 2024 5:11 AM
To: Hollenbeck, Scott 
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 
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 th

Re: [regext] EPP Transport Service Discovery

[Jody Kolker]

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  On Behalf Of Steve Crocker
Sent: Wednesday, March 20, 2024 5:11 AM
To: Hollenbeck, Scott 
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 
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
[Sent by a Verified 
sender]<https://wallet.unumid.co/authenticate?referralCode=tcp16fM4W47y>
sender
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] EPP Transport Service Discovery

[Steve Crocker]

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


-- 
Sent by a Verified
[image: Sent by a Verified sender]

sender
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] EPP Transport Service Discovery

[Jim Reid]

> On 20 Mar 2024, at 08:09, Bill Woodcock  wrote:
> 
> “Telling people about it” doesn’t get them to upgrade.

Neither would publishing some discovery info (presumably in the DNS).

> If we want to improve things, we actually need to improve things, not just 
> talk about it.

I agree. What I was trying to say is a discovery mechanism shouldn’t be the 
only tool in that toolbox.

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] EPP Transport Service Discovery

[Bill Woodcock]

> On Mar 20, 2024, at 08:50, Jim Reid  wrote:
>> On 20 Mar 2024, at 07:04, Bill Woodcock  wrote:
>> Yes, because the registry can improve over time, and the registrars can 
>> update their software over time. If we don’t give updated client-side 
>> software a mechanism to discover that the server now supports improved 
>> transport, we get gridlock.
> Bill, I somehow doubt a registry would introduce an updated/new transport and 
> not tell anyone about that. 

So?  “Telling people about it” doesn’t get them to upgrade.  If we want to 
improve things, we actually need to improve things, not just talk about it.

-Bill



signature.asc
Description: Message signed with OpenPGP
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] EPP Transport Service Discovery

[kowalik]

Hi Scott,

On 20.03.24 05:56, Hollenbeck, Scott wrote:

-Original Message-
From: Francisco Obispo
Sent: Wednesday, March 20, 2024 12:32 AM
To: Hollenbeck, Scott
Cc:regext@ietf.org
Subject: [EXTERNAL] Re: [regext] EPP Transport Service Discovery


This is a neat idea,

Is there a reasoning or use case for such need?

[SAH] [snip]

During today's WG meeting we discussed three proposals for non-TCP EPP 
transport. If any of them become standards and are implemented and deployed, a 
client will not be able to assume that tcp/700 is the only available transport. 
It will need to discover which transport is supported by every server it 
communicates with. That's the need.


[PK] I think the registries are pretty good these days in communicating 
such changes to their registrars *at the point in time of new feature 
introduction*. If a registrar would like to switch on a new transport at 
a later stage, when say X registries already offer it, it would have no 
other choice than digging through documentation of all of them 
(including those not yet supporting). So I see some use of a discovery 
at some point.


There is also discovery of other features built in EPP, like extensions 
supported, but I would be interested what is the current practice - 
would registrar automatically start using an extension just because it 
got announced? My past experience is that anyway it is off-band + read 
the doc.


But having a repository to refer to similar to RDAP may be useful for 
the first use case I outlined. But I don't have super strong feelings 
about it. There is no such repository for EPP server addresses and it 
seems to be no problem.


Kind Regards,

Pawel


smime.p7s
Description: S/MIME Cryptographic Signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] EPP Transport Service Discovery

[Jim Reid]

> On 20 Mar 2024, at 07:04, Bill Woodcock  wrote:
> 
> Yes, because the registry can improve over time, and the registrars can 
> update their software over time. If we don’t give updated client-side 
> software a mechanism to discover that the server now supports improved 
> transport, we get gridlock.

Bill, I somehow doubt a registry would introduce an updated/new transport and 
not tell anyone about that. Other than changing some not-yet-defined discovery 
RRtype. YMMV.

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] EPP Transport Service Discovery

[Kal Feher]

-Original Message-
From: Francisco Obispo 
Sent: Wednesday, March 20, 2024 12:32 AM
To: Hollenbeck, Scott 
Cc: regext@ietf.org
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.

This is a neat idea,

Is there a reasoning or use case for such need?

[SAH] [snip]

During today's WG meeting we discussed three proposals for non-TCP EPP 
transport. If any of them become standards and are implemented and deployed, a 
client will not be able to assume that tcp/700 is the only available transport. 
It will need to discover which transport is supported by every server it 
communicates with. That's the need.

Scott
___


Is there a need for in band discovery? Out of band via person to person comms 
works fine for all kinds of one-off on-boarding activities.
If we propose that transport might change during regular operations, then I can 
see a need for something in band.

Regardless of service discovery capability, I think EPP over alternate 
transports should move forward.

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] EPP Transport Service Discovery

[Bill Woodcock]

The. Certificate problem can be dealt with as elsewhere: switch to DANE and 
stop accepting CA certs. 

-Bill


> On Mar 20, 2024, at 5:33 AM, Francisco Obispo  wrote:
> 
> This is a neat idea,
> 
> Is there a reasoning or use case for such need?
> 
> One of the challenges that I see, is that knowing the server address is one 
> thing, but generally clients (registrars) keep the connections open for a 
> long period of time, so the need to reduce the connection speed may not be a 
> big advantage in practice. (if this is the argument)
> 
> Additionally to connect to an EPP server you will need some sort of client 
> credentials and a form of client certificate pinning which is usually 
> negotiated and exchanged out-of-band.
> 
> I am curious to understand the reasoning behind this need
> 
> Best regards,
> 
> Francisco
> 
>> On 19 Mar 2024, at 19:11, Hollenbeck, Scott 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
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext


___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] EPP Transport Service Discovery

[Bill Woodcock]

Yes, because the registry can improve over time, and the registrars can update 
their software over time. If we don’t give updated client-side software a 
mechanism to discover that the server now supports improved transport, we get 
gridlock. 

-Bill


> On Mar 20, 2024, at 3:40 AM, Jim Reid  wrote:
> 
> 
> 
>> On 20 Mar 2024, at 02:11, Hollenbeck, Scott 
>>  wrote:
>> 
>> we need to consider how a client can discover the transport services 
>> provided by an EPP server.
> 
> I’m sceptical about that. Though I don’t object to the idea.
> 
> Surely clients get told about the EPP server’s supported transports as a 
> result of signing the registry’s contract? If so, do we *really* need 
> something else?
> 
> ___
> 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

Re: [regext] EPP Transport Service Discovery

[Hollenbeck, Scott]

> -Original Message-
> From: Francisco Obispo 
> Sent: Wednesday, March 20, 2024 12:32 AM
> To: Hollenbeck, Scott 
> Cc: regext@ietf.org
> 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.
> 
> This is a neat idea,
> 
> Is there a reasoning or use case for such need?
[SAH] [snip]

During today's WG meeting we discussed three proposals for non-TCP EPP 
transport. If any of them become standards and are implemented and deployed, a 
client will not be able to assume that tcp/700 is the only available transport. 
It will need to discover which transport is supported by every server it 
communicates with. That's the need.

Scott
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] EPP Transport Service Discovery

[Francisco Obispo]

This is a neat idea,

Is there a reasoning or use case for such need?

One of the challenges that I see, is that knowing the server address is one 
thing, but generally clients (registrars) keep the connections open for a long 
period of time, so the need to reduce the connection speed may not be a big 
advantage in practice. (if this is the argument)

Additionally to connect to an EPP server you will need some sort of client 
credentials and a form of client certificate pinning which is usually 
negotiated and exchanged out-of-band.

I am curious to understand the reasoning behind this need

Best regards,

Francisco

On 19 Mar 2024, at 19:11, Hollenbeck, Scott 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
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] EPP Transport Service Discovery

[Maarten Wullink]

how about using an iana registry similar as described for rdap?

see

Bootstrap Service Registry for Domain Name 
Space
iana.org
[apple-touch-icon.png]




Op 20 mrt 2024 om 13:00 heeft Paul Ebersman  het 
volgende geschreven:

[You don't often get email from list-reg...@dragon.net. Learn why this is 
important at https://aka.ms/LearnAboutSenderIdentification ]

jim> Surely clients get told about the EPP server's supported transports
jim> as a result of signing the registry's contract? If so, do we
jim> *really* need something else?

My guess is that even though registry software updates aren't overly
nimble, registry contracts are probably even slower and harder to
update/change.

___
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

Re: [regext] EPP Transport Service Discovery

[Paul Ebersman]

jim> Surely clients get told about the EPP server's supported transports
jim> as a result of signing the registry's contract? If so, do we
jim> *really* need something else?

My guess is that even though registry software updates aren't overly
nimble, registry contracts are probably even slower and harder to
update/change.

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] EPP Transport Service Discovery

[Jim Reid]

> On 20 Mar 2024, at 02:11, Hollenbeck, Scott 
>  wrote:
> 
> we need to consider how a client can discover the transport services provided 
> by an EPP server. 

I’m sceptical about that. Though I don’t object to the idea.

Surely clients get told about the EPP server’s supported transports as a result 
of signing the registry’s contract? If so, do we *really* need something else?

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext