Hi Ted, Thank you for the speedy reply -- I've updated per your request. Please be sure to refresh since I just updated these.
We will await approvals from both authors. The updated files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9665.txt https://www.rfc-editor.org/authors/rfc9665.pdf https://www.rfc-editor.org/authors/rfc9665.html https://www.rfc-editor.org/authors/rfc9665.xml The relevant diff files have been posted here (please refresh): https://www.rfc-editor.org/authors/rfc9665-diff.html (comprehensive diff) https://www.rfc-editor.org/authors/rfc9665-auth48diff.html (AUTH48 changes only) Thank you, RFC Editor/st > On May 30, 2025, at 2:32 PM, Ted Lemon <ele...@apple.com> wrote: > > On 30 May 2025, at 21:07, Sarah Tarrant <starr...@staff.rfc-editor.org> wrote: >> >> >> Ted - Thank you for helping me understand the phrasing with "traditional DNS >> Update protocol". I spent some time looking through the other instances in >> the document, and your explanation really helped me understand. > > Yes, it's actually a bit confusing in the document. You touched on this in > the initial AUTH48 edit, but I think we didn't get rid of all the ambiguity, > so it's no wonder you are confused. The document uses the terms "DNS Update" > and "DNS Update message" to mean the same thing, but also uses the term "DNS > Update" to refer to the "DNS Update protocol." I think an edit to fix this > would be too much to suggest at this stage in the process, but that's > probably how this confusion arose. Oh, and we also use "DNS Update" in the > context of protocol elements, like "DNS Update Adds". > > Sigh. > > Anyway, I do see an issue here in 3.2.5.1: > > hen regenerating a key or or only in the event that the SRP update > > This change wasn't fully applied: > > In section 3.2.5.3, unplugged is a bit anachronistic these days. OLD: > > The lifetime of the KEY records is set using the KEY-LEASE field of the > Update Lease Option and SHOULD be set to a much longer time, typically 14 > days. The result being that even though a device may be temporarily unplugged > -- disappearing from the network for a few days -- it makes a claim on its > name that lasts much longer. > Therefore, even if a device is unplugged from the network for a few days, and > its services are not available for that time, no other device can come along > and claim its name the moment it disappears from the network. In the event > that a device is unplugged from the network and permanently discarded, then > its name is eventually cleaned up and made available for reuse. > NEW: > The lifetime of the KEY records is set using the KEY-LEASE field of the > Update Lease Option and SHOULD be set to a much longer time, typically 14 > days. The result being that even though a device may be temporarily > disconnected or powered off -- disappearing from the network for a few days > -- it makes a claim on its name that lasts much longer. > Therefore, even if a device is unplugged from the network for a few days, and > its services are not available for that time, no other device can come along > and claim its name the moment it disappears from the network. In the event > that a device is disconnected from the network and permanently discarded, > then its name is eventually cleaned up and made available for reuse. > This change was omitted from Stuart's update: > Also in 3.2.5.4, OLD: > > Note that this document does not update the SRV specification [RFC2782]: > Authoritative DNS servers still MUST NOT compress SRV record targets. The > requirement to accept compressed SRV records in updates only applies to SRP > registrars, and SRP registrars that are also authoritative DNS servers still > MUST NOT compress SRV record targets in DNS responses. We note also that > Multicast DNS [RFC6762] similarly compresses SRV records in mDNS messages. > NEW: > > Note that this document does not update the SRV specification [RFC2782]: > Authoritative DNS servers still MUST NOT compress SRV record targets. The > requirement to accept compressed SRV records in updates only applies to SRP > registrars. SRP registrars that are also authoritative DNS servers still MUST > NOT compress SRV record targets in DNS responses. We note also that Multicast > DNS [RFC6762] similarly compresses SRV records in mDNS messages. > I think Stuart didn't understand the purpose of this change. The reason to > break this into two sentences is not for readability. It's that it makes the > meaning clearer. "SRP registrars" at the end of the sentence in the new text > is talking about all SRP registrars. "SRP registrars" at the beginning of the > second sentence is talking about SRP registrars that are also authoritative > DNS servers. The current text makes this distinction a lot less clear. > Sorry to add one more cycle, but hopefully this is the last one. > -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
