On May 20, 2025, at 06:47, Sarah Tarrant <starr...@staff.rfc-editor.org> wrote:
> Authors, > > This is a friendly weekly reminder that we await answers to the questions > below and your review of the document before continuing with the publication > process. We don't believe we've heard from you since April 28. > > Please let us know if there's anything you need from us to assist your review. > > Thank you, > RFC Editor/st Thank you for the updated draft Sarah. Ted and I have completed our final review. Our combined comments are attached below. With these changes, I think we should be finished with RFC-to-be 9665. Stuart Cheshire -- * Clarification. Change “services” to “service instances” -- to avoid confusion between service types (e.g., IPP) and instances of a service (e.g., a particular printer that supports IPP). Here we are talking about instances. OLD: DNS-SD allows servers to publish the information required to access the services they provide. DNS-SD clients can then discover the set of services of a particular type that are available. They can then select a service from among those that are available and obtain the information required to use it. Although DNS-SD using the DNS protocol can be more efficient and versatile than using mDNS, it is not common in practice because of the difficulties associated with updating authoritative DNS services with service information. NEW: DNS-SD allows servers to publish the information required to access the services they provide. DNS-SD clients can then discover the set of service instances of a particular type that are available. They can then select an instance from among those that are available and obtain the information required to use it. Although DNS-SD using the DNS protocol can be more efficient and versatile than using mDNS, it is not common in practice because of the difficulties associated with updating authoritative DNS services with service information. * Clarify that a reservation is not permanent. Add “immediately” OLD: The claim on the name can have a longer lease so that another requester cannot claim the name, even though the registration has expired. NEW: The claim on the name can have a longer lease so that another requester cannot immediately claim the name, even though the registration itself has expired. * Clarify: The TCP handshake only guards against off-path spoofing. OLD: To prevent such spoofing, TCP is required for such networks. NEW: To guard against off-path spoofing, TCP is required for such networks. * Clarify. This is specific to SRV targets. OLD: code only compresses in the case where a requester is generating an SRP Update. NEW: code only compresses SRV targets in the case where a requester is generating an SRP Update. * Missing word “instance”: OLD: a requester may need to remove a specific service NEW: a requester may need to remove a specific service instance OLD: To simply remove a specific service NEW: To simply remove a specific service instance * Spelling: OLD: valua NEW: value * Add quotes: OLD: imagine that you set up SRP service for example.com NEW: imagine that you set up SRP service for "example.com" * Delete “non-error” (NXDOMAIN is an error code) OLD: MAY instead return a negative non-error response NEW: MAY instead return a negative response * Need to specify the port too. OLD: It is the responsibility of a CNN supporting SRP to provide one or more registrar addresses. NEW: It is the responsibility of a CNN supporting SRP to provide at least one registrar address and port. * Clarify that Retransmission Strategy (UDP) is only for CNN devices, and say “when” rather than “if” OLD: When using UDP, reliable transmission must be guaranteed by retransmitting if a DNS UDP message is not acknowledged in a reasonable interval. NEW: For UDP updates from CNN devices, reliable transmission must be guaranteed by retransmitting when a DNS UDP message is not acknowledged in a reasonable interval. * I don’t think “consists” is right. I think, “both A and B,” is two things, and therefore should be plural, hence “both A and B consist of...” not “both A and B consists of...” OLD: both the removal of the old service and the add of the new service consists of a valid Service Discovery Instruction NEW: both the removal of the old service and the add of the new service consist of a valid Service Discovery Instruction * I don’t think this is right. YXDomain is pronounced “Why Ex Domain”, so wouldn’t we say “a Why Ex Domain” not “an Why Ex Domain”? OLD: Description Instruction), then the SRP registrar MUST reject the SRP Update with an YXDomain RCODE indicating that the desired name is NEW: Description Instruction), then the SRP registrar MUST reject the SRP Update with a YXDomain RCODE indicating that the desired name is * Weird wording, with duplicated references: OLD: The SRP registrar MAY add a Reverse Mapping PTR record (described for IPv4 in Section 3.5 of [RFC1035] of the DNS specification [RFC1035] and for IPv6 in Section 2.5 of [RFC3596] of the later document updating DNS for IPv6 [RFC3596]) NEW: The SRP registrar MAY add a Reverse Mapping PTR record (described for IPv4 in Section 3.5 of the DNS specification [RFC1035] and for IPv6 in Section 2.5 of the later document updating DNS for IPv6 [RFC3596]) I believe that this change to the XML will fix it: OLD: <xref target="RFC1035" section="3.5" sectionFormat="of"/> <xref target="RFC3596" section="2.5" sectionFormat="of"/> NEW: <xref target="RFC1035" section="3.5" sectionFormat="bare"/> <xref target="RFC3596" section="2.5" sectionFormat="bare"/> * I don’t think writing “a <proper-noun>” is right. We wouldn’t write “Implementations of *a* TCP” or “Implementations of *a* DHCP”. OLD: Implementations of a traditional DNS Update [RFC2136] do not normally provide a way to enforce a constraint of this type. NEW: Implementations of traditional DNS Update [RFC2136] do not normally provide a way to enforce a constraint of this type. * Trying to avoid reference-as-noun. I would prefer to write some words in place of the thing in square brackets. How about this? OLD: New entries may be added either as a result of Standards Action (Section 4.9 of [RFC8126]) or with IESG Approval (Section 4.10 of [RFC8126]), provided that ... NEW: New entries may be added either as a result of Standards Action (Section 4.9 of the IANA Guidelines) or with IESG Approval (Section 4.10 of of the IANA Guidelines) [RFC8126], provided that ... I believe that this change to the XML will fix it: OLD: New entries may be added either as a result of Standards Action (<xref target="RFC8126" sectionFormat="of" section="4.9"/>) or with IESG Approval (<xref target="RFC8126" sectionFormat="of" section="4.10"/>), provided NEW: New entries may be added either as a result of Standards Action (Section <xref target="RFC8126" section="4.9" sectionFormat="bare"/> of the IANA Guidelines) or with IESG Approval (Section <xref target="RFC8126" section="4.10" sectionFormat="bare"/> of the IANA Guidelines) <xref target="RFC8126"/>, provided * Change “SRP requesters” to “service instances” OLD: To support this, when removing a hostname, an SRP registrar MUST remove all service instances pointing to that hostname and all Service Discovery PTR records pointing to those service instances, even if the SRP requester doesn't list them explicitly. If the KEY lease time is nonzero, the SRP registrar MUST NOT delete the KEY records for these SRP requesters. NEW: To support this, when removing a hostname, an SRP registrar MUST remove all service instances pointing to that hostname and all Service Discovery PTR records pointing to those service instances, even if the SRP requester doesn't list them explicitly. If the KEY lease time is nonzero, the SRP registrar MUST NOT delete the KEY records for these service instances. * Clarification: When removing a service instance but reserving a name, the KEY record needs to be preserved. At the end, add, “An "Add to an RRset" instruction for the KEY record here is allowed but not implicit.” OLD: if the Service Discovery Instruction is a "Delete An RR From An RRSet" instruction, that Service Description Instruction contains a "Delete All RRsets From A Name" instruction for that service instance name with no following "Add To An RRset" instructions for the SRV and TXT records describing that service. NEW: if the Service Discovery Instruction is a "Delete An RR From An RRSet" instruction, that Service Description Instruction contains a "Delete All RRsets From A Name" instruction for that service instance name with no following "Add To An RRset" instructions for the SRV and TXT records describing that service. An "Add to an RRset" instruction for the KEY record here is allowed but not implicit. * Change “modify” to “add” (two places) OLD: Service Description Instructions do not modify any other resource records. NEW: Service Description Instructions do not add any other resource records. OLD: Host Description Instructions do not modify any other resource records. NEW: Host Description Instructions do not add any other resource records. * Change “was” to “is” (present tense) OLD: with the exception of the KEY RR, which was defined in the specification for how to store Diffie-Hellman Keys in the DNS [RFC2539] NEW: with the exception of the KEY RR, which is defined in the specification for how to store Diffie-Hellman Keys in the DNS [RFC2539] * Change “described” to “mentioned” OLD: Devices made for CNNs register in the special-use domain name [RFC6761] "default.service.arpa." and let the SRP registrar handle rewriting that to a different domain if necessary, as described in Section 3.1.2. NEW: Devices made for CNNs register in the special-use domain name [RFC6761] "default.service.arpa." and let the SRP registrar handle rewriting that to a different domain if necessary, as mentioned in Section 3.1.2. * Change “You” and “it” to “The requester” OLD: Updates done according to this specification are somewhat different from normal DNS Updates [RFC2136] where the update process could involve many update attempts. You might first attempt to add a name if it doesn't exist; if that fails, then in a second message it might update the name if it does exist but matches certain preconditions. Because the Service Registration Protocol described in this document uses a single transaction, some of this adaptability is lost. NEW: Updates done according to this specification are somewhat different from normal DNS Updates [RFC2136] where the update process could involve many update attempts. The requester might first attempt to add a name if it doesn't exist; if that fails, then in a second message the requester might update the name if it does exist but matches certain preconditions. Because the Service Registration Protocol described in this document uses a single transaction, some of this adaptability is lost. In section 3.2.3.2, a usage issue similar to the one seen in RFC9664 exists. * Change “when” to “only in the event that” (we don’t want to imply that this conflict is something that will necessarily happen) OLD: So, implicit in the generation of a new key is the generation of a new name; this can be done either proactively when regenerating a key or when the SRP update produces a name conflict. NEW: So, implicit in the generation of a new key is the generation of a new name; this can be done either proactively when regenerating a key or only in the event that the SRP update produces a name conflict. * Change “unplugged” to “disconnected or powered off” 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. * In section 3.2.5.4 (Compression in SRV Records) capitalize “RDATA” (two places) * Change “traditional DNS message” (which may be unclear) to “DNS query or response” OLD: Because the SRP Update is a DNS update, it MUST contain a single entry in the Zone Section (what would be the Question Section in a traditional DNS message) that indicates the zone to be updated. Every delete and update in an SRP Update MUST be within the zone that is specified for the SRP Update. NEW: Because the SRP Update is a DNS update, it MUST contain a single entry in the Zone Section (what would be the Question Section in a DNS query or response) that indicates the zone to be updated. Every delete and update in an SRP Update MUST be within the zone that is specified for the SRP Update. * Change “that received option” to “the Update Lease option in the response” OLD: The requester MUST check for the EDNS(0) Update Lease option in the response, and when deciding when to renew its registration the requester MUST use the lease times from that received option in place of the lease times that it originally requested from the registrar. NEW: The requester MUST check for the EDNS(0) Update Lease option in the response, and when deciding when to renew its registration the requester MUST use the lease times from the Update Lease option in the response in place of the lease times that it originally requested from the registrar. -- -- auth48archive mailing list -- auth48archive@rfc-editor.org To unsubscribe send an email to auth48archive-le...@rfc-editor.org
