Some wording fixes

draft-lenders-core-dnr.md

@@ -63,6 +63,7 @@ informative:
   RFC8323: coap-tcp
   RFC8484: doh
   RFC8613: oscore
+  RFC9176: core-rd
   RFC9250: doq
   RFC9203: ace-oscore
   RFC9528: edhoc
@@ -80,10 +81,11 @@ informative:
 
 --- abstract
 
-This document specifies a problem statement for the discovery over DNS SVCB records of endpoints
-that communicate over Object Security for Constrained RESTful Environments (OSCORE) {{-oscore}}.
+This document provides a problem statement for the discovery of endpoints that communicate over
+Object Security for Constrained RESTful Environments (OSCORE) {{-oscore}} over DNS SVCB records.
 This will ultimately allow a host to learn about CoAP servers, but also DNS over CoAP resolvers,
-including configurations to use OSCORE and Ephemeral Diffie-Hellman Over COSE (EDHOC) {{-edhoc}}.
+that use OSCORE to encrypt messages and Ephemeral Diffie-Hellman Over COSE (EDHOC) {{-edhoc}} for
+key exchange.
 
 --- middle
 
@@ -93,7 +95,7 @@ including configurations to use OSCORE and Ephemeral Diffie-Hellman Over COSE (E
 how to communicate with a service. Service Parameters (SvcParams) are used to
 carry that information. On top of that, options to discover DNS resolvers that allow for encrypted
 DNS resolution are specified in other document. These use either DNS ({{-svcb-for-dns}}, {{-ddr}})
-or, in a local network, Router Advertisements or DHCP ({{-dnr}}). The specifications use
+or, in a local network, Router Advertisements or DHCP ({{-dnr}}). These specifications use
 SvcParams to carry information required for configuration of such resolvers.
 So far, however, only DNS transfer protocols based on Transport Layer Security
 (TLS) are supported, namely DNS over TLS (DoT) {{-dot}}, DNS over HTTPS
@@ -108,7 +110,7 @@ agnostic to the transport layer, i.e., CoAP can be transported over UDP, TCP, or
 {{lwm2m}} are discussed. A future iteration of {{-coap-indication}} will cover the selection of this
 transport via SVCB records.
 
-However, CoAP offers three security modes:
+Furthermore, CoAP offers three security modes:
 
 - **No Security:** This plain CoAP mode does not support any encryption. It
   is not recommended when using {{-doc}} but inherits core CoAP features
@@ -128,13 +130,15 @@ However, CoAP offers three security modes:
   As an alternative to EDHOC,
   keys can be set up by such an AS as described in the ACE OSCORE profile {{-ace-oscore}}.
 
-The case of no security is sufficiently covered by {{-coap-indication}}.
+The case of no security will be sufficiently covered by {{-coap-indication}}.
 {{-coap-tcp}} and {{-coap-dtls-svcb}} cover the case for transport security.
 However, there is still a gap for object security. This document provides a problem statement for
 what is needed to fill this gap.
 
 For simplicity, we will talk about the discovery CoAP servers in the following, even though the
-discovery and configuration of DoC servers over DDR and DNR is currently the main use case for this.
+discovery and configuration of DoC servers over DDR and DNR is currently the main use case for this,
+as {{-core-rd}} already provides resource discovery, and consequently CoAP service discovery, for
+constrained environments.
 
 # Terminology
 
@@ -155,17 +159,17 @@ new SvcParamKeys need to be defined and what is already there.
 {{-svcb}} defines the “alpn” key, which is used to identify the protocol suite of a service binding
 using its Application-Layer Protocol Negotiation (ALPN) ID {{-alpn}}. While this is useful to
 identify classic transport layer security, the question is raised if this is needed or even helpful
-for when there is only object security. There is an ALPN ID for CoAP over TLS that was defined in
+for when there is only object security. There is an ALPN ID for CoAP over TLS that is defined in
 {{-coap-tcp}}. As using the same ALPN ID for different transport layers is not recommended, another
-ALPN ID for CoAP over DTLS was introduced in {{-coap-dtls-svcb}}. Object security may be
+ALPN ID for CoAP over DTLS is introduced in {{-coap-dtls-svcb}}. Object security may be
 selected in addition to transport layer security or without it. Additionally, different
 CoAP transports can be selected, which may be orthogonal to the transport security.
 For instance, DTLS can be used over transports other than UDP. The selection of CoAP transport
-protocols is covered in {{-coap-indication}}. Defining an ALPN ID for each combination of object
-security, mode of transport layer security, and transport protocol might not be viable or scalable.
-For some ways of setting up object security, additional information is needed, such as an
-establishment options for an encryption context with EDHOC or an authentication server (AS) with
-ACE.
+protocols will be covered in future versions of {{-coap-indication}}. Defining an ALPN ID for each
+combination of object security, mode of transport layer security, and transport protocol might not
+be viable or scalable. For some ways of setting up object security, additional information is
+needed, such as an establishment options for an encryption context with EDHOC or an authentication
+server (AS) with ACE.
 
 Beyond the SvcParamKeys, there is the question of what the field values of the Encrypted DNS Options
 defined in {{-dnr}} might be with EDHOC or ACE EDHOC. While most fields map,