On Fri, Dec 16, 2016 at 7:34 AM, Rubens Kuhl <rube...@nic.br> 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 _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
