Re: [regext] EPP evolution and the REGEXT charter

[Maarten Wullink]

RFC5730 Section 2.7 describes how to extend the XML data model to create a new 
EPP extension.
and the transport considerations in section 2.1 describe how to create a new 
transport mapping.

The charter then considers both to be types of an EPP extension, this works for 
me.
but it does seem there is some ambiguity there.

Maarten


From: regext  On Behalf Of Gould, James
Sent: Thursday, March 21, 2024 7:49 PM
To: maarten.wullink=40sidn...@dmarc.ietf.org; regext@ietf.org
Subject: [EXTERNAL] Re: [regext] EPP evolution and the REGEXT charter


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.
Maarten,

The charter refers to EPP extensions, which transports is a form of an EPP 
extension.  RFC 5730 defines the extension points for EPP and includes support 
for extending the transports based on Section 2.1 “Transport Mapping 
Considerations”.  I don’t believe that there is a need to revise the REGEXT 
charter to support the additional of new EPP transports.
[SAH] Agreed. New transport mappings are just another type of extension as long 
as they preserve the data model described in RFC 5730.

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

Re: [regext] EPP evolution and the REGEXT charter

[Jasdip Singh]

Hi.

Curious if the newly proposed “RESTful EPP” is considered a new protocol that 
is different from EPP, or is it an “extension” of EPP? (AFAICT, the former 
seems outside the current regext charter.)

Thanks,
Jasdip

From: regext  on behalf of Hollenbeck, Scott 

Date: Friday, March 22, 2024 at 9:56 AM
To: jgould=40verisign@dmarc.ietf.org 
, 
maarten.wullink=40sidn...@dmarc.ietf.org 
, regext@ietf.org 
Subject: Re: [regext] EPP evolution and the REGEXT charter
From: regext  On Behalf Of Gould, James
Sent: Thursday, March 21, 2024 7:49 PM
To: maarten.wullink=40sidn...@dmarc.ietf.org; regext@ietf.org
Subject: [EXTERNAL] Re: [regext] EPP evolution and the REGEXT charter


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.
Maarten,

The charter refers to EPP extensions, which transports is a form of an EPP 
extension.  RFC 5730 defines the extension points for EPP and includes support 
for extending the transports based on Section 2.1 “Transport Mapping 
Considerations”.  I don’t believe that there is a need to revise the REGEXT 
charter to support the additional of new EPP transports.
[SAH] Agreed. New transport mappings are just another type of extension as long 
as they preserve the data model described in RFC 5730.

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

Re: [regext] EPP evolution and the REGEXT charter

[Hollenbeck, Scott]

From: regext  On Behalf Of Gould, James
Sent: Thursday, March 21, 2024 7:49 PM
To: maarten.wullink=40sidn...@dmarc.ietf.org; regext@ietf.org
Subject: [EXTERNAL] Re: [regext] EPP evolution and the REGEXT charter



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.

Maarten,



The charter refers to EPP extensions, which transports is a form of an EPP 
extension.  RFC 5730 defines the extension points for EPP and includes support 
for extending the transports based on Section 2.1 “Transport Mapping 
Considerations”.  I don’t believe that there is a need to revise the REGEXT 
charter to support the additional of new EPP transports.

[SAH] Agreed. New transport mappings are just another type of extension as long 
as they preserve the data model described in RFC 5730.



Scott

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

Re: [regext] EPP evolution and the REGEXT charter

[Jim Reid]

> On 21 Mar 2024, at 23:49, Gould, James  
> wrote:
> 
> I don’t believe that there is a need to revise the REGEXT charter to support 
> the additional of new EPP transports. 

+1

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

Re: [regext] EPP evolution and the REGEXT charter

[Gould, James]

Maarten,

The charter refers to EPP extensions, which transports is a form of an EPP 
extension.  RFC 5730 defines the extension points for EPP and includes support 
for extending the transports based on Section 2.1 “Transport Mapping 
Considerations”.  I don’t believe that there is a need to revise the REGEXT 
charter to support the additional of new EPP 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

From: regext  on behalf of Maarten Wullink 

Date: Thursday, March 21, 2024 at 7:37 PM
To: "regext@ietf.org" 
Subject: [EXTERNAL] [regext] EPP evolution and the REGEXT charter


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,

Is the charter for the REGEXT WG limited to working on EPP XML extensions only?

If so, what is then required for allowing the different new transport proposals 
to continue? A new transport is clearly something different.

Do we need to expand the current charter and maybe change the WG name, if 
possible?

Or do we need to create a new WG for work related to EPP evolution such as new 
transport protocols?

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

[regext] EPP evolution and the REGEXT charter

[Maarten Wullink]

Hi all,

Is the charter for the REGEXT WG limited to working on EPP XML extensions only?

If so, what is then required for allowing the different new transport proposals 
to continue? A new transport is clearly something different.

Do we need to expand the current charter and maybe change the WG name, if 
possible?

Or do we need to create a new WG for work related to EPP evolution such as new 
transport protocols?

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

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

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


 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 

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 noted during this 

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 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 

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