Looks good. I approve this version. Thanks to you as well for the quick turnaround!
> On 30 May 2025, at 21:42, Sarah Tarrant <starr...@staff.rfc-editor.org> wrote: > > 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
