lookup are example values.  The server in this example also indicates that it is capable of providing observation on resource lookups. <del> [ The RFC editor is asked to replace this and later occurrences of MCD1 with the assigned IPv6 site-local address for "all CoRE Resource Directories". ] </del> From a management and maintenance perspective, it is necessary to identify the components that constitute the RD server.  The identification refers to information about for example client-server 9.5. <del> IANA has assigned the following multicast addresses for use by CoAP nodes: </del>  <del> IPv4 - "all CoRE resource directories" address, from the "IPv4 Multicast Address Space Registry" equal to "All CoAP Nodes", 224.0.1.187.  As the address is used for discovery that may span beyond a single network, it has come from the Internetwork Control Block (224.0.1.x, RFC 5771). </del>  IPv6 - "all CoRE resource directories" address MCD1 (suggestions FF0X::FE), from the "IPv6 Multicast Address Space Registry", in the CoAP nodes should listen to; CoAP needs the Link-Local and Site-Local scopes only.  10. Two examples are presented: a Lighting Installation example in lt-ex

Request a dedicated IPv4 address (rather than sharing with All CoAP nodes) Fix erroneous examples Editorial changes Add figure numbers to examples Update RD parameters table to reflect changes of earlier versions in the text Typos and minor wording
Where IANA has not yet allocated a value, we cannot say "has allocated a value". Yes, it is a bit tedious to change this once the allocation has been done, but IANA has to be able to derive from the text what it needs to do. Also, I don't understand the "equal to" language in section mc-registration; do you mean ", the same as"?
Changing this as of finishing up the pending comments. Ad "equal to", my understanding is that we don't actually register a new address but just ask people to use "All CoAP nodes" for the same purpose (given the tighter address space). Is that the agreed-upon intention? If so: Does this warrant IANA action (by adding another name alias to the same address), or won't we just say where we use it that there ain't no IPv4 multicast address for that, and All CoAP nodes are used instead?
I cannot recall a recent discussion on this, but this is indeed one possible interpretation of the not so clear language. I don’t think the registry uses aliases. So there would be no IANA action. There should be no text in mc-registration (since this is for IANA), but there should be text in 4.3 URI Discovery saying that. Alternatively, we could simply go for another IPv4 address. The registry doesn’t seem to explode (there is just one entry after RFC 7252). But let’s find the WG discussion first. Grüße, Carsten
anchors are /sensors/temp but targets are /temp
some examples have figure numbers, some don't
Figure 6 has a spurious anchor (and figure 7 right below is not labeled as a figure)
The -12 draft suggests as a heuristic to ask at . There is a multicast address for All CoAP Nodes, I suggest we use that (would be ).
Indeed, that is an obvious change to be made. We also could think of registering a multicast address for "all CoRE resource directories", if that turns out to be useful.
agree fully with Carsten chrysn schreef op 2017-11-04 13:07:
I like the "All CoRE RDs" address. It's trivial for IPv6, but the v4 addresses are more scarce. Can we register one of both, or would the v4 behavior just be "All CoAP nodes" again?
Let's stick to all CoRE RDs address; specify a new address for v6, and equate all CoRE RD address equal to all CoAP nodes.
Inserted text for "all RD" MC address registry, called MCD1 for the moment
the equation would have turned out a bit complicated in the iana considerations (either it'd have spread the text around or we'd be aliasing multicast addresses), going with a dedicated address. See URL and today's CoRE chat logs.

lookup are example values.  The server in this example also indicates that it is capable of providing observation on resource lookups.  From a management and maintenance perspective, it is necessary to identify the components that constitute the RD server.  The identification refers to information about for example client-server 9.5.  <ins> IANA is asked to assign the following multicast addresses for use by CoAP nodes: </ins>  <ins> IPv4 - "all CoRE resource directories" address MCD2 (suggestion: 224.0.1.189), from the "IPv4 Multicast Address Space Registry".  As the address is used for discovery that may span beyond a single network, it has come from the Internetwork Control Block (224.0.1.x, RFC 5771). </ins> IPv6 - "all CoRE resource directories" address MCD1 (suggestions FF0X::FE), from the "IPv6 Multicast Address Space Registry", in the CoAP nodes should listen to; CoAP needs the Link-Local and Site-Local scopes only. <ins> [ The RFC editor is asked to replace MCD1 and MCD2 with the assigned addresses throughout the document. ] </ins> 10. Two examples are presented: a Lighting Installation example in lt-ex


authorization token. Lifetime (optional).  Lifetime of the registration in seconds. <del> Range of 60-4294967295.  If no lifetime is included in the </del>  initial registration, a default value of 90000 (25 hours) SHOULD be assumed. successful earlier registration. Lifetime (optional).  Lifetime of the registration in seconds. <del> Range of 60-4294967295.  If no lifetime is included, the </del>  previous last lifetime set on a previous update or the original registration (falling back to 90000) SHOULD be used.

Not setting to 0 as this would require further explanation on what it means, and also leaves the 0 value usable as a sentinel in implementations for "no lt given" (although the same, with -1, could be achieved by reducing the range at the top end). Closes: URL
Feedback from LwM2M: Their testing takes long with the arbitrary limit of 60s. We found no technical reasons to keep it there, and it should probably be abolished in favor of the natural lower limit of 1 second.

authorization token. Lifetime (optional).  Lifetime of the registration in seconds.  <ins> Range of 1-4294967295.  If no lifetime is included in the </ins> initial registration, a default value of 90000 (25 hours) SHOULD be assumed. successful earlier registration. Lifetime (optional).  Lifetime of the registration in seconds.  <ins> Range of 1-4294967295.  If no lifetime is included, the </ins> previous last lifetime set on a previous update or the original registration (falling back to 90000) SHOULD be used.


4.1.2. <del> A resource directory can advertise its resources in DNS-SD using the service names "_rd._udp", "_rd-lookup-res._udp" and "_rd_lookup- ep._udp" defined in this document for its Directory Resource, its resource lookup and endpoint lookup resource, respectively.  A "path" key SHOULD be set, and indicate the path on the server (starting with a slash). </del>  <del> The use of those service names implies that CoAP-over-UDP is used. With that information, the host name and port given in the SRV record and the path from the TXT record, the discovering client can perform RD and URI discovery in a single step. </del>  <del> When the "path" key is absent, the client MUST discovery the URIs on the server according to discovery. This section is a concrete application of the more generic mechanism that is being developed as I-D.ietf-core-rd-dns-sd. </del>  4.2. 9.7. <del> IANA is asked to enter two new items into the Service Names and Transport Protocol Port Number Registry, all with this document as a reference: Service name "rd" over protocol "udp", described as "Resource Directory Directory Resource accessed using CoAP" </del>  <del> Service name "rd-lookup-res" over protocol "udp", described as "Resource Directory resource lookup accessed using CoAP" </del>  <del> Service name "rd-lookup-ep" over protocol "udp", described as "Resource Directory endpoint lookup accessed using CoAP" </del>  <del> All share the same assignment note: </del>  <del> Defined TXT key: path (e.g. "path=/rd") </del>  10.

Reviewing the discussion in [1] and [2], my original patch seems to have overshot. [1]: URL [2]: URL
Much more sensibleless ambitious and more correct. The outcome in discussion in the Friday meeting was that the resource-directory specification should simply define the small number of DNS-SD service types that are needed for resource directory discovery. We said details were to be taken to the list, which I want to initiate now. In the meeting, I gave the three examples core-URL, core-rd-URL, and core-URL — noting that while core-rd is a proper RD service type, core-rd-tls isn’t. To cover the six transports we have for CoAP today (coap, coaps, coap+tcp, coaps+tcp, coap+ws, coaps+ws), we would need four service types on top of tcp and could use two of them over udp? Grüße, Carsten

4.1.2.  <ins> A resource directory can advertise its presence in DNS-SD using the service name "_core-rd._udp" defined in this document. </ins>  <ins> The use of that service names implies that CoAP-over-UDP is used. The SRV record points the client to a host name and port to use as a starting point for the URI discovery steps of discovery. </ins>  <ins> This section is a simplified concrete application of the more generic mechanism specified in I-D.ietf-core-rd-dns-sd. </ins> 4.2. 9.7.  <ins> IANA is asked to enter a new item into the Service Names and Transport Protocol Port Number Registry: </ins>  <ins> Service name: "core-rd" </ins>  <ins> Protocol: "udp" </ins>  <ins> Description: "Resource Directory accessed using CoAP" </ins>  <ins> Reference: this document </ins> 10.


available), the use of a preconfigured anycast address is recommended (e.g. installation phase described in automation). <del> The use of DNS facilities is described in I-D.ietf-core-rd-dns-sd. </del>  The use of multicast discovery in mesh networks is NOT recommended.

This was missed in the original pull of mechanism from RD-DNS-SD into here; its wording was brought in line with the other recommendations ("In case X, Y is recommended") and now goes to the internal section rather than the external document. Will be merged on Monday before submission unless spoken against.

available), the use of a preconfigured anycast address is recommended (e.g. installation phase described in automation).  <ins> In networks managed using DNS-SD, the use of DNS-SD for discovery as described in rd-using-dnssd is recommended. </ins> The use of multicast discovery in mesh networks is NOT recommended.


4.1.2. A resource directory can advertise its presence in DNS-SD using the <del> service name "_core-rd._udp" defined in this document. </del>  <del> The use of that service names implies that CoAP-over-UDP is used. The SRV record points the client to a host name and port to use as a starting point for the URI discovery steps of discovery. </del>  This section is a simplified concrete application of the more generic mechanism specified in I-D.ietf-core-rd-dns-sd. 9.7. <del> IANA is asked to enter a new item into the Service Names and </del>  Transport Protocol Port Number Registry: <del> Service name: "core-rd" </del>  <del> Protocol: "udp" </del>  <del> Description: "Resource Directory accessed using CoAP" </del>  <del> Reference: this document </del>  10.

