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

[regext] EPP Transport Service Discovery

[Hollenbeck, Scott]

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] FW: ROW13 - Call for proposals

[Hollenbeck, Scott]

FYI, folks! Please note the date of the next Registration Operations
Workshop (ROW) and the deadline for presentation abstracts (10 May 2024).

 

Scott

 

From: Row 
Sent: Tuesday, March 19, 2024 9:48 PM
Subject: ROW13 - Call for proposals

 

ROW13 Call for Proposals is Now Open! | June 4th, 2024 | 13:00 - 17:00 UTC |
Zoom Video Conference

 

Since 2014, thanks to our sponsors Verisign   and
ICANN
 , the Registration Operations Workshop
  (ROW) brings together industry members, including address/gTLD/ccTLD
registries, domain name registrars, resellers, and second level domain
registries, to present and discuss technical topics related to real world
experiences of implementing registration operations, such as RDAP, EPP,
WHOIS, RPKI, Registry Lock, and many more (https://regiops.net/events
 ).

 

The Program Committee has now opened the call for proposals for ROW13 and
invites you to submit a short abstract describing your presentation or panel
proposal to our email address r...@cofomo.com   by May
10th, 2024.

 

We invite submissions guided by this non-exhaustive list of broad topics and
encourage any discussions/suggestions for additional topics on ROW's mailing
list: regi...@googlegroups.com  

* RDRS from an operational perspective

*   RDAP implementation experience
*   Implementation of NIS2 Directive
*   New DNS Delegation (deleg) - impact on registration systems
*   Best practices for DNSSEC Key management
*   DNS abuse
*   How might Artificial Intelligence (AI) affect the registration
ecosystem
*   Topics relevant to EPP, RPKI and other protocols relevant to
Registration Systems
*   Digital Identity topics (eIDAS, etc.)
*   Registry/Registrar Industry Coming of Age:

oHandling turnover of staff or platform providers, transitioning

*   Evolving the role of the registry/registrar within the Internet
economy/environment (meaning, gov't/others)
*   Does having a distributed workforce help or hinder the operations of
a registry/registrar?

The Program Committee will notify selected authors by May 14th, 2024
(additional ROW13 important dates available at https://regiops.net
 ).

 

We look forward to receiving your proposals. Registration process will be
made available shortly on our website.

 

Please feel free to disseminate this call for proposals to other lists and
contacts where it might be of interest. Thank you. 

 


 
 

ROW Program Committee

regiops.net

| r...@cofomo.com | regi...@googlegroups.com 

 

  

 

[regext] I-D Action: draft-ietf-regext-rdap-rir-search-08.txt

[internet-drafts]

Internet-Draft draft-ietf-regext-rdap-rir-search-08.txt is now available. It
is a work item of the Registration Protocols Extensions (REGEXT) WG of the
IETF.

   Title:   RDAP RIR Search
   Authors: Tom Harrison
Jasdip Singh
   Name:draft-ietf-regext-rdap-rir-search-08.txt
   Pages:   26
   Dates:   2024-03-19

Abstract:

   The Registration Data Access Protocol (RDAP) is used by Regional
   Internet Registries (RIRs) and Domain Name Registries (DNRs) to
   provide access to their resource registration information.  The core
   specifications for RDAP define basic search functionality, but there
   are various IP and ASN-related search options provided by RIRs via
   their Whois services for which there is no corresponding RDAP
   functionality.  This document extends RDAP to support those search
   options.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-rir-search/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-rir-search-08

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-rir-search-08

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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

[regext] draft-ietf-regext-rdap-geofeed-02 Review Feedback

[Gould, James]

Ahead of the REGEXT meeting later today, I took the opportunity to review 
draft-ietf-regext-rdap-geofeed-02.  Overall, I found the extension to cover 
some useful aspects for implementers.  Below is my review feedback that can be 
further discussed at the meeting:


1.  It's interesting that the extension doesn't define a new RDAP response 
member but defines a new "links" "rel" type and a new media type.  This defines 
a new form of extension that could be leveraged in the future.  This form of 
extension can be considered in the content of draft-ietf-regext-rdap-extensions.

2.  I'm curious whether the "geo" type could be used for other RDAP objects 
(existing or new).

a.  Should the draft be made more generic to apply to any RDAP object, 
inclusive of the IP Network object class?

b.  Wouldn't it be better to have the extension identifier set to "geo" to 
match the new "rel" type used by the extension?

3.  I'm unsure whether there is the need to redefine the "links" JSON 
values that is defined in Section 4.2 of RFC 9083 other than the use of the 
"rel" value of "geo" and the recommendation to use "application/geofeed+csv" 
for the "type" value.

4.  I recommend including a registration of the "Geofeed links" redacted 
"name" in the RDAP JSON Values registry with the "redacted name" type field.  
If registered, the "description" member can be changed to a "type" member.

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