rfc9665v5.txt   rfc9665.txt 
skipping to change at line 871 skipping to change at line 871
with which the SRP Update was signed. with which the SRP Update was signed.
Service Description Instructions do not add any other resource Service Description Instructions do not add any other resource
records. records.
An SRP registrar MUST correctly handle compressed names in the SRV An SRP registrar MUST correctly handle compressed names in the SRV
target. target.
3.3.1.3. Host Description Instruction 3.3.1.3. Host Description Instruction
Every SRP Update alway contains exactly one Host Description Every SRP Update always contains exactly one Host Description
Instruction. Instruction.
An instruction is a Host Description Instruction if, for the An instruction is a Host Description Instruction if, for the
appropriate hostname, it contains the following: appropriate hostname, it contains the following:
* exactly one "Delete All RRsets From A Name" RR * exactly one "Delete All RRsets From A Name" RR
* exactly one "Add To An RRset" RR that adds a KEY RR that contains * exactly one "Add To An RRset" RR that adds a KEY RR that contains
the public key corresponding to the private key that was used to the public key corresponding to the private key that was used to
sign the message sign the message
skipping to change at line 906 skipping to change at line 906
registrar could elect not to publish this in a DNS zone. However, in registrar could elect not to publish this in a DNS zone. However, in
some situations, the registrar might make the records available some situations, the registrar might make the records available
through a mechanism such as an advertising proxy only on the specific through a mechanism such as an advertising proxy only on the specific
link from which the SRP Update originated. In such a situation, link from which the SRP Update originated. In such a situation,
locally scoped records are still valid. locally scoped records are still valid.
3.3.2. Valid SRP Update Requirements 3.3.2. Valid SRP Update Requirements
An SRP Update MUST contain exactly one Host Description Instruction. An SRP Update MUST contain exactly one Host Description Instruction.
Multiple Service Discovery updates and Service Description updates Multiple Service Discovery updates and Service Description updates
may be combined into a single single SRP Update along with a single may be combined into a single SRP Update along with a single Host
Host Description update, as described in Section 3.2.3. A DNS Update Description update, as described in Section 3.2.3. A DNS Update
message that contains any additional adds or deletes that cannot be message that contains any additional adds or deletes that cannot be
identified as Service Discovery, Service Description, or Host identified as Service Discovery, Service Description, or Host
Description Instructions is not an SRP Update. A DNS update that Description Instructions is not an SRP Update. A DNS update that
contains any prerequisites is not an SRP Update. contains any prerequisites is not an SRP Update.
An SRP Update MUST include an EDNS(0) Update Lease option [RFC9664]. An SRP Update MUST include an EDNS(0) Update Lease option [RFC9664].
The LEASE time specified in the Update Lease option MUST be less than The LEASE time specified in the Update Lease option MUST be less than
or equal to the KEY-LEASE time. A DNS update that does not include or equal to the KEY-LEASE time. A DNS update that does not include
the Update Lease option, or that includes a KEY-LEASE value that is the Update Lease option, or that includes a KEY-LEASE value that is
less than the LEASE value, is not an SRP Update. less than the LEASE value, is not an SRP Update.
skipping to change at line 1159 skipping to change at line 1159
SRP requesters SHOULD assume that each lease ends N seconds after the SRP requesters SHOULD assume that each lease ends N seconds after the
update was first transmitted (where N is the granted lease duration). update was first transmitted (where N is the granted lease duration).
SRP registrars SHOULD assume that each lease ends N seconds after the SRP registrars SHOULD assume that each lease ends N seconds after the
update that was successfully processed was received. Because the update that was successfully processed was received. Because the
registrar will always receive the update after the SRP requester sent registrar will always receive the update after the SRP requester sent
it, this avoids the possibility of a race condition where the SRP it, this avoids the possibility of a race condition where the SRP
registrar prematurely removes a service when the SRP requester thinks registrar prematurely removes a service when the SRP requester thinks
the lease has not yet expired. In addition, the SRP requester MUST the lease has not yet expired. In addition, the SRP requester MUST
begin attempting to renew its lease in advance of the expected begin attempting to renew its lease in advance of the expected
expiration time, as required by the DNS Update Lease specification expiration time, as required by the DNS Update Lease specification
[RFC9664], to accomodate the situation where the clocks on the SRP [RFC9664], to accommodate the situation where the clocks on the SRP
requester and the SRP registrar do not run at precisely the same requester and the SRP registrar do not run at precisely the same
rate. rate.
SRP registrars MUST reject updates that do not include an EDNS(0) SRP registrars MUST reject updates that do not include an EDNS(0)
Update Lease option. DNS authoritative servers that allow both SRP Update Lease option. DNS authoritative servers that allow both SRP
and non-SRP DNS updates MAY accept updates that don't include leases, and non-SRP DNS updates MAY accept updates that don't include leases,
but they SHOULD differentiate between SRP Updates and other updates but they SHOULD differentiate between SRP Updates and other updates
and MUST reject updates that would otherwise be SRP Updates if they and MUST reject updates that would otherwise be SRP Updates if they
do not include leases. do not include leases.
skipping to change at line 1706 skipping to change at line 1706
[RFC8765] Pusateri, T. and S. Cheshire, "DNS Push Notifications", [RFC8765] Pusateri, T. and S. Cheshire, "DNS Push Notifications",
RFC 8765, DOI 10.17487/RFC8765, June 2020, RFC 8765, DOI 10.17487/RFC8765, June 2020,
<https://www.rfc-editor.org/info/rfc8765>. <https://www.rfc-editor.org/info/rfc8765>.
[RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237, [RFC9364] Hoffman, P., "DNS Security Extensions (DNSSEC)", BCP 237,
RFC 9364, DOI 10.17487/RFC9364, February 2023, RFC 9364, DOI 10.17487/RFC9364, February 2023,
<https://www.rfc-editor.org/info/rfc9364>. <https://www.rfc-editor.org/info/rfc9364>.
[RFC9664] Cheshire, S. and T. Lemon, "An EDNS(0) Option to Negotiate [RFC9664] Cheshire, S. and T. Lemon, "An EDNS(0) Option to Negotiate
Leases on DNS Updates", RFC 9664, DOI 10.17487/RFC9664, Leases on DNS Updates", RFC 9664, DOI 10.17487/RFC9664,
October 2024, <https://www.rfc-editor.org/info/rfc9664>. June 2025, <https://www.rfc-editor.org/info/rfc9664>.
11.2. Informative References 11.2. Informative References
[IAB-ARPA] "Internet Architecture Board statement on the registration [IAB-ARPA] "Internet Architecture Board statement on the registration
of special use names in the ARPA domain", March 2017, of special use names in the ARPA domain", March 2017,
<https://www.iab.org/documents/correspondence-reports- <https://www.iab.org/documents/correspondence-reports-
documents/2017-2/iab-statement-on-the-registration-of- documents/2017-2/iab-statement-on-the-registration-of-
special-use-names-in-the-arpa-domain/>. special-use-names-in-the-arpa-domain/>.
[IPv6] IANA, "IANA IPv6 Special-Purpose Address Registry", [IPv6] IANA, "IANA IPv6 Special-Purpose Address Registry",
 End of changes. 4 change blocks. 
5 lines changed or deleted 5 lines changed or added

This html diff was produced by rfcdiff 1.48.