Those were in the original proposals during IETF / on the list, but not in the text yet. Depends on for practical merging purposes.

4.1.2. A resource directory can advertise its presence in DNS-SD using the  <ins> service name "_core-rd._udp" (for CoAP), "_core-rd-dtls._udp" (for CoAP over UDP), "_core-rd._tcp" (for CoAP over TCP) or "_core-rd- tls._tcp" (for CoAP over TLS)` defined in this document.  (For the WebSocket transports of CoAP, no service is defined as DNS-SD is typically unavailable in environments where CoAP over WebSockets). </ins>  <ins> The selection of the service indicates the protocol used, and the SRV record points the client to a host name and port to use as a starting point for the URI discovery steps of discovery. </ins> This section is a simplified concrete application of the more generic mechanism specified in I-D.ietf-core-rd-dns-sd. 9.7.  <ins> IANA is asked to enter four new items into the Service Names and </ins> Transport Protocol Port Number Registry:  <ins> Service name: "core-rd", Protocol: "udp", Description: "Resource Directory accessed using CoAP" </ins>  <ins> Service name "core-rd-dtls", Protocol: "udp", Description: "Resource Directory accedded using CoAP over DTLS" </ins>  <ins> Service name: "core-rd", Protocol: "tcp", Description: "Resource Directory accessed using CoAP over TCP" </ins>  <ins> Service name "core-rd-tls", Protocol: "tcp", Description: "Resource Directory accedded using CoAP over TLS" All in common have this document as their reference. </ins> 10.


A web entity that stores information about web resources and implements the REST interfaces defined in this specification for <del> registration and lookup of those resources. </del>  In the context of a Resource Directory, a sector is a logical

This is to address Russ's genart comment:
The reflowing commit went here by accident (wrong branch / didn't check on upload). I'm pushing it to master, hoping this makes the PR's diff show only what's intended.

A web entity that stores information about web resources and implements the REST interfaces defined in this specification for  <ins> discovery, for the creation, the maintenance and the removal of registrations, and for lookup of the registered resources. </ins> In the context of a Resource Directory, a sector is a logical


This section describes how the registering endpoint can maintain the registrations that it created.  The registering endpoint can be the <del> registrant-ep or the CT.  An endpoint SHOULD NOT use this interface for registrations that it did not create.  The registrations are resources of the RD. </del>  After the initial registration, the registering endpoint retains the returned location of the Registration Resource for further Search criteria for limiting the number of results (optional).  Page (optional).  Parameter cannot be used without the count parameter.  Results are returned from result set in pages that contain 'count' links starting from index (page * count).  Page registration of endpoints, as a query parameter in lookups, or be expressed as a target attribute, <del> validity requirements if any, </del>  a description,

It appears I've missed some of Alexey's remarks responding to the changes made after his initial review (, 2019-11-20). This contains fixes for the points he still wanted changed / suggested after my original response to his review.

This section describes how the registering endpoint can maintain the registrations that it created.  The registering endpoint can be the  <ins> registrant-ep or the CT.  The registrations are resources of the RD. An endpoint should not use this interface for registrations that it did not create.  This is usually enforced by security policies, which in general require equivalent credentials for creation of and operations on a registration. </ins> After the initial registration, the registering endpoint retains the returned location of the Registration Resource for further Search criteria for limiting the number of results (optional). <ins> The search criteria are an associative array, expressed in a form-style query as per the URI template (see RFC6570 Sections 2.4.2 and 3.2.8) </ins> Page (optional).  Parameter cannot be used without the count parameter.  Results are returned from result set in pages that contain 'count' links starting from index (page * count).  Page registration of endpoints, as a query parameter in lookups, or be expressed as a target attribute,  <ins> syntax and validity requirements if any, </ins> a description,


12.  changes from -23 to -24 Discovery using DNS-SD added again

This is the WIP work to go from "we explain how exactly to do RD security" (and get the details wrong) to "we outline what needs to be considered but it's really up to the application" talked about in URL
(as no single commit has this in its metadata)
From Russ's Genart review: It's tempting to say "squared number of maximum endpoints times security" here. But really what's the error mode here? If a registrant happens to pick something duplicate, it'll get a 4.03 Forbidden. It could then try a different value, but as the RD only "can" (and not MUST) check for collisions, it might have allowed someone else to take our registrant's ep name, and if the registrant was previously successful with that name, it can't change it any more as the RD would refuse it based on the MUST. We can make both MUSTs (the RD already needs to keep a list of used certificates already anyway, it only adds a requirement to use it (possibly via a new index)), but then still, what's a device to do if it receives a 4.03? Change its ep name as this is obviously not the same RD where it had worked before? Just fail? Can or must a device change its name if it is fashioned with a new certificate? Does it need to know the RD's criteria for equivalence of certificates to decide that?
With the text of f98deeee7bd603c7e6b4da2b9936d45a99e18ceb this is easier now (as the error mode in "and require the same properties" is implied to be 4.01); text to follow.

12. <ins> changes in this branch Large rework of section 7 (Security policies) Rather than prescribing which data in the RD _is_ authenticated (and how), it now describes what applications built on an RD _can_ choose to authenticate, show possibilities on how to do it and outline what it means for clients. This addresses Russ' Genart review points on details in the text in a rather broad fashion.  That is because the discussion on the topic inside the WG showed that that text on security has been driven more review-by-review than by the an architectural plan of the authors and WG. Add concrete suggestions (twice as long as registrant number with retries, or UUIDs without) for random endpoint names </ins> changes from -23 to -24 Discovery using DNS-SD added again


endpoint lookup, or resource lookup with filtering on the endpoint name, the RD must ensure that the registrant is authorized to use the given endpoint name.  This applies both to registration and later to <del> operations on the registration resource.  It is immaterial there whether the client is the registrant-ep itself or a CT is doing the </del>  registration: The RD can not tell the difference, and CTs may use authorization credentials authorizing only operations on that particular endpoint name, or a wider range of endpoint names. endpoint name (secure-ep) or whether arbitrary names are accepted (arbitrary-ep). <del> Simple registration could be used to circumvent address based access </del>  control: An attacker would send a simple registration request with the victim's address as source address, and later look up the victim's .well-known/core content in the RD.  Mitigation for this is 12.  changes from -24 to -25 Large rework of section 7 (Security policies)

from URL Next steps: Merge when there is a decision to have a -26
Before the 2020-08-13 telechat, some reviews have come in: : Not Ready Minor: Clarification on "subject" -- my intention was to include anything "subject", but I don't really know what else to put in there. Minor: Why is the first attempt special? -- Can clarify, PR to come. [edit: ] Nits addressed in URL More nits (IDnits) do not require editing, but some explanation -- where would that go? Shepherd writeup? (that would be → NAME : Ready Notes that the DDOS mitigation section is a bit history heavy. I had similar comment in URL; should we use that comment to shorten here? [edit: If so, would want an ACK.] "It is my impression, that Security Considerations were mostly written having in mind that (D)TLS is always used, however it is only "SHOULD" in this draft (or even "MAY" if we look at RFC6690 which Security Considerations this draft refers to). I think that adding a few words describing which consequences for security not using (D)TLS would have and in which cases it is allowed will make the Security Considerations more consistent. " -- [edit: covered in ] I'll issue PRs for what I think we can do something about quickly, but won't merge them or create a -26 without an ACK on them (given we're late in the whole publication stage and my impression is that ill-coordinated uploads do more harm than good) and will follow up on this comment when they're ready for review.
With the additional reviews that have come in today, I see no point in addressing some of what has come in in a pre-telechat update (as we can't resolve all the discuss points) -- taking the urgency off this. I'll still file PRs for changes resulting from the reviewer comments. Procedurally (so this goes to NAME or NAME Is the general expectation with IESG comments that the text be further improved to answer all the points (especially when they are comments), or can a plain "we did it that way because" suffice? In the latter case, would it make sense to collect point-to-point responses here so they get author or WG review before "we" answer them?
With URL and its follow-ups sent out, this is closed; any further comments will be opened as new issues. Hello Reviewers, CoRE and IESG members, thanks for your input to the Resource Directory document, and your patience while it was being processed. Before the individual point to point responses can go out, this mail is to address the general status, and answer a few points that were brought up by different reviewers (it will be referred back to in the point to point responses). In summary, the points raised in the reviews led to the changes of the recently uploaded [-26], and where no changes were made, the reasoning behind the choices in the document is outlined below or in the following mails. (Either way, short of aggregated nits paragraphs, all points are responded to in the following mails). A few larger issues evolved from the review comments being discussed in the interim meetings, so please expect a -27 at a later point (after IETF109) with the changes mentioned below. Kind regards Christian [-26]: URL Preface References into the issue tracker are primarily intended for bookkeeping and to give you access to the altered text if you're curious -- but for general review purposes, the responses are self-contained. Anticipated changes We have opted to submit a new version that should clear out all the other comments, so that the remaining work can be focused and swift: Replay and Freshness (OPEN-REPLAY-FRESHNESS) The comment on DTLS replay made us reevaluate the security properties of operations on the registration resource. While these are successively harder going from DTLS without replay protection to DTLS with replay protection and hardest with OSCORE, the text as it is is still vulnerable to an attacker stopping a reoccurring registration, or undoing alterations in registration attributes. Mitigation from a concurrent document (the Echo mechanism of I-D.ietf-core-echo-request-tag in event freshness mode) is planned, but the text is not complete yet. Necessity of the value in all responses The requirements around Limited Link Format and the necessity to express all looked up links in fully resolved form have stemmed from different ways RFC6690 has been read, both in the IETF community and by implementers. A comment from Esko Dijk has shown a clear error in one of the readings. That reading is single-handedly responsible for most of the overhead in the wire format (savings can go up to 50%), which is of high importance to the CoRE field. Due to that, it is the WG's and authors' intention to remove the reading from the set of interpretations that led to the rules set forth. The change will not render any existing RD server implementation incompatible (older RDs would merely be needlessly verbose), and the known implementations of Link-Format parsers can easily be updated. The updates to the document could not be completed in time with the rest of the changes, because a) it requires revisiting the known implementations for confirmation and b) will affect almost every example that contains lookup results. Server authorization (OPEN-SERVER) The two areas of "how is the RD discovery secured" and "what do applications based on the RD need to consider" jointly opened up new questions about server authorization and the linkage between a client's intention and the server's promises that may easily not conclusde in timeframe reasonable for RD. While steps have been taken to address the issue both on the RD discovery and the applications side (URL), the ongoing discussions in the working group may turn up with a less cumbersome phrasing for these parts. There's a few small open issues Esko brought up on the issue tracker that could not be addressed in time; most of them are about enhancing the examples, which best happens after the anchor cleanup anyway. Repeated topics A few common topics came up in multiple reviews, and are addressed in the following section; the individual responses can be found in follow-up mails, and refer to the common topics as necesary. GENERIC-FFxxDB "Where do the ff35:30:2001:... addresses come from?" response: There's a coverage gap between RFC3849 (defining example unicast addresses) and RFC3306 (defining unicast-prefix-based multicast addresses). For lack of an agreed-on example multicast address, the used ones were created by applying the unicast-prefix derivation process to the example address. The results (ff35:30:2001:db8::1) should be intuitively recognizable both as a multicast address and as an example address. The generated address did, however, fail to follow the guidance of RFC 3307 and set the first bit of the Group ID. Consequently, the addresses were changed from ff35:30:2001:db8::x to ff35:30:2001:db8::8000:x, which should finally be a legal choice of a group address for anyone operating the 2001:db8:: site. (The changes can be viewed at URL). GENERIC-6MAN "Whas this discussed with 6MAN?" response: Not yet; a request for feedback was sent out recently. (Mail at URL). GENERIC-WHOPICKSMODEL "How does the client know which security policies the RD supports?" response: The client can only expect any level of trustworthiness if there is a claim to that in the RD's credentials. Typically, though, that claim will not be encoded there, but implied. For example, when configuring an application that relies authenticated endpoint names, then telling the application to use the RD authenticated via PKI as URL should only be done if the configurator is sure that URL will do the required checks on endpoint names. Some clarification has been added in URL GENERIC-SUBJECT "Section 7.1 says: '... can be transported in the subject.' -- where precisely?" response: That text was only meant to illustrate to the reader what such a policy could contain, not to set one (which would require more precision). It has been made more explicit that this is merely setting the task for the policies. As an example, some more precision is given by referring to SubjectAltName dNSName entries. Changes in URL (If you have read up to this point, please continue reading the follow-up mails addressing the individual reviewer's points.)

endpoint lookup, or resource lookup with filtering on the endpoint name, the RD must ensure that the registrant is authorized to use the given endpoint name.  This applies both to registration and later to  <ins> operations on the registration resource.  It is immaterial whether the client is the registrant-ep itself or a CT is doing the </ins> registration: The RD can not tell the difference, and CTs may use authorization credentials authorizing only operations on that particular endpoint name, or a wider range of endpoint names. endpoint name (secure-ep) or whether arbitrary names are accepted (arbitrary-ep).  <ins> Simple registration could be used to circumvent address-based access </ins> control: An attacker would send a simple registration request with the victim's address as source address, and later look up the victim's .well-known/core content in the RD.  Mitigation for this is 12. <ins> changes from -25 to -26 Minor editorial fixes in response to Gen-ART review. </ins> changes from -24 to -25 Large rework of section 7 (Security policies)


8.3. Services that run over UDP unprotected are vulnerable to unknowingly <del> become part of a DDoS attack as UDP does not require return routability check.  Therefore, an attacker can easily spoof the source IP of the target entity and send requests to such a service which would then respond to the target entity.  This can be used for large-scale DDoS attacks on the target.  Especially, if the service returns a response that is order of magnitudes larger than the request, the situation becomes even worse as now the attack can be amplified.  DNS servers have been widely used for DDoS amplification attacks.  There is also a danger that NTP Servers could become implicated in denial-of-service (DoS) attacks since they run on unprotected UDP, there is no return routability check, and they can have a large amplification factor.  The responses from the NTP server were found to be 19 times larger than the request.  An RD which responds to wild-card lookups is potentially vulnerable if run with CoAP over UDP.  Since there is no return routability check and the responses can be significantly larger than requests, RDs can unknowingly become part of a DDoS amplification attack. </del>  RFC7252 describes this at length in its Section 11.3, including some mitigation by using small block sizes in responses.  The upcoming I- a row is way below that because only the colliding node(s) will retry).  changes from -24 to -25 Large rework of section 7 (Security policies)

This addresses a note from the SecDir review[1] and follows an earlier suggestion[2]. [1]: URL [2]: URL
Before the 2020-08-13 telechat, some reviews have come in: : Not Ready Minor: Clarification on "subject" -- my intention was to include anything "subject", but I don't really know what else to put in there. Minor: Why is the first attempt special? -- Can clarify, PR to come. [edit: ] Nits addressed in URL More nits (IDnits) do not require editing, but some explanation -- where would that go? Shepherd writeup? (that would be → NAME : Ready Notes that the DDOS mitigation section is a bit history heavy. I had similar comment in URL; should we use that comment to shorten here? [edit: If so, would want an ACK.] "It is my impression, that Security Considerations were mostly written having in mind that (D)TLS is always used, however it is only "SHOULD" in this draft (or even "MAY" if we look at RFC6690 which Security Considerations this draft refers to). I think that adding a few words describing which consequences for security not using (D)TLS would have and in which cases it is allowed will make the Security Considerations more consistent. " -- [edit: covered in ] I'll issue PRs for what I think we can do something about quickly, but won't merge them or create a -26 without an ACK on them (given we're late in the whole publication stage and my impression is that ill-coordinated uploads do more harm than good) and will follow up on this comment when they're ready for review.
With the additional reviews that have come in today, I see no point in addressing some of what has come in in a pre-telechat update (as we can't resolve all the discuss points) -- taking the urgency off this. I'll still file PRs for changes resulting from the reviewer comments. Procedurally (so this goes to NAME or NAME Is the general expectation with IESG comments that the text be further improved to answer all the points (especially when they are comments), or can a plain "we did it that way because" suffice? In the latter case, would it make sense to collect point-to-point responses here so they get author or WG review before "we" answer them?
With URL and its follow-ups sent out, this is closed; any further comments will be opened as new issues.
From Adam's Secdir review, this is something we should address. The hard part is the "how", as echo-request-tag is about to update 7252 with a concrete suggestion (which would apply to RD implicitly), but saying that here would create a normative (forward? they're not far apart) reference between otherwise unrelated documents. It might be worth adding a note that a simple registration doesn't need special consideration in that respect, as the GET .well-known/core is not significantly larger than the POST /rd -- at least from a DDOS point of view. (By the way, that whole paragraph is quite a mouthful, reads a bit like a history lesson -- I wonder why that didn't occur to me earlier, but changing such things now is probably hard; let's leave it to a summarizing "but in the end that's what you do against it") Hello Reviewers, CoRE and IESG members, thanks for your input to the Resource Directory document, and your patience while it was being processed. Before the individual point to point responses can go out, this mail is to address the general status, and answer a few points that were brought up by different reviewers (it will be referred back to in the point to point responses). In summary, the points raised in the reviews led to the changes of the recently uploaded [-26], and where no changes were made, the reasoning behind the choices in the document is outlined below or in the following mails. (Either way, short of aggregated nits paragraphs, all points are responded to in the following mails). A few larger issues evolved from the review comments being discussed in the interim meetings, so please expect a -27 at a later point (after IETF109) with the changes mentioned below. Kind regards Christian [-26]: URL Preface References into the issue tracker are primarily intended for bookkeeping and to give you access to the altered text if you're curious -- but for general review purposes, the responses are self-contained. Anticipated changes We have opted to submit a new version that should clear out all the other comments, so that the remaining work can be focused and swift: Replay and Freshness (OPEN-REPLAY-FRESHNESS) The comment on DTLS replay made us reevaluate the security properties of operations on the registration resource. While these are successively harder going from DTLS without replay protection to DTLS with replay protection and hardest with OSCORE, the text as it is is still vulnerable to an attacker stopping a reoccurring registration, or undoing alterations in registration attributes. Mitigation from a concurrent document (the Echo mechanism of I-D.ietf-core-echo-request-tag in event freshness mode) is planned, but the text is not complete yet. Necessity of the value in all responses The requirements around Limited Link Format and the necessity to express all looked up links in fully resolved form have stemmed from different ways RFC6690 has been read, both in the IETF community and by implementers. A comment from Esko Dijk has shown a clear error in one of the readings. That reading is single-handedly responsible for most of the overhead in the wire format (savings can go up to 50%), which is of high importance to the CoRE field. Due to that, it is the WG's and authors' intention to remove the reading from the set of interpretations that led to the rules set forth. The change will not render any existing RD server implementation incompatible (older RDs would merely be needlessly verbose), and the known implementations of Link-Format parsers can easily be updated. The updates to the document could not be completed in time with the rest of the changes, because a) it requires revisiting the known implementations for confirmation and b) will affect almost every example that contains lookup results. Server authorization (OPEN-SERVER) The two areas of "how is the RD discovery secured" and "what do applications based on the RD need to consider" jointly opened up new questions about server authorization and the linkage between a client's intention and the server's promises that may easily not conclusde in timeframe reasonable for RD. While steps have been taken to address the issue both on the RD discovery and the applications side (URL), the ongoing discussions in the working group may turn up with a less cumbersome phrasing for these parts. There's a few small open issues Esko brought up on the issue tracker that could not be addressed in time; most of them are about enhancing the examples, which best happens after the anchor cleanup anyway. Repeated topics A few common topics came up in multiple reviews, and are addressed in the following section; the individual responses can be found in follow-up mails, and refer to the common topics as necesary. GENERIC-FFxxDB "Where do the ff35:30:2001:... addresses come from?" response: There's a coverage gap between RFC3849 (defining example unicast addresses) and RFC3306 (defining unicast-prefix-based multicast addresses). For lack of an agreed-on example multicast address, the used ones were created by applying the unicast-prefix derivation process to the example address. The results (ff35:30:2001:db8::1) should be intuitively recognizable both as a multicast address and as an example address. The generated address did, however, fail to follow the guidance of RFC 3307 and set the first bit of the Group ID. Consequently, the addresses were changed from ff35:30:2001:db8::x to ff35:30:2001:db8::8000:x, which should finally be a legal choice of a group address for anyone operating the 2001:db8:: site. (The changes can be viewed at URL). GENERIC-6MAN "Whas this discussed with 6MAN?" response: Not yet; a request for feedback was sent out recently. (Mail at URL). GENERIC-WHOPICKSMODEL "How does the client know which security policies the RD supports?" response: The client can only expect any level of trustworthiness if there is a claim to that in the RD's credentials. Typically, though, that claim will not be encoded there, but implied. For example, when configuring an application that relies authenticated endpoint names, then telling the application to use the RD authenticated via PKI as URL should only be done if the configurator is sure that URL will do the required checks on endpoint names. Some clarification has been added in URL GENERIC-SUBJECT "Section 7.1 says: '... can be transported in the subject.' -- where precisely?" response: That text was only meant to illustrate to the reader what such a policy could contain, not to set one (which would require more precision). It has been made more explicit that this is merely setting the task for the policies. As an example, some more precision is given by referring to SubjectAltName dNSName entries. Changes in URL (If you have read up to this point, please continue reading the follow-up mails addressing the individual reviewer's points.)

8.3. Services that run over UDP unprotected are vulnerable to unknowingly  <ins> amplify and distribute a DoS attack as UDP does not require return routability check.  Since RD lookup responses can be significantly larger than requests, RDs are prone to this. </ins> RFC7252 describes this at length in its Section 11.3, including some mitigation by using small block sizes in responses.  The upcoming I- a row is way below that because only the colliding node(s) will retry). <ins> Security considerations: Shorten amplification mitigation by removing the references to earlier cases of DDoS amplification, and by removing redundancies between the problem introduction and the description of how an RD could become part of the problem. </ins> changes from -24 to -25 Large rework of section 7 (Security policies)


The security considerations as described in Section 5 of RFC8288 and Section 6 of RFC6690 apply.  The "/.well-known/core" resource may be protected e.g. using DTLS when hosted on a CoAP server as described <del> in RFC7252.  DTLS or TLS based security SHOULD be used on all resource directory interfaces defined in this document. </del>  8.1. level as possible.  For example access control for lookups could be performed either at the sector, endpoint or resource level.  8.3. Services that run over UDP unprotected are vulnerable to unknowingly a row is way below that because only the colliding node(s) will retry). <del> Security considerations: Shorten amplification mitigation by removing the references to earlier cases of DDoS amplification, and by removing redundancies between the problem introduction and the description of how an RD could become part of the problem. </del>  changes from -24 to -25

This is in response to a note from the SecDir review[1]. It harmonizes the general SHOULD of using protection with the policies text of being application specific, adds OSCORE to the options (the text there was simply not touched since OSCORE became an option for CoAP), and points to where it says more about what comes from not following that recommendation (for the access control part; there is already an example in the endpoint identification part). [1]: URL Part of the changes -- will merge only when ACKed; then it'd go into -26.
Merged while processing the previous interim's discussion outcome.
Before the 2020-08-13 telechat, some reviews have come in: : Not Ready Minor: Clarification on "subject" -- my intention was to include anything "subject", but I don't really know what else to put in there. Minor: Why is the first attempt special? -- Can clarify, PR to come. [edit: ] Nits addressed in URL More nits (IDnits) do not require editing, but some explanation -- where would that go? Shepherd writeup? (that would be → NAME : Ready Notes that the DDOS mitigation section is a bit history heavy. I had similar comment in URL; should we use that comment to shorten here? [edit: If so, would want an ACK.] "It is my impression, that Security Considerations were mostly written having in mind that (D)TLS is always used, however it is only "SHOULD" in this draft (or even "MAY" if we look at RFC6690 which Security Considerations this draft refers to). I think that adding a few words describing which consequences for security not using (D)TLS would have and in which cases it is allowed will make the Security Considerations more consistent. " -- [edit: covered in ] I'll issue PRs for what I think we can do something about quickly, but won't merge them or create a -26 without an ACK on them (given we're late in the whole publication stage and my impression is that ill-coordinated uploads do more harm than good) and will follow up on this comment when they're ready for review.
With the additional reviews that have come in today, I see no point in addressing some of what has come in in a pre-telechat update (as we can't resolve all the discuss points) -- taking the urgency off this. I'll still file PRs for changes resulting from the reviewer comments. Procedurally (so this goes to NAME or NAME Is the general expectation with IESG comments that the text be further improved to answer all the points (especially when they are comments), or can a plain "we did it that way because" suffice? In the latter case, would it make sense to collect point-to-point responses here so they get author or WG review before "we" answer them?
With URL and its follow-ups sent out, this is closed; any further comments will be opened as new issues. Hello Reviewers, CoRE and IESG members, thanks for your input to the Resource Directory document, and your patience while it was being processed. Before the individual point to point responses can go out, this mail is to address the general status, and answer a few points that were brought up by different reviewers (it will be referred back to in the point to point responses). In summary, the points raised in the reviews led to the changes of the recently uploaded [-26], and where no changes were made, the reasoning behind the choices in the document is outlined below or in the following mails. (Either way, short of aggregated nits paragraphs, all points are responded to in the following mails). A few larger issues evolved from the review comments being discussed in the interim meetings, so please expect a -27 at a later point (after IETF109) with the changes mentioned below. Kind regards Christian [-26]: URL Preface References into the issue tracker are primarily intended for bookkeeping and to give you access to the altered text if you're curious -- but for general review purposes, the responses are self-contained. Anticipated changes We have opted to submit a new version that should clear out all the other comments, so that the remaining work can be focused and swift: Replay and Freshness (OPEN-REPLAY-FRESHNESS) The comment on DTLS replay made us reevaluate the security properties of operations on the registration resource. While these are successively harder going from DTLS without replay protection to DTLS with replay protection and hardest with OSCORE, the text as it is is still vulnerable to an attacker stopping a reoccurring registration, or undoing alterations in registration attributes. Mitigation from a concurrent document (the Echo mechanism of I-D.ietf-core-echo-request-tag in event freshness mode) is planned, but the text is not complete yet. Necessity of the value in all responses The requirements around Limited Link Format and the necessity to express all looked up links in fully resolved form have stemmed from different ways RFC6690 has been read, both in the IETF community and by implementers. A comment from Esko Dijk has shown a clear error in one of the readings. That reading is single-handedly responsible for most of the overhead in the wire format (savings can go up to 50%), which is of high importance to the CoRE field. Due to that, it is the WG's and authors' intention to remove the reading from the set of interpretations that led to the rules set forth. The change will not render any existing RD server implementation incompatible (older RDs would merely be needlessly verbose), and the known implementations of Link-Format parsers can easily be updated. The updates to the document could not be completed in time with the rest of the changes, because a) it requires revisiting the known implementations for confirmation and b) will affect almost every example that contains lookup results. Server authorization (OPEN-SERVER) The two areas of "how is the RD discovery secured" and "what do applications based on the RD need to consider" jointly opened up new questions about server authorization and the linkage between a client's intention and the server's promises that may easily not conclusde in timeframe reasonable for RD. While steps have been taken to address the issue both on the RD discovery and the applications side (URL), the ongoing discussions in the working group may turn up with a less cumbersome phrasing for these parts. There's a few small open issues Esko brought up on the issue tracker that could not be addressed in time; most of them are about enhancing the examples, which best happens after the anchor cleanup anyway. Repeated topics A few common topics came up in multiple reviews, and are addressed in the following section; the individual responses can be found in follow-up mails, and refer to the common topics as necesary. GENERIC-FFxxDB "Where do the ff35:30:2001:... addresses come from?" response: There's a coverage gap between RFC3849 (defining example unicast addresses) and RFC3306 (defining unicast-prefix-based multicast addresses). For lack of an agreed-on example multicast address, the used ones were created by applying the unicast-prefix derivation process to the example address. The results (ff35:30:2001:db8::1) should be intuitively recognizable both as a multicast address and as an example address. The generated address did, however, fail to follow the guidance of RFC 3307 and set the first bit of the Group ID. Consequently, the addresses were changed from ff35:30:2001:db8::x to ff35:30:2001:db8::8000:x, which should finally be a legal choice of a group address for anyone operating the 2001:db8:: site. (The changes can be viewed at URL). GENERIC-6MAN "Whas this discussed with 6MAN?" response: Not yet; a request for feedback was sent out recently. (Mail at URL). GENERIC-WHOPICKSMODEL "How does the client know which security policies the RD supports?" response: The client can only expect any level of trustworthiness if there is a claim to that in the RD's credentials. Typically, though, that claim will not be encoded there, but implied. For example, when configuring an application that relies authenticated endpoint names, then telling the application to use the RD authenticated via PKI as URL should only be done if the configurator is sure that URL will do the required checks on endpoint names. Some clarification has been added in URL GENERIC-SUBJECT "Section 7.1 says: '... can be transported in the subject.' -- where precisely?" response: That text was only meant to illustrate to the reader what such a policy could contain, not to set one (which would require more precision). It has been made more explicit that this is merely setting the task for the policies. As an example, some more precision is given by referring to SubjectAltName dNSName entries. Changes in URL (If you have read up to this point, please continue reading the follow-up mails addressing the individual reviewer's points.)

The security considerations as described in Section 5 of RFC8288 and Section 6 of RFC6690 apply.  The "/.well-known/core" resource may be protected e.g. using DTLS when hosted on a CoAP server as described  <ins> in RFC7252. Access that is limited or affects sensitive data SHOULD be protected, e.g. using (D)TLS or OSCORE (RFC8613; which aspects of the RD this affects depends on the security policies of the application (see policies). </ins> 8.1. level as possible.  For example access control for lookups could be performed either at the sector, endpoint or resource level. <ins> The precise access controls necessary (and the consequences of failure to enforce them) depend on the protection objectives of the application and the security policies (policies) derived from them. </ins> 8.3. Services that run over UDP unprotected are vulnerable to unknowingly a row is way below that because only the colliding node(s) will retry).  <ins> Security considerations: List all current options for security layers usable with CoAP (OSCORE was missing as the text predated RFC8613) Relax the previous SHOULD on secure access to SHOULD where protection is indicated by security policies (bringing the text in line with the -25 changes) Point out that failure to follow the security considerations has implications depending on the protection objective described with the security policies Shorten amplification mitigation by removing the references to earlier cases of DDoS amplification, and by removing redundancies between the problem introduction and the description of how an RD could become part of the problem. </ins> changes from -24 to -25


examples throughout these sections assume the use of CoAP RFC7252, these REST interfaces can also be realized using HTTP RFC7230.  Only multicast discovery operations are not possible on HTTP, and Simple <del> Registration can not be executed as base attribute (which is </del>  mandatory for HTTP) can not be used there.  In all definitions in these sections, both CoAP response codes (with dot notation) and HTTP response codes (without dot notation) are shown.  An RD implementing In networks managed using DNS-SD, the use of DNS-SD for discovery as described in rd-using-dnssd is recommended. <del> The use of multicast discovery in mesh networks is NOT recommended. </del>  4.1.1. identify the components that constitute the RD server.  The identification refers to information about for example client-server incompatibilities, supported features, required updates and other <del> aspects.  The URI discovery address, a described in section 4 of </del>  RFC6690 can be used to find the identification. It would typically be stored in an implementation information link href or anchor was submitted as a (full) URI are returned with these attributes unmodified. <del> Above rules allow the client to interpret the response as links </del>  without any further knowledge of the storage conventions of the RD. The RD MAY replace the registration base URIs with a configured intermediate proxy, e.g. in the case of an HTTP lookup interface for for endpoints SHOULD be expressed in path-absolute form if possible and MUST be expressed in URI form otherwise; the RD SHOULD recognize either.  The "anchor" attribute is usable for resource lookups, and, <del> if queried, MUST be for in URI form as well. </del>  Endpoints that are interested in a lookup result repeatedly or continuously can use mechanisms like ETag caching, resource As above, the impact of undesirable links depends on the extent to which the lookup client relies on the RD.  To avoid the limitations, <del> RD applications should consider prescribe that lookup clients only </del>  use the discovered information as hints, and describe which pieces of information need to be verified with the server because they impact the application's security. network manager. At the moment of installation, the network under installation is not <del> necessarily connected to the DNS infra structure.  Therefore, SLAAC </del>  IPv6 addresses are assigned to CT, RD, luminaries and sensor shown in interface-S below:

Thanks, merged. (If questions come up around the normative-language RECOMMENDED: I agere that from the capitals NOT before it, this was already intended to be normative.)

examples throughout these sections assume the use of CoAP RFC7252, these REST interfaces can also be realized using HTTP RFC7230.  Only multicast discovery operations are not possible on HTTP, and Simple  <ins> Registration can not be executed as the base attribute (which is </ins> mandatory for HTTP) can not be used there.  In all definitions in these sections, both CoAP response codes (with dot notation) and HTTP response codes (without dot notation) are shown.  An RD implementing In networks managed using DNS-SD, the use of DNS-SD for discovery as described in rd-using-dnssd is recommended.  <ins> The use of multicast discovery in mesh networks is NOT RECOMMENDED. </ins> 4.1.1. identify the components that constitute the RD server.  The identification refers to information about for example client-server incompatibilities, supported features, required updates and other  <ins> aspects.  The URI discovery address, as described in section 4 of </ins> RFC6690 can be used to find the identification. It would typically be stored in an implementation information link href or anchor was submitted as a (full) URI are returned with these attributes unmodified.  <ins> The above rules allow the client to interpret the response as links </ins> without any further knowledge of the storage conventions of the RD. The RD MAY replace the registration base URIs with a configured intermediate proxy, e.g. in the case of an HTTP lookup interface for for endpoints SHOULD be expressed in path-absolute form if possible and MUST be expressed in URI form otherwise; the RD SHOULD recognize either.  The "anchor" attribute is usable for resource lookups, and,  <ins> if queried, MUST be in URI form as well. </ins> Endpoints that are interested in a lookup result repeatedly or continuously can use mechanisms like ETag caching, resource As above, the impact of undesirable links depends on the extent to which the lookup client relies on the RD.  To avoid the limitations,  <ins> RD applications should consider prescribing that lookup clients only </ins> use the discovered information as hints, and describe which pieces of information need to be verified with the server because they impact the application's security. network manager. At the moment of installation, the network under installation is not  <ins> necessarily connected to the DNS infrastructure.  Therefore, SLAAC </ins> IPv6 addresses are assigned to CT, RD, luminaries and sensor shown in interface-S below:


The RD is primarily a tool to make discovery operations more efficient than querying /.well-known/core on all connected devices, <del> or across boundaries that would be limiting those operations. </del>  It provides information about resources hosted by other devices that could otherwise only be obtained by directly querying the /.well- 3.4. Registration Base URIs can contain link-local IP addresses.  To be <del> usable across hosts, those can not be serialized to contain zone </del>  identifiers (see RFC6874 Section 1). Link-local addresses can only be used on a single link (therefore RD <del> servers can not announce them when queried on a different link), and </del>  lookup clients using them need to keep track of which interface they got them from. examples throughout these sections assume the use of CoAP RFC7252, these REST interfaces can also be realized using HTTP RFC7230.  Only multicast discovery operations are not possible on HTTP, and Simple <del> Registration can not be executed as the base attribute (which is mandatory for HTTP) can not be used there.  In all definitions in </del>  these sections, both CoAP response codes (with dot notation) and HTTP response codes (without dot notation) are shown.  An RD implementing this specification MUST support the discovery, registration, update, it MUST include the base parameter in the registration to provide a valid network path. <del> A registrant that can not be reached by potential lookup clients at the address it registers from (e.g. because it is behind some form of Network Address Translation (NAT)) MUST provide a reachable base address with its registration. </del>  If the Base URI contains a link-local IP literal, it MUST NOT contain a Zone Identifier, and MUST be local to the link on which the registration request is received. Endpoints that register with a base that contains a path <del> component can not meaningfully use RFC6690 Link Format due to </del>  its prevalence of the Origin concept in relative reference resolution.  Those applications should use different representations of links to which limitedlinkformat is not using DELETE, and to perform further operations beyond the scope of this specification. <del> These operations are described below. </del>  5.3.1. given endpoint name.  This applies both to registration and later to operations on the registration resource.  It is immaterial whether the client is the registrant-ep itself or a CT is doing the <del> registration: The RD can not tell the difference, and CTs may use </del>  authorization credentials authorizing only operations on that particular endpoint name, or a wider range of endpoint names. In those situations, the registrant needs to be careful to authenticate the RD as well.  The registrant needs to know in advance which AS, audience and scope values indicate an RD it may trust for <del> this purpose, and can not rely on the RD to provide AS address and </del>  token details.  (In contrast, in the other scenarios it may try to register, and follow the pointers the RD gives it as to which credentials it needs to provide in order to perform its

Will merge before the interim to have a discussion on the big stuff with the small stuff out of the way.

The RD is primarily a tool to make discovery operations more efficient than querying /.well-known/core on all connected devices,  <ins> or across boundaries that would limit those operations. </ins> It provides information about resources hosted by other devices that could otherwise only be obtained by directly querying the /.well- 3.4. Registration Base URIs can contain link-local IP addresses.  To be  <ins> usable across hosts, those cannot be serialized to contain zone </ins> identifiers (see RFC6874 Section 1). Link-local addresses can only be used on a single link (therefore RD  <ins> servers cannot announce them when queried on a different link), and </ins> lookup clients using them need to keep track of which interface they got them from. examples throughout these sections assume the use of CoAP RFC7252, these REST interfaces can also be realized using HTTP RFC7230.  Only multicast discovery operations are not possible on HTTP, and Simple  <ins> Registration cannot be executed as the base attribute (which is mandatory for HTTP) cannot be used there.  In all definitions in </ins> these sections, both CoAP response codes (with dot notation) and HTTP response codes (without dot notation) are shown.  An RD implementing this specification MUST support the discovery, registration, update, it MUST include the base parameter in the registration to provide a valid network path.  <ins> A registrant that cannot be reached by potential lookup clients at the address it registers from (e.g. because it is behind some form of Network Address Translation (NAT)) MUST provide a reachable base address with its registration. </ins> If the Base URI contains a link-local IP literal, it MUST NOT contain a Zone Identifier, and MUST be local to the link on which the registration request is received. Endpoints that register with a base that contains a path  <ins> component cannot meaningfully use RFC6690 Link Format due to </ins> its prevalence of the Origin concept in relative reference resolution.  Those applications should use different representations of links to which limitedlinkformat is not using DELETE, and to perform further operations beyond the scope of this specification.  <ins> The operations on the Registration Resource are described below. </ins> 5.3.1. given endpoint name.  This applies both to registration and later to operations on the registration resource.  It is immaterial whether the client is the registrant-ep itself or a CT is doing the  <ins> registration: The RD cannot tell the difference, and CTs may use </ins> authorization credentials authorizing only operations on that particular endpoint name, or a wider range of endpoint names. In those situations, the registrant needs to be careful to authenticate the RD as well.  The registrant needs to know in advance which AS, audience and scope values indicate an RD it may trust for  <ins> this purpose, and cannot rely on the RD to provide AS address and </ins> token details.  (In contrast, in the other scenarios it may try to register, and follow the pointers the RD gives it as to which credentials it needs to provide in order to perform its


4.04 "Not Found" or 404 "Not Found".  Registration does not exist (e.g. may have been removed). <del> If the registration fails in any way, including "Not Found" and request timeouts, or if the time indicated in a Service Unavailable Max-Age/Retry-After exceeds the remaining lifetime, the registering endpoint SHOULD attempt registration again. </del>  The following example shows how the registering endpoint updates its registration resource at an RD using this interface with the example

Will still grow while I'm working through the latest discusses/comments; these are things not directly mentioned there but small errors that became obvious when working through the document to prepare responses and/or when preparing patches to address the issues.

4.04 "Not Found" or 404 "Not Found".  Registration does not exist (e.g. may have been removed).  <ins> If the registration update fails in any way, including "Not Found" and request timeouts, or if the time indicated in a Service Unavailable Max-Age/Retry-After exceeds the remaining lifetime, the registering endpoint SHOULD attempt registration again. </ins> The following example shows how the registering endpoint updates its registration resource at an RD using this interface with the example


mandate the use of the sector parameter on all operations, as no credentials are suitable for operations across sector borders anyway.  8. The security considerations as described in Section 5 of RFC8288 and Remove speculation about how in detail ACE scopes are obtained.  changes from -24 to -25 Large rework of section 7 (Security policies)

Closes: URL
I'd appreciate a pair of eyes on this before tomorrow's interim, given my was flawed in several respects, and I'm not sure I got all the fixes right.
A question to be raised today is whether this should contain a note that where one wants endpoint names from certificates ("the other proposal" from ), they can write it up per application or make a short document of it.
Looking into the COSE!=CWT more deeply, I now think that they are not even mutually exclusive (TLS X.509 client certificate with SubjectAltName and a CWT posted to /token with a subj claim? TLS with CWT as certificate, and an X.509 posted to token? Reminds me of IP-over-DNS-over-HTTP-over-QUIC. Not that I'd do that...), so I'll send this through one more iteration that just takes the bag of all found (subject, authority) claims and requires them. Might make phrasing it easier, even.
From Ben's review DISCUSS at : There's two contenders for such a model: first-come-first-served with concrete guidance on what suffices for later updates fixed ep names The former is what I prefer (because I see the latter as a more niche application in tightly managed setups, whereas the former has the general application of providing discoverability without multicast), the latter is simpler. I'm starting work on a text for the first-come-first-served for tomorrow's interim.
Also playing in here from :
Quick scribble of a proposal in keywords: RDs remember information about a device for at least the active lifetime, preferably longer (but without obligation). The information they remember is the generally the most abstract they can be confident to represent the single device. Device authenticates with... DTLS without client authentication: Same (or resumed) session DTLS with self-signed certificate: Same certificate (by fingerprint) DTLS with certs that chain to a host name (with input from URL) if they're valid to authenticate as a server: Same host name (independent of chain) OSCORE from ace-oscore-profile: Same token (Does that even make sense? Is there any generic claim about client identity that can be in there?) OSCORE from LAKE with referenced certificate: as in DTLS OSCORE from LAKE with RPK: Same RPK Clients must register without sector. RD may put them into a sector of a configured name.
for ACE: subject claim (or having the same PSK or possibly signed CWT identifier)
Hostname or subject identifier; if it does not exist: go for the public key. Thanks for the updates in the -26; they help a lot. I'm particularly happy to see the (default/example) "first-come-first-remembered" policy in § 7.5, which does a good job of documenting its properties (including potential deficiencies) and can be usable for many environments.  (I do have some suggestions for improvements to the specific wording in the section-by-section comments, but on the whole I like it.) It does lead in to a more general comment, though (which is not exactly new to the changes in the -26 though it is reflected in several of them): some aspects of the concept of "authorization" to appear in a directory, and the verification of authorization for the entire flow from client locating the RD server to final request at the discovered resource, are somewhat subtle.  (The new text discusses, e.g., "repeat the URI discovery step at the /.well-known/core resource of the indicated host to obtain the resource type information from an authorized source" and "a straightforward way to verify [discovered information] is to request it again from an authorized server, typically the one that hosts the target resource".)  The aspects I'm concerned about are not matters of a resource server being authorized to publish to a directory or a client deeming that a server is authorized to act as an RD (though both of those are also important), but seems to rather just be relating to the RD faithfully disseminating the information the RD retrieved from /.well-known/core discovery on the given server(s) (or otherwise learned via some other mechanism). In this sense the RD is just acting as a cache or efficiency aid, but the authoritative source of the information remains (in general) the server hosting the resource.  To be clear, I think the procedures that this document specifies are good and correct procedures for a client to perform, I'm just not sure whether "authorized" is the right term in these cases; "authoritative" might be more appropriate, in that the operation in question is to verify the information retrieved from the RD (which acts in some sense as an intermediary) at the more authoritative source. (On a tangent from that note, it seems that there is not necessarily any indication to a client that a server claiming to provide a given resource (whether discovered via RD or /.well-known/core) is actually authorized to provide such a resource and be trusted by the client.  But that's not really a property of RD, and rather the underlying CoRE mechanism and any provisioned trust database, so my thoughts about it seem out of scope for this document.) (It's not entirely clear to me what the reader is expected to do with the information about the previous formulation.) (It seems that something also needs to cause the RD to check the authorization of lookup clients to receive the information in question, which might be worth reiterating in this section.) I'm pretty sure the intent here is that only the subject names that are certified by the recognized authority(ies) are stored, in which case I'd suggest to s/all those/all such/. (I can understand why the "store the whole list" logic is used, though there may be some subtleties about name constraints on the (X.509) CAs used, which is why we typically don't recomment treating the entire list of names in the certificate as validated from a single operation, instead preferring "is this certificate authenticated for this specific name?" when the specific target name is available.) Should we talk about whether the lifetime of registration entries is related to the various lifetimes of these credentials/identifiers?  DTLS without resumption is perhaps an interesting case, in that keeping the DTLS association "live" just to be able to update the registration information seems impractical, so perhaps some fixed cap would be applied on the lifetime in that case.  If resumption is used, the resumption information (ticket or session state) has some finite lifetime that could be used to bound the lifetime of the registration. IIRC an OSCORE security context can also have an expiration time; certificates and JWT/CWT have expiration time as well (though the procedures in the first bullet point would effectively allow a "renewal" operation), but the validity period (if any) of a raw public key would have to be provisioned along with that key (or just have RPK be handled akin to DTLS without resumption, I guess). (Similar to my earlier parenthetical comment, the requirement for exact match of all subject name information is unusual.  In effect this is a way of pinning the set of names that the CA has chosen to include in a single certificate, which is arguably a stronger requirement than needed but should not lead to any unauthorized access.)
Thanks for addressing my DISCUSS and COMMENT feedback

mandate the use of the sector parameter on all operations, as no credentials are suitable for operations across sector borders anyway. <ins> 7.5. The First-Come-First-Remembered policy is provided both as a reference example for a security policy definition, and as a policy that implementations may choose to use as default policy in absence of other configuration.  It is designed to enable efficient discovery operations even in ad-hoc settings. Under this policy, the RD accepts registrations for any endpoint name that is not assigned to an active registration resource, and only accepts registration updates from the same endpoint.  The policy is minimal in that towards lookup clients it does not make any of the claims of entered-resources and link-confidentiality, and its claims on secure-ep are limited to the lifetime of that endpoint's registration.  It does, however, guarantee towards any endpoint that for the duration of its registration, its links will be discoverable on the RD. When a registration or operation is attempted, the RD MUST determine the client's subject name or public key: If the client's credentials indicate any subject name that is certified by any authority which the RD recognizes (which may be the system's trust anchor store), all those subject names are stored.  With CWT or JWT based credentials (as common with ACE), the Subject (sub) claim is stored as a single name, if it exists. With X.509 certificates, the Common Name (CN) and the complete list of SubjectAltName entries are stored.  In both cases, the authority that certified the claim is stored along with the subject, as the latter may only be locally unique. Otherwise, if the client proves possession of a private key, the matching public key is stored.  This applies both to raw public keys and to the public keys indicated in certificates that failed the above authority check. If neither is present, a reference to the security session itself is stored.  With (D)TLS, that is the connection itself, or the session resumption information if available.  With OSCORE, that is the security context. As part of the registration operation, that information is stored along with the registration resource. The RD MUST accept all registrations whose registration resource is not already active, as long as they are made using a security layer supported by the RD. Any operation on a registration resource, including registrations that lead to an existing registration resource, MUST be rejected by the RD unless all the stored information is found in the new request's credentials. Note that even though subject names are compared in this policy, they are never directly compared to endpoint names, and an endpoint can not expect to "own" any particular endpoint name outside of an active registration - even if a certificate says so.  It is an accepted shortcoming of this approach that the endpoint has no indication of whether the RD remembers it by its subject name or public key; recognition by subject happens on a best-effort base (given the RD may not recognize any authority).  Clients MUST be prepared to pick a different endpoint name when rejected by the RD initially or after a change in their credentials; picking an endpoint name as per arbitrary-ep is an easy option for that. For this policy to be usable without configuration, clients should not set a sector name in their registrations.  An RD can set a default sector name for registrations accepted under this policy, which is useful especially in a segmented setup where different policies apply to different sectors. </ins> 8. The security considerations as described in Section 5 of RFC8288 and Remove speculation about how in detail ACE scopes are obtained. <ins> Security policies: The First-Come-First-Remembered policy is added as an example and a potential default behavior. </ins> changes from -24 to -25 Large rework of section 7 (Security policies)


server as described in finding_an_rd. The registrant-ep sends (and regularly refreshes with) a POST <del> request to the "/.well-known/core" URI of the directory server of </del>  choice.  The body of the POST request is empty, and triggers the resource directory server to perform GET requests at the requesting registrant-ep's /.well-known/core to obtain the link- POST <del> /.well-known/core{?ep,d,lt,extra-attrs*} </del>  URI Template Variables are as they are for registration in registration.  The base attribute is not accepted to keep the registration interface simple; that rules out registration over CoAP- <del> over-TCP or HTTP that would need to specify one. </del>  The following response is expected on this interface: 9.6. <del> IANA is asked to extend the reference for the "core" URI suffix in the "Well-Known URIs" registry to reference this document next to RFC6690, as this defines the resource's behavior for POST requests. </del>  9.7. Home and building automation use case: Tie in with RD  changes from -24 to -25 Large rework of section 7 (Security policies)

No deployed implementations of simple registration are known that can't switch over easily. As per URL

server as described in finding_an_rd. The registrant-ep sends (and regularly refreshes with) a POST  <ins> request to the "/.well-known/rd" URI of the directory server of </ins> choice.  The body of the POST request is empty, and triggers the resource directory server to perform GET requests at the requesting registrant-ep's /.well-known/core to obtain the link- POST  <ins> /.well-known/rd{?ep,d,lt,extra-attrs*} </ins> URI Template Variables are as they are for registration in registration.  The base attribute is not accepted to keep the registration interface simple; that rules out registration over CoAP-  <ins> over-TCP or HTTP that would need to specify one.  For some time during this document's development, the URI template "/.well-known/ core{?ep,...}" has been in use instead. </ins> The following response is expected on this interface: 9.6.  <ins> IANA is asked to permanently register the URI suffix "rd" in the "Well-Known URIs" registry.  The change controller is the IETF, this document is the reference. </ins> 9.7. Home and building automation use case: Tie in with RD <ins> Simple registration: Rather than coopting POSTs to /.well-known/ core, a new resource /.well-known/rd is registered.  A historical note in the text documents the change. </ins> changes from -24 to -25 Large rework of section 7 (Security policies)


3.1. <del> The Resource Directory is primarily a tool that enables discovery operations that are already present for CoRE devices to happen more efficiently, or across boundaries that would be limiting those </del>  operations. It provides a cache (in the high-level sense, not as defined in RFC7252/RFC2616) of data that could otherwise only be obtained by <del> directly querying the link-format resources on the target device, or by accessing those resources with a multicast request. </del>  From that, it follows that no information should be stored in the <del> resource directory that can not be discovered from querying the described device's link-format resources directly. </del>  It also follows that data in the resource directory can only be <del> provided by the device whose descriptions are cached.  (Commissioning tools are an exception here because they are thought to act on behalf agents too constrained to present that information themselves).  No other client can modify data in the resource directory or even expect those changes to propagate back to its source. </del>  3.2.

Contributes-To: URL
Hi Chris, thanks for this addition. a few textual changes. why link-format resources and not just /.well-known/core? Peter Proposed text
I said "link-format" because self-description data may be hosted in other ct="40" resources linked at .well-known/core -- but that's a detail I don't think we have to consider here; pull request is updated.
If we agree on some basic principles RD should follow, we can phrase them into a text that both guides other decisions in the RD design and can help implementers understand the basic ideas. As I understand, those can be Statements obtained from the RD should stem from statements that can be found on the origin device (on .well-known/core or other ct=40 resources linked by it). As of -10, this is compatible but not enforced in resource links, and absent in statements about the whole device (where registration query parameters ep, et and d are exposed as resource attributes in the endpoint lookup) I'd treat commissioning tools that store information on behalf of the too-constrained origin node as an exception here. Another possible exception is the RD (or something interacting with it) making more statements true, eg. by registering the nodes's address in the DNS and thus making a resolvable (and possibly more stable) name available for use in con. An RD registration can only be updated using the registration resource (which typically only the origin device knows). If some entity (eg. a DNS-SD bridge) wants to update a resource's description (eg. change an instance name or rename an endpoint), they have to find (possibly through the RD) if and where the origin server allows such modification, and put the changes there. Are those agreeable principles, and what else belongs in that category?
During the last calls, it has emerged that RD is seen as an optimization of multicast discovery on .well-known/core; this can probably be merged with the first item above.
I don't see the CT as an exception; I reformulated that aspect.

3.1.  <ins> The Resource Directory is primarily a tool to make discovery operations more efficient than querying /.well-known/core on all connected device, or across boundaries that would be limiting those </ins> operations. It provides a cache (in the high-level sense, not as defined in RFC7252/RFC2616) of data that could otherwise only be obtained by  <ins> directly querying the /.well-known/core resource on the target device, or by accessing those resources with a multicast request. </ins> From that, it follows that no information should be stored in the  <ins> resource directory that cannot be discovered from querying the described device's /.well-known/core resource directly. </ins> It also follows that data in the resource directory can only be  <ins> provided by the device whose descriptions are cached or a dedicated Commissioning Tool (CT).  These CTs are thought to act on behalf agents too constrained, or generally unable, to present that information themselves.  No other client can modify data in the resource directory or even expect those changes to propagate back to its source. </ins> 3.2.


10. Two examples are presented: a Lighting Installation example in lt-ex <del> and a LWM2M example in lwm2m-ex. </del>  10.1. From the returned base parameter value, the luminary learns the multicast address of the multicast group. <del> Alternatively, the CT can communicate the multicast address directly to the luminaries by using the "coap-group" resource specified in RFC7390. Dependent on the situation, only the address, "a", or the name, "n", is specified in the coap-group resource. </del> The presence sensor can learn the presence of groups that support resources with rt=tag:example.com,2020:light in its own sector by sending the same request, as used by the luminary.  The presence 10.2. <del> This example shows how the OMA LWM2M specification makes use of RDs. OMA LWM2M is a profile for device services based on CoAP(OMA Name Authority).  LWM2M defines a simple object model and a number of abstract interfaces and operations for device management and device service enablement. An LWM2M server is an instance of an LWM2M middleware service layer, containing an RD along with other LWM2M interfaces defined by the LWM2M specification. The registration interface of this specification is used to provide the LWM2M Registration interface. </del>  <del> LWM2M does not provide for registration sectors and does not currently use the rd-lookup interface. </del>  <del> The LWM2M specification describes a set of interfaces and a resource model used between a LWM2M device and an LWM2M server.  Other interfaces, proxies, and applications are currently out of scope for LWM2M. </del>  <del> The location of the LWM2M Server and RD URI path is provided by the LWM2M Bootstrap process, so no dynamic discovery of the RD is used. LWM2M Servers and endpoints are not required to implement the /.well- </del>  known/core resource. <del> 10.2.1. The OMA LWM2M object model is based on a simple 2 level class hierarchy consisting of Objects and Resources. An LWM2M Resource is a REST endpoint, allowed to be a single value or an array of values of the same data type. An LWM2M Object is a resource template and container type that encapsulates a set of related resources.  An LWM2M Object represents a specific type of information source; for example, there is a LWM2M Device Management object that represents a network connection, containing resources that represent individual properties like radio signal strength. Since there may potentially be more than one of a given type object, for example more than one network connection, LWM2M defines instances of objects that contain the resources that represent a specific physical thing. The URI template for LWM2M consists of a base URI followed by Object, Instance, and Resource IDs: {/base-uri}{/object-id}{/object-instance}{/resource-id}{/resource- instance} The five variables given here are strings.  base-uri can also have the special value "undefined" (sometimes called "null" in RFC 6570). Each of the variables object-instance, resource-id, and resource- instance can be the special value "undefined" only if the values behind it in this sequence also are "undefined".  As a special case, object-instance can be "empty" (which is different from "undefined") if resource-id is not "undefined". base-uri := Base URI for LWM2M resources or "undefined" for default (empty) base URI object-id := OMNA (OMA Name Authority) registered object ID (0-65535) object-instance := Object instance identifier (0-65535) or "undefined"/"empty" (see above)) to refer to all instances of an object ID resource-id := OMNA (OMA Name Authority) registered resource ID (0-65535) or "undefined" to refer to all resources within an instance resource-instance := Resource instance identifier or "undefined" to refer to single instance of a resource LWM2M IDs are 16 bit unsigned integers represented in decimal (no leading zeroes except for the value 0) by URI format strings.  For example, a LWM2M URI might be: The base URI is empty, the Object ID is 1, the instance ID is 0, the resource ID is 1, and the resource instance is "undefined".  This example URI points to internal resource 1, which represents the registration lifetime configured, in instance 0 of a type 1 object (LWM2M Server Object). 10.2.2. LWM2M defines a registration interface based on the REST API, described in registration.  The RD registration URI path of the LWM2M RD is specified to be "/rd". LWM2M endpoints register object IDs, for example </1>, to indicate that a particular object type is supported, and register object instances, for example </1/0>, to indicate that a particular instance of that object type exists. Resources within the LWM2M object instance are not registered with the RD, but may be discovered by reading the resource links from the object instance using GET with a CoAP Content-Format of application/ link-format.  Resources may also be read as a structured object by performing a GET to the object instance with a Content-Format of senml+json. When an LWM2M object or instance is registered, this indicates to the LWM2M server that the object and its resources are available for management and service enablement (REST API) operations. LWM2M endpoints may use the following RD registration parameters as defined in tab-registry : Endpoint Name, Lifetime, and LWM2M Version are mandatory parameters for the register operation, all other registration parameters are optional. Additional optional LWM2M registration parameters are defined: The following RD registration parameters are not currently specified for use in LWM2M: The endpoint registration must include a payload containing links to all supported objects and existing object instances, optionally including the appropriate link-format relations. Here is an example LWM2M registration payload: This link format payload indicates that object ID 1 (LWM2M Server Object) is supported, with a single instance 0 existing, object ID 3 (LWM2M Device object) is supported, with a single instance 0 existing, and object 5 (LWM2M Firmware Object) is supported, with no existing instances. 10.2.3. The LwM2M update is really very similar to the registration update as described in update, with the only difference that there are more parameters defined and available.  All the parameters listed in that section are also available with the initial registration but are all optional: A Registration update is also specified to be used to update the LWM2M server whenever the endpoint's UDP port or IP address are changed. 10.2.4. LWM2M allows for de-registration using the delete method on the returned location from the initial registration operation.  LWM2M de- registration proceeds as described in removal. </del> 11. Oscar Novo, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders RDAO: Clarify that it is an option for RAs and not other ND messages. <del> Examples: Use example URIs rather than unclear reg names (unless it's RFC6690 examples, which were kept for continuity) </del>  changes from -24 to -25

This is a series of commits removing cruft in the examples as discussed in URL Diverging from the discussion outcome, more than a single line was kept of 10.2, as the historical note left in , by analogy, means that we should mention that application's choice of a fixed path as well. Some commits may be added still as I'm going through the list.
I'm merging this in to ensure it interacts well with the example updates (where the resource types were replaced with actual example values); any follow-ups will go to a separate PR.

10. Two examples are presented: a Lighting Installation example in lt-ex  <ins> and a LwM2M example in lwm2m-ex. </ins> 10.1. From the returned base parameter value, the luminary learns the multicast address of the multicast group.  The presence sensor can learn the presence of groups that support resources with rt=tag:example.com,2020:light in its own sector by sending the same request, as used by the luminary.  The presence 10.2.  <ins> OMA LwM2M is a profile for device services based on CoAP, providing interfaces and operations for device management and device service enablement. </ins>  <ins> An LwM2M server is an instance of an LwM2M middleware service layer, containing an RD (LwM2M page 36f). </ins>  <ins> That RD only implements the registration interface, and no lookup is implemented.  Instead, the LwM2M server provides access to the registered resources, in a similar way to a reverse proxy. </ins>  <ins> The location of the LwM2M Server and RD URI path is provided by the LwM2M Bootstrap process, so no dynamic discovery of the RD is used. LwM2M Servers and endpoints are not required to implement the /.well- </ins> known/core resource.  11. Oscar Novo, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders RDAO: Clarify that it is an option for RAs and not other ND messages.  <ins> Examples: Use example URIs rather than unclear reg names (unless it's RFC6690 examples, which were kept for continuity) The LwM2M example was reduced from an outdated explanation of the complete LwM2M model to a summary of how RD is used in there, with a reference to the current specification. </ins> changes from -24 to -25


4.1.1. <del> The Resource Directory Address Option (RDAO) using IPv6 Neighbor Discovery (ND) carries information about the address of the RD.  This information is needed when endpoints cannot discover the RD with a link-local or realm-local scope multicast address, for instance because the endpoint and the RD are separated by a Border Router (6LBR).  In many circumstances the availability of DHCP cannot be guaranteed either during commissioning of the network.  The presence and the use of the RD is essential during commissioning. </del>  It is possible to send multiple RDAO options in one message, indicating as many RD addresses. redundancies between the problem introduction and the description of how an RD could become part of the problem.  changes from -24 to -25 Large rework of section 7 (Security policies)

This puts the RDAO in the same messages as RDNSS option (see RFC8106) See-Also: URL
All addressed, sorry for the bugs. Thanks for the updates in the -26; they help a lot. I'm particularly happy to see the (default/example) "first-come-first-remembered" policy in § 7.5, which does a good job of documenting its properties (including potential deficiencies) and can be usable for many environments.  (I do have some suggestions for improvements to the specific wording in the section-by-section comments, but on the whole I like it.) It does lead in to a more general comment, though (which is not exactly new to the changes in the -26 though it is reflected in several of them): some aspects of the concept of "authorization" to appear in a directory, and the verification of authorization for the entire flow from client locating the RD server to final request at the discovered resource, are somewhat subtle.  (The new text discusses, e.g., "repeat the URI discovery step at the /.well-known/core resource of the indicated host to obtain the resource type information from an authorized source" and "a straightforward way to verify [discovered information] is to request it again from an authorized server, typically the one that hosts the target resource".)  The aspects I'm concerned about are not matters of a resource server being authorized to publish to a directory or a client deeming that a server is authorized to act as an RD (though both of those are also important), but seems to rather just be relating to the RD faithfully disseminating the information the RD retrieved from /.well-known/core discovery on the given server(s) (or otherwise learned via some other mechanism). In this sense the RD is just acting as a cache or efficiency aid, but the authoritative source of the information remains (in general) the server hosting the resource.  To be clear, I think the procedures that this document specifies are good and correct procedures for a client to perform, I'm just not sure whether "authorized" is the right term in these cases; "authoritative" might be more appropriate, in that the operation in question is to verify the information retrieved from the RD (which acts in some sense as an intermediary) at the more authoritative source. (On a tangent from that note, it seems that there is not necessarily any indication to a client that a server claiming to provide a given resource (whether discovered via RD or /.well-known/core) is actually authorized to provide such a resource and be trusted by the client.  But that's not really a property of RD, and rather the underlying CoRE mechanism and any provisioned trust database, so my thoughts about it seem out of scope for this document.) (It's not entirely clear to me what the reader is expected to do with the information about the previous formulation.) (It seems that something also needs to cause the RD to check the authorization of lookup clients to receive the information in question, which might be worth reiterating in this section.) I'm pretty sure the intent here is that only the subject names that are certified by the recognized authority(ies) are stored, in which case I'd suggest to s/all those/all such/. (I can understand why the "store the whole list" logic is used, though there may be some subtleties about name constraints on the (X.509) CAs used, which is why we typically don't recomment treating the entire list of names in the certificate as validated from a single operation, instead preferring "is this certificate authenticated for this specific name?" when the specific target name is available.) Should we talk about whether the lifetime of registration entries is related to the various lifetimes of these credentials/identifiers?  DTLS without resumption is perhaps an interesting case, in that keeping the DTLS association "live" just to be able to update the registration information seems impractical, so perhaps some fixed cap would be applied on the lifetime in that case.  If resumption is used, the resumption information (ticket or session state) has some finite lifetime that could be used to bound the lifetime of the registration. IIRC an OSCORE security context can also have an expiration time; certificates and JWT/CWT have expiration time as well (though the procedures in the first bullet point would effectively allow a "renewal" operation), but the validity period (if any) of a raw public key would have to be provisioned along with that key (or just have RPK be handled akin to DTLS without resumption, I guess). (Similar to my earlier parenthetical comment, the requirement for exact match of all subject name information is unusual.  In effect this is a way of pinning the set of names that the CA has chosen to include in a single certificate, which is arguably a stronger requirement than needed but should not lead to any unauthorized access.)

4.1.1.  <ins> The Resource Directory Address Option (RDAO) carries information about the address of the RD in RAs (Router Advertisements) of IPv6 Neighbor Discovery (ND), similar to how RDNSS options RFC8106 are sent.  This information is needed when endpoints cannot discover the RD with a link-local or realm-local scope multicast address, for instance because the endpoint and the RD are separated by a Border Router (6LBR).  In many circumstances the availability of DHCP cannot be guaranteed either during commissioning of the network.  The presence and the use of the RD is essential during commissioning. </ins> It is possible to send multiple RDAO options in one message, indicating as many RD addresses. redundancies between the problem introduction and the description of how an RD could become part of the problem. <ins> RDAO: Clarify that it is an option for RAs and not other ND messages. </ins> changes from -24 to -25 Large rework of section 7 (Security policies)