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

[Andrew Newton <[e-mail]>]

On Fri, Dec 16, 2016 at 7:34 AM, Rubens Kuhl <[e-mail]> wrote:
>
>
>
> Besides the concerns already mentioned by Michele, I add that using a TCP+TLS based mechanism adds latency that is not the best friend of a sales pipeline.
> When this topic last appeared I suggested considering DTLS transport and I repeat that suggestion, adding that an availability protocol should be less verbose than RDAP in order to not add network latency to the problem.

Rubens,

Both I and the IETF have been down the UDP as a domain availability
service road before. See RFC 5144. Given that it rarely comes up in
these conversations is probably a good indicator that such an idea is
not successful.

While I'm not a DTLS expert by any means, my understanding is that it
is TLS modified for UDP achieved most characteristically with a record
format modified from TLS. That means it still has key exchange, and
therefore the setup is not much more lightweight than TLS itself
(there will be multiple packet exchanges before app data flows). DTLS
benefits protocols where dropped packets have a different tolerance
such as real-time audio or video streaming.

Additionally, if you look at the draft you'll see examples where octet
counts are given. A simple status check can easily fit in a single TCP
packet. Given keep-alive and the bag of tricks achievable with HTTP/2,
I think latency is not much of concern.

I'll give you that it is possible to engineer a UDP/DTLS protocol that
is more performant, but in practice it will be only marginally better
yet orders of magnitude more difficult to implement.

-andy