I agree that we should clarify which nodes are likely to have sufficient local resources & usually good enough Internet connectivity that they could (or perhaps SHOULD) use more secure modern transports for their DRIP usage of DNS, vs which typically will not & thus generally will have to use legacy DNS. We authors will discuss & address ASAP. Thank you. Sent from my Verizon, Samsung Galaxy smartphone Get Outlook for Android<https://aka.ms/AAb9ysg> ________________________________ From: Di Ma <madi@xxxxxxxxxxx> Sent: Wednesday, January 17, 2024 4:01:44 AM To: Adam Wiethuechter <adam.wiethuechter@xxxxxxxxxxxxxxxx> Cc: dnsdir@xxxxxxxx <dnsdir@xxxxxxxx>; draft-ietf-drip-auth.all@xxxxxxxx <draft-ietf-drip-auth.all@xxxxxxxx>; last-call@xxxxxxxx <last-call@xxxxxxxx>; tm-rid@xxxxxxxx <tm-rid@xxxxxxxx> Subject: Re: Dnsdir last call review of draft-ietf-drip-auth-43 [You don't often get email from madi@xxxxxxxxxxx. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ] Hi, Adam, > 2024年1月16日 22:26，Adam Wiethuechter <adam.wiethuechter@xxxxxxxxxxxxxxxx> 写道： > > Di, thanks for your review of the I-D. > > It’s not clear if enhanced error codes will serve a useful role in DRIP. It probably won’t matter to an end client what sort of failure occurred. All that matters is the lookup failed. Which could mean a DET has expired or been revoked and some out-of-band (ie non-DNS) mechanism could be needed to confirm that. Thanks for your clarification. Your consideration on error codes is making sense here. > > New(ish) DNS developments like DOA and DSO are unlikely to figure in DRIP deployments because in general DRIP clients will not have the hardware and networking resources to maintain state or an encrypted transport. Yes. However, you’d better articulate DRIP is using RFC1035 DNS since DNS is not normatively limited to UDP-DNS as DoH and DSO are coming into sight of IETF community. Di
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
