Subject: Re: [regext] Using RDAP as a Domain Availability Service

From: "Gould, James" <[email-masked]>
Date: Fri, 16 Dec 2016 15:48:18 +0000

Keith,

Yes, the DAC service looks interesting; although it would need to be made more generic.  A lightweight protocol that is focused on availability would be preferred.  It would be good to get a list of use cases to understand the need for such a service.   

—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

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

On 12/16/16, 8:59 AM, "regext on behalf of Keith Gaughan" <[email-masked] on behalf of [email-masked]> wrote:

    On 16/12/16 13:42, Gould, James wrote:
    
    > I too have heard interest in an availability service that could be
    > discussed, but this should be separated from RDAP.
    
    Agreed. There are many, many problems with using RDAP for this, not
    least of which that it's ill suited to bulk queries, which, speaking
    from experience on the domain registrar side of things, is an essential
    part of any DAS.
    
    If you want a good model for a dedicated DAS protocol, the one Nominet
    use[1] is sensible, and, with a few small tweaks[2], could be made
    generally useful.
    
    [1]
    http://registrars.nominet.uk/namespace/uk/registration-and-domain-management/query-tools/dac/instructions
    
    [2] A greeting to indicate a list of response headers to the client
        would be sufficient.
    
    > I view availability via EPP as the best channel for authorized
    > parties to go, since it is authoritative and it includes all the
    > availability business logic.  EPP is a standard, so registries that
    > have chosen not to implement it may not implement another standard
    > either.
    
    There's room for a dedicated DAS protocol. Specifically, a registrar
    may wish to allow specific customers or internal services query the
    availability of domains without hitting an EPP server directly. This
    is what we do internally in Blacknight. A dedicated DAS can have lower
    overhead than EPP too.
    
    > A public availability service would look a lot more like a DNS
    > service than an RDAP lookup service, since it could be a larger
    > dependency for a broader set of real-time clients and therefore needs
    > to be focused on scalability and accuracy (complete set of
    > availability logic) over breadth of lookup features.  It would be
    > great to understand the use cases for a public availability service
    > to define the need prior to making proposals on a solution.
    
    K.
    
    -- 
    Keith Gaughan, Development Lead; PGP/GPG key ID: D5FC9D23
    Blacknight Internet Solutions Ltd. <http://blacknight.host/>
    12A Barrowside Business Park, Carlow, R93 X265, Ireland
    Registered in Ireland, Company No.: 370845
    
    _______________________________________________
    regext mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/regext

---

From: "Gould, James" <[email-masked]>
Date: Mon, 19 Dec 2016 13:35:58 +0000

Francisco,

My understanding is that the expectation of RDAP is to implement the RDAP RFC’s as a Registration Data Directory Service (RDDS) and not to replace all features implemented in WHOIS by various providers.  You chose to provide elements of an availability service in the form of an unavailable feature in WHOIS.  In RDAP, the registry is not obligated to provide an availability check or reason why the object is not available in RDAP but simply return the data if it exists and the user is authorized.

I believe that an availability service is best implemented by checking the availability of one or more objects in a lightweight and highly performant manner, as opposed to implementing an unavailable feature on an individual lookup.  EPP has a separate check command from an info command for the reason of providing a lightweight mechanism to get the availability information of many objects in a single packet.  An unavailability feature of a lookup is technically possible, but I don’t believe it meets the needs for a scalable availability service.

Just as the availability check is being extended in EPP with items like claims information and fee information, an availability service runs a similar risk of getting heavyweight with features.  Some of these features are best handled in the OLTP system based on the complexity and required accuracy, so I believe it’s best to discuss who will use the availability information, what would they need, and what are the non-functional requirements for it.  This all needs to be done prior to proposing a protocol to handle it.

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

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

From: Francisco Obispo <[email-masked]>
Date: Friday, December 16, 2016 at 5:37 PM
To: James Gould <[email-masked]>
Cc: Andrew Newton <[email-masked]>, Registration Protocols Extensions <[email-masked]>
Subject: [EXTERNAL] Re: [regext] Using RDAP as a Domain Availability Service

Hi James,

From what I’ve seen, the expectation is that RDAP will substitute port 43 WHOIS.

We (uniregistry) currently do availability checks when the domain is not registered AND we also provide a very specific reason on why a domain is not available.

Customers also want to know if a specific domain is under a specific policy that might change in the near future, for instance when we launched out TLDs we had a large set that was held back for a period of time (A.K.A. names collision), and just showing as “object does not exist” did not provide information on why and whether the name would be available in the future. We had to become very explicit when our support queue was growing very large from customers asking for a specific reason and/or dates when they could register the names.

For us, RDAP has to cover both use cases. Whether a registry is obligated to provide an availability check or reason why the object is not available, should be mandated by policy and not in anyway by limitations of the protocol.

Best regards,

Francisco Obispo
CTO - Registry Operations
____________________________

[niregistry]<http://www.uniregistry.com/>

2161 San Joaquin Hills Road
Newport Beach, CA 92660

Office +1 949 706 2300 x4202
[email-masked]

On 16 Dec 2016, at 9:22, Gould, James wrote:

That is one of my concerns, RDAP is a lookup protocol and not the SRS and should only return data that exists with no reasons why it does not exist other than scenarios like authorization issues or when data can be found elsewhere by reference.  We have not defined the use cases and it should not be assumed that because RDAP provides registration data that it should also support availability logic like the SRS.  Can we clearly define the use case of this undefined service?  I view this as a separate service from the SRS and RDAP to meet the undefined needs of a yet to be defined set of users.