Any, all or none of the below can apply to an application.  Which are relevant depends on its protection objectives.  7.1. Whenever an RD needs to provide trustworthy results to clients doing firewalling than lookups to the RD, the RD may need to limit which lookup clients may access the information. <del> 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 this purpose, and cannot rely on the RD to provide AS address and 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 registration). </del>  7.4. Abstract, introduction: removed "or disperse networks"  changes from -24 to -25 Large rework of section 7 (Security policies)

…om authorized RDs This makes the paragraph that described that for a particular case largely redundant. The lines about that special case that described special considerations for ACE anticipate a mechanism that is not finished yet, and were removed.

Any, all or none of the below can apply to an application.  Which are relevant depends on its protection objectives. <ins> Security policies are set by configuration of the RD, or by choice of the implementation.  Lookup clients (and, where relevant, endpoints) can only trust an RD to uphold them if it is authenticated, and authorized to serve as an RD according to the application's requirements. </ins> 7.1. Whenever an RD needs to provide trustworthy results to clients doing firewalling than lookups to the RD, the RD may need to limit which lookup clients may access the information.  <ins> In this case, the endpoint (and not the lookup clients) needs to be careful to check the RD's authorization. </ins> 7.4. Abstract, introduction: removed "or disperse networks" <ins> Security policies: Clarify that with all security policies, clients must verify the authorization of the RD. Remove speculation about how in detail ACE scopes are obtained. </ins> changes from -24 to -25 Large rework of section 7 (Security policies)


victim's .well-known/core content in the RD.  Mitigation for this is recommended in simple.  8.3. Access control SHOULD be performed separately for the RD registration Acknowledge that most discovery operations are not secured; mention consequences and mitigation.  RDAO: Clarify that it is an option for RAs and not other ND messages.

This is a result of the discussion following Roman's "> But why expose them at all if they're not going to be accessible?" comment.

victim's .well-known/core content in the RD.  Mitigation for this is recommended in simple. <ins> The Registration Resource path is visible to any client that is allowed endpoint lookup, and can be extracted by resource lookup clients as well.  The same goes for registration attributes that are shown as target attributes or lookup attributes.  The RD needs to consider this in the choice of Registration Resource paths, and administrators or endpoint in their choice of attributes. </ins> 8.3. Access control SHOULD be performed separately for the RD registration Acknowledge that most discovery operations are not secured; mention consequences and mitigation. <ins> Add note about information in Registration Resource path. </ins> RDAO: Clarify that it is an option for RAs and not other ND messages.


At the moment of installation, the network under installation is not necessarily connected to the DNS infrastructure.  Therefore, SLAAC <del> IPv6 addresses are assigned to CT, RD, luminaries and sensor shown in interface-S below: </del>  In rd-en the use of RD during installation is presented. used in this section. For discovery, the resource types (rt) of the devices are important. <del> The lamps in the luminaries have rt: light, and the presence sensor has rt: p-sensor.  The endpoints have names which are relevant to the light installation manager.  In this case luminary1, luminary2, and the presence sensor are located in room 2-4-015, where luminary1 is located at the window and luminary2 and the presence sensor are located at the door.  The endpoint names reflect this physical location.  The middle, left and right lamps are accessed via path /light/middle, /light/left, and /light/right respectively.  The identifiers relevant to the RD are shown in endpoint below: It is assumed that the CT knows the RD's address, and has performed URI discovery on it that returned a response like the one in the discovery example. </del>  The CT inserts the endpoints of the luminaries and the sensor in the RD using the registration base URI parameter (base) to specify the the complete LwM2M model to a summary of how RD is used in there, with a reference to the current specification.  impl-info: Add note about the type being WIP Error handling: Place a SHOULD around the likely cases, and make

These fix some missing parts from , and address Erik's SLAAC comments as well as their fall-out on the CTs "knowing" the RD.

At the moment of installation, the network under installation is not necessarily connected to the DNS infrastructure.  Therefore, SLAAC  <ins> IPv6 addresses are assigned to CT, RD, luminaries and the sensor. The addresses shown in interface-S below stand in for these in the following examples. </ins> In rd-en the use of RD during installation is presented. used in this section. For discovery, the resource types (rt) of the devices are important.  <ins> The lamps in the luminaries have rt=tag:example.com,2020:light, and the presence sensor has rt=tag:example.com,2020:p-sensor.  The endpoints have names which are relevant to the light installation manager.  In this case luminary1, luminary2, and the presence sensor are located in room 2-4-015, where luminary1 is located at the window and luminary2 and the presence sensor are located at the door.  The endpoint names reflect this physical location.  The middle, left and right lamps are accessed via path /light/middle, /light/left, and /light/right respectively.  The identifiers relevant to the RD are shown in endpoint below: It is assumed that the CT has performed RD discovery and has received a response like the one in the discovery example. </ins> The CT inserts the endpoints of the luminaries and the sensor in the RD using the registration base URI parameter (base) to specify the the complete LwM2M model to a summary of how RD is used in there, with a reference to the current specification. <ins> Luminary example: Explain example addresses </ins> impl-info: Add note about the type being WIP Error handling: Place a SHOULD around the likely cases, and make


Abstract In many IoT applications, direct discovery of resources is not <del> practical due to sleeping nodes, disperse networks, or networks where multicast traffic is inefficient.  These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources.  The input to an RD is composed of links and the output is composed of links constructed from the information stored in the RD.  This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, lookup and remove information on resources. Furthermore, new target attributes useful in conjunction with an RD are defined. </del>  1. RFC6690 only describes how to discover resources from the web server that hosts them by querying "/.well-known/core".  In many constrained scenarios, direct discovery of resources is not practical due to <del> sleeping nodes, disperse networks, or networks where multicast traffic is inefficient.  These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. </del>  This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, lookup and RD replication: Point out that security policies may limit that.  changes from -24 to -25 Large rework of section 7 (Security policies)

We were asked about the term in Erik's comments, and nobody could explain its relevance to the RD; removing it. See-Also: URL

Abstract In many IoT applications, direct discovery of resources is not  <ins> practical due to sleeping nodes, or networks where multicast traffic is inefficient.  These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources.  The input to an RD is composed of links and the output is composed of links constructed from the information stored in the RD.  This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, lookup and remove information on resources.  Furthermore, new target attributes useful in conjunction with an RD are defined. </ins> 1. RFC6690 only describes how to discover resources from the web server that hosts them by querying "/.well-known/core".  In many constrained scenarios, direct discovery of resources is not practical due to  <ins> sleeping nodes, or networks where multicast traffic is inefficient. These problems can be solved by employing an entity called a Resource Directory (RD), which contains information about resources held on other servers, allowing lookups to be performed for those resources. </ins> This document specifies the web interfaces that an RD supports for web servers to discover the RD and to register, maintain, lookup and RD replication: Point out that security policies may limit that. <ins> Abstract, introduction: removed "or disperse networks" </ins> changes from -24 to -25 Large rework of section 7 (Security policies)


An update MAY update the lifetime or context registration parameters "lt", "con" as in registration ) if the previous settings are to be <del> retained.  Parameters that are not being changed changed SHOULD NOT be included in an update.  Adding parameters that have not changed </del>  increases the size of the message but does not have any other implications.  Parameters MUST be included as query parameters in an update operation as in registration.

This PR fixes a simple typo. Side question: I found a number of lines in the markdown document that have spaces before the newline character. Would a PR removing those also be of interest?
Thanks! Re your side question: So I'm not the only person annoyed by trailing spaces :-) I went ahead and fixed this (one command in Emacs :-), including re-aligning a markdown table.

An update MAY update the lifetime or context registration parameters "lt", "con" as in registration ) if the previous settings are to be  <ins> retained.  Parameters that are not being changed SHOULD NOT be included in an update.  Adding parameters that have not changed </ins> increases the size of the message but does not have any other implications.  Parameters MUST be included as query parameters in an update operation as in registration.


Luminary example: Explain example addresses  impl-info: Add note about the type being WIP Error handling: Place a SHOULD around the likely cases, and make

The generated address failed to follow the guidance of RFC 3307 and set the first bit of the Group ID.
Since the example prefix is 2001:db8::/32 , I would assume the plen field is also set to 32, so we would get: ff35:20:2001:db8::8000:x Or is there a reason here to use plen=0x30 (48) bits ?
Throughout the examples, we use the third word to distinguish between separate logically distinct examples (2001:db8:1:: .. 2001:db8:4::), so it seemed logical to take a /48 for this example as well. (Although in keeping with the other appendix that uses 2001:db8:f0::, something like 2001:db8:e0::/48 and thus ff35:30:2001:db8:e0::1 would enhance consistency).
Ok, thanks - I see - so in example nr 4 the prefix 2001:db8:4/48 is used, then the mcast address would become ff35:30:2001:db8:4::8000:x right? If the ':4' is omitted it looks like a prefix 2001:db8/32 is being used.
The last commit on this series (c4d24f38342a6a6e0074a26dfd88db302b62d47c) now has something in the original addresses 3rd word (2001:db8:f1::/48) to make the choice of 30 in the prefix length more understandable, and for consistency.

Luminary example: Explain example addresses <ins> Multicast addresses in the examples were changed from ff35:30:2001:db8::x to ff35:30:2001:db8:f1::8000:x; the 8000 is to follow RFC 3307, and the f1 is for consistency with all the other example addresses where 2001:db8::/32 is subnetted to 2001:db8:x::/48 by groups of internally consistent examples. </ins> impl-info: Add note about the type being WIP Error handling: Place a SHOULD around the likely cases, and make


Section 3.2.1).  The endpoint name MUST NOT contain any character in the inclusive ranges 0-31 or 127-159.  The maximum length of this parameter is 63 UTF-8 encoded bytes.  If the RD <del> is configured to recognize the endpoint (e.g. based on its security context), the RD assigns an endpoint name based on a set of configuration parameter values. </del>  Sector (optional).  The sector to which this endpoint belongs. When this parameter is not present, the RD MAY associate the <del> endpoint with a configured default sector or leave it empty. The sector is encoded like the ep parameter, and is limited to 63 UTF-8 encoded bytes as well.  The endpoint name and sector name are not set when one or both are set in an accompanying authorization token. </del>  Lifetime (optional).  Lifetime of the registration in seconds. Range of 1-4294967295.  If no lifetime is included in the Error handling: Place a SHOULD around the likely cases, and make the previous "MUST to the best of their capabilities" a "must".  changes from -24 to -25 Large rework of section 7 (Security policies)

This also answers the repeated questions that were asked about conflicts between recognized and given ep names, and brings the wording in line with the more consistent application of the security glossary.

Section 3.2.1).  The endpoint name MUST NOT contain any character in the inclusive ranges 0-31 or 127-159.  The maximum length of this parameter is 63 UTF-8 encoded bytes.  If the RD  <ins> is configured to recognize the endpoint to be authorized to use exactly one endpoint name, the RD assigns that name.  In that case, giving the endpoint name becomes optional for the client; if the client gives any other endpoint name, it is not authorized to perform the registration. </ins> Sector (optional).  The sector to which this endpoint belongs. When this parameter is not present, the RD MAY associate the  <ins> endpoint with a configured default sector (possibly based on the endpoint's authorization) or leave it empty.  The sector is encoded like the ep parameter, and is limited to 63 UTF-8 encoded bytes as well. </ins> Lifetime (optional).  Lifetime of the registration in seconds. Range of 1-4294967295.  If no lifetime is included in the Error handling: Place a SHOULD around the likely cases, and make the previous "MUST to the best of their capabilities" a "must". <ins> Registration: Wording around "mostly mandatory" has been improved, conflicts clarified and sector default selection adjusted. </ins> changes from -24 to -25 Large rework of section 7 (Security policies)


This and the following sections define the required set of REST interfaces between an RD, endpoints and lookup clients.  Although the examples throughout these sections assume the use of CoAP RFC7252, <del> these REST interfaces can also be realized using HTTP RFC7230.  Only multicast discovery operations are not possible on HTTP, and Simple Registration cannot be executed as the base attribute (which is mandatory for HTTP) cannot 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 this specification MUST support the discovery, registration, update, lookup, and removal interfaces. </del>  All operations on the contents of the RD MUST be atomic and idempotent.

The previous sentence was barely readable. Details were removed as they are obvious (multicast) or already mentioned in the respective section (simple registration).

This and the following sections define the required set of REST interfaces between an RD, endpoints and lookup clients.  Although the examples throughout these sections assume the use of CoAP RFC7252,  <ins> these REST interfaces can also be realized using HTTP RFC7230.  The multicast discovery and simple registration operations are exceptions to that, as they rely on mechanisms unavailable in HTTP.  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 this specification MUST support the discovery, registration, update, lookup, and removal interfaces. </ins> All operations on the contents of the RD MUST be atomic and idempotent.


REST clients (registrant-EPs and CTs during registration and maintenance, lookup clients, RD servers during simple registrations) <del> MUST be prepared to receive any unsuccessful code and act upon it </del>  according to its definition, options and/or payload to the best of their capabilities, falling back to failing the operation if recovery <del> is not possible.  In particular, they should retry the request upon </del>  5.03 (Service Unavailable; 503 in HTTP) according to the Max-Age <del> (Retry-After in HTTP) option, and fall back to link-format when receiving 4.15 (Unsupported Content-Format; 415 in HTTP). </del>  An RD MAY make the information submitted to it available to further directories, if it can ensure that a loop does not form.  The impl-info: Add note about the type being WIP  changes from -24 to -25 Large rework of section 7 (Security policies)

The "MUST" was non-actionable, while the "should" would be; switching normativity. See-Also: URL 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.)

REST clients (registrant-EPs and CTs during registration and maintenance, lookup clients, RD servers during simple registrations)  <ins> must be prepared to receive any unsuccessful code and act upon it </ins> according to its definition, options and/or payload to the best of their capabilities, falling back to failing the operation if recovery  <ins> is not possible.  In particular, they SHOULD retry the request upon </ins> 5.03 (Service Unavailable; 503 in HTTP) according to the Max-Age  <ins> (Retry-After in HTTP) option, and SHOULD fall back to link-format when receiving 4.15 (Unsupported Content-Format; 415 in HTTP). </ins> An RD MAY make the information submitted to it available to further directories, if it can ensure that a loop does not form.  The impl-info: Add note about the type being WIP <ins> Error handling: Place a SHOULD around the likely cases, and make the previous "MUST to the best of their capabilities" a "must". </ins> changes from -24 to -25 Large rework of section 7 (Security policies)


In a 6LoWPAN, just assume the Border Router (6LBR) can act as an RD (using the ABRO option to find that RFC6775).  Confirmation can <del> be obtained by sending a Unicast to "coap://[6LBR]/.well-known/ </del>  core?rt=core.rd*". In a network that supports multicast well, discovering the RD known interface of the CoRE Link Format RFC6690 after having discovered a host as described in finding_an_rd. <del> Discovery of the RD registration URI path is performed by sending either a multicast or unicast GET request to "/.well-known/core" and including a Resource Type (rt) parameter RFC6690 with the value "core.rd" in the query string.  Likewise, a Resource Type parameter value of "core.rd-lookup*" is used to discover the URIs for RD Lookup operations, core.rd* is used to discover all URI paths for RD operations.  Upon success, the response will contain a payload with a link format entry for each RD function discovered, indicating the URI of the RD function returned and the corresponding Resource Type. When performing multicast discovery, the multicast IP address used will depend on the scope required and the multicast capabilities of the network (see mc-registration). </del>  An RD MAY provide hints about the content-formats it supports in the links it exposes or registers, using the "ct" target attribute, as The sequence of fetching the registration content before sending a successful response was chosen to make responses reliable, and the <del> caching item was chosen to still allow very constrained registrants. Registrants MUST be able to serve a GET request to "/.well-known/ core" after having requested registration.  Constrained devices MAY regard the initial request as temporarily failed when they need RAM occupied by their own request to serve the RD's GET, and retry later when the RD already has a cached representation of their discovery resources.  Then, the RD can reply immediately and the registrant can receive the response. </del>  The simple registration request interface is specified as follows:

Just one so far, but AFAIR there'll be a few more to push on this. See-Also: URL 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.)

In a 6LoWPAN, just assume the Border Router (6LBR) can act as an RD (using the ABRO option to find that RFC6775).  Confirmation can  <ins> be obtained by sending a unicast to "coap://[6LBR]/.well-known/ </ins> core?rt=core.rd*". In a network that supports multicast well, discovering the RD known interface of the CoRE Link Format RFC6690 after having discovered a host as described in finding_an_rd.  <ins> Discovery of the RD registration URI is performed by sending either a multicast or unicast GET request to "/.well-known/core" and including a Resource Type (rt) parameter RFC6690 with the value "core.rd" in the query string.  Likewise, a Resource Type parameter value of "core.rd-lookup*" is used to discover the URIs for RD Lookup operations, core.rd* is used to discover all URIs for RD operations. Upon success, the response will contain a payload with a link format entry for each RD function discovered, indicating the URI of the RD function returned and the corresponding Resource Type.  When performing multicast discovery, the multicast IP address used will depend on the scope required and the multicast capabilities of the network (see mc-registration). </ins> An RD MAY provide hints about the content-formats it supports in the links it exposes or registers, using the "ct" target attribute, as The sequence of fetching the registration content before sending a successful response was chosen to make responses reliable, and the  <ins> point about caching was chosen to still allow very constrained registrants.  Registrants MUST be able to serve a GET request to "/.well-known/core" after having requested registration.  Constrained devices MAY regard the initial request as temporarily failed when they need RAM occupied by their own request to serve the RD's GET, and retry later when the RD already has a cached representation of their discovery resources.  Then, the RD can reply immediately and the registrant can receive the response. </ins> The simple registration request interface is specified as follows:


registration, update, lookup, and removal interfaces defined in this section.  5.1. Resource Directory implementations using this specification MUST including a Resource Type (rt) parameter RFC6690 with the value "core.rd" in the query string.  Likewise, a Resource Type parameter value of "core.rd-lookup*" is used to discover the URIs for RD Lookup <del> operations, and "core.gp" is used to discover the URI path for RD Group operations.  Upon success, the response will contain a payload with a link format entry for each RD function discovered, indicating the URI path of the RD function returned and the corresponding Resource Type.  When performing multicast discovery, the multicast IP address used will depend on the scope required and the multicast capabilities of the network. </del>  A Resource Directory MAY provide hints about the content-formats it supports in the links it exposes or registers, using the "ct" link registration may be created at any time to supersede an existing registration, replacing the registration parameters and links.  The registration request interface is specified as follows: EP -> RD 5.3.2. <del> An endpoint that wants to make itself discoverable occasionally sends a POST request to the "/.well-known/core" URI of any candidate directory server that it finds.  The body of the POST request is empty, which triggers the resource directory server to perform GET requests at the requesting server's default discovery URI to obtain the link-format payload to register. </del>  The endpoint MUST include the endpoint name and MAY include the registration parameters d, lt, and et, in the POST request as per registration.  The following example shows an endpoint using simple publishing, by simply sending an empty POST to a resource directory. registration with an RD.  To use the interface, the endpoint sends a POST request to the registration resource returned in the Location header option in the response returned from the intial registration <del> operation. </del>  An update MAY update the lifetime or context registration parameters "lt", "con" as in registration ) if the previous settings are to be shut-down).  This is accomplished using a removal interface on the RD by performing a DELETE on the endpoint resource.  The removal request interface is specified as follows: EP -> RD 11. Oscar Novo, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders <del> Brandt, Matthieu Vial, Mohit Sethi, Sampo Ukkola, Linyi Tian, Chistian Amsuss, and Jan Newmarch have provided helpful comments, </del>  discussions and ideas to improve and shape this document.  Zach would also like to thank his colleagues from the EU FP7 SENSEI project, where many of the resource directory concepts were originally 12.  changes from -09 to -10 removed "ins" and "exp" link-format extensions.

atomicity idempotency, Jim multiple query parameter, Fairhair deleted eps from group, Jim simple registration, hauke

registration, update, lookup, and removal interfaces defined in this section. <ins> All operations on the contents of the Resource Directory MUST be atomic and idempotent. A Resource Directory MUST accept query filtering with multiple query parameters in the URI. </ins> 5.1. Resource Directory implementations using this specification MUST including a Resource Type (rt) parameter RFC6690 with the value "core.rd" in the query string.  Likewise, a Resource Type parameter value of "core.rd-lookup*" is used to discover the URIs for RD Lookup  <ins> operations, and "core.rd-group" is used to discover the URI path for RD Group operations.  Upon success, the response will contain a payload with a link format entry for each RD function discovered, indicating the URI path of the RD function returned and the corresponding Resource Type.  When performing multicast discovery, the multicast IP address used will depend on the scope required and the multicast capabilities of the network. </ins> A Resource Directory MAY provide hints about the content-formats it supports in the links it exposes or registers, using the "ct" link registration may be created at any time to supersede an existing registration, replacing the registration parameters and links. <ins> An empty payload is considered a malformed request. </ins> The registration request interface is specified as follows: EP -> RD 5.3.2.  <ins> An endpoint that wants to make itself discoverable sends (and regularly refreshes with) a POST request to the "/.well-known/core" URI of any candidate directory server that it finds.  The body of the POST request is empty, which triggers the resource directory server to perform GET requests at the requesting server's default discovery URI to obtain the link-format payload to register. </ins> The endpoint MUST include the endpoint name and MAY include the registration parameters d, lt, and et, in the POST request as per registration. <ins> The endpoints MUST be deleted after the expiration of their lifetime. Additional operations cannot be executed because no registration location is returned. </ins> The following example shows an endpoint using simple publishing, by simply sending an empty POST to a resource directory. registration with an RD.  To use the interface, the endpoint sends a POST request to the registration resource returned in the Location header option in the response returned from the intial registration  <ins> operation.  The POST request (in contrats to PUT) allows replacing selection of a resource. </ins> An update MAY update the lifetime or context registration parameters "lt", "con" as in registration ) if the previous settings are to be shut-down).  This is accomplished using a removal interface on the RD by performing a DELETE on the endpoint resource. <ins> Removed endpoints are implicitly removed from the groups to which they belong. </ins> The removal request interface is specified as follows: EP -> RD 11. Oscar Novo, Srdjan Krco, Szymon Sasin, Kerry Lynn, Esko Dijk, Anders  <ins> Brandt, Matthieu Vial, Jim Schaad, Mohit Sethi, Hauke Petersen, Sampo Ukkola, Linyi Tian, and Jan Newmarch have provided helpful comments, </ins> discussions and ideas to improve and shape this document.  Zach would also like to thank his colleagues from the EU FP7 SENSEI project, where many of the resource directory concepts were originally 12. <ins> changes from -11 to -12 added ER diagram updated discovery text improved text on: atomicity, idempotency, multiple query, ep removal, simple registration </ins> changes from -09 to -10 removed "ins" and "exp" link-format extensions.


When the (ep, d) value pair of the registration-request is equal to an existing registration, the content and parameters of the existing registration are replaced with the content of the <del> registration request. </del>  The posted link-format document can (and typically does) contain relative references both in its link targets and in its anchors, or

See-Also: URL 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.)

When the (ep, d) value pair of the registration-request is equal to an existing registration, the content and parameters of the existing registration are replaced with the content of the  <ins> registration request.  Like the later changes to registration resources, security policies (policies) usually require such requests to come from the same device. </ins> The posted link-format document can (and typically does) contain relative references both in its link targets and in its anchors, or


Endpoint authorization needs to be checked on registration and registration resource operations independently of whether there are configured requirements on the credentials for a given endpoint name <del> (secure-ep) or whether arbitrary names are accepted (arbitrary-ep). </del>  Simple registration could be used to circumvent address-based access control: An attacker would send a simple registration request with

Endpoint authorization needs to be checked on registration and registration resource operations independently of whether there are configured requirements on the credentials for a given endpoint name  <ins> (and sector; secure-ep) or whether arbitrary names are accepted (arbitrary-ep). </ins> Simple registration could be used to circumvent address-based access control: An attacker would send a simple registration request with


3.6. Home and commercial building automation systems can benefit from the <del> use of M2M web services.  The discovery requirements of these </del>  applications are demanding.  Home automation usually relies on run- time discovery to commission the system, whereas in building automation a combination of professional commissioning and run-time Two phases can be discerned for a network servicing the system: (1) installation and (2) operation.  During the operational phase, the <del> network is connected to the Internet with a Border router (6LBR) and the nodes connected to the network can use the Internet services that are provided by the Internet Provider or the network administrator. During the installation phase, the network is completely stand-alone, no 6LBR is connected, and the network only supports the IP </del>  communication between the connected nodes.  The installation phase is usually followed by the operational phase.  As an RD's operations work without hard dependencies on names or addresses, it can be used "coap://[MCD1]/.well-known/core?rt=core.rd*".  RDs within the multicast scope will answer the query. <del> When answering a multicast request directed at a link-local address, </del>  the RD may want to respond from a routable address; this makes it easier for registrants to use one of their own routable addresses for registration.

Use case HA/BA: Expand and reference term "6LBR" Use case HA/BA: Use term 'IoT' that's more common in that area these days

3.6. Home and commercial building automation systems can benefit from the  <ins> use of IoT web services.  The discovery requirements of these </ins> applications are demanding.  Home automation usually relies on run- time discovery to commission the system, whereas in building automation a combination of professional commissioning and run-time Two phases can be discerned for a network servicing the system: (1) installation and (2) operation.  During the operational phase, the  <ins> network is connected to the Internet with a Border Router (e.g. a 6LoWPAN Border Router (6LBR), see RFC6775) and the nodes connected to the network can use the Internet services that are provided by the Internet Provider or the network administrator.  During the installation phase, the network is completely stand-alone, no Border Router is connected, and the network only supports the IP </ins> communication between the connected nodes.  The installation phase is usually followed by the operational phase.  As an RD's operations work without hard dependencies on names or addresses, it can be used "coap://[MCD1]/.well-known/core?rt=core.rd*".  RDs within the multicast scope will answer the query.  <ins> When answering a multicast request directed at a link-local group, </ins> the RD may want to respond from a routable address; this makes it easier for registrants to use one of their own routable addresses for registration.


When answering a multicast request directed at a link-local group, the RD may want to respond from a routable address; this makes it easier for registrants to use one of their own routable addresses for <del> registration. </del>  As some of the RD addresses obtained by the methods listed here are just (more or less educated) guesses, endpoints MUST make use of any The First-Come-First-Remembered policy is added as an example and a potential default behavior. <del> RD discovery: Drop the previously stated assumption that RDAO and any DHCP options would only be used together with SLAAC and DHCP for address configuration, respectivly. </del>  Terminology:

See-Also: URL I've gone though the rules of source address selection and think what I'm doing here is a) legal and b) produces the right results (this works is because 10.4 places fe80 and :: in the same label, and the the limited precedence for fe80 puts them out of the game in the modified rule 8), but I'll add this to the focus points of the 6man mail. Thank you for the work put into this document. As you can noticed, I have cleared my 2 DISCUSS points (kept below for archive) thank you also for replying to my comments over email. BTW, I appreciated the use of ASCII art to represent an entity-relationship diagram ! I hope that this helps to improve the document, -- Section 4.1 -- It will be trivial to fix, in IPv6 address configuration (SLAAC vs. DHCP) is orthogonal to DHCP 'other-information'. E.g., even if address is configured via SLAAC, DHCPv6 other-information can be used to configure the Recursive DNS Server (or possibly the RD). -- Section 4.1.1 -- Another trivial DISCUSS to fix: in which message is this RDAO sent ? I guess unicast Router Advertisement but this MUST be specified. In general, I wonder how much interactions and exchanges of ideas have happened in the long history of this document with the DNSSD (DNS Service Discovery) Working Group that has very similar constraints (sleeping nodes) and same objectives. -- Section 2 -- To be honest: I am not too much an APP person; therefore, I was surprised to see "source address (URI)" used to identify the "anchor="... I do not mind too much the use of "destination address (URI)" as it is really a destination but the anchor does not appear to me as a "source address". Is it common terminology ? If so, then ignore my COMMENT, else I suggest to change to "destination URI" and simply "anchor" ? -- Section 3.3 -- Should the lifetime be specified in seconds at first use in the text? -- Section 3.6 -- Is the use of "M2M" still current? I would suggest to use the word "IoT" esp when 6LBR (assuming it is 6LO Border Router) is cited later. Please expand and add reference for 6LBR. Using 'modern' technologies (cfr LP-WAN WG) could also add justification to section 3.5. -- Section 4.1 -- About "coap://[MCD1]/.well-known/core?rt=core.rd*", what is the value of MCD1 ? The IANA section discuss about it but it may help the reader to give a hint before (or simply use TBDx that is common in I-D). Any reason to use "address" rather than "group" in "When answering a multicast request directed at a link-local address" ? Later "to use one of their own routable addresses for registration." but there can be multiple configured prefixes... Which one should the RD select ? Should this be specified ? As a co-author of RFC 8801, I would have appreciated to read PvD option mentionned to discover the RD. Any reason why PvD Option cannot be used ? -- Section 4.1.1 -- I suggest to swap the reserved and lifetime fields in order to be able to use a lifetime in units of seconds (to be consistent with other NDP options). -- Section 5 -- May be I missed it, but, can an end-point register multiple base URI ? E.g., multiple IPv6 addresses. -- Section 9.2 -- For information, value 38 is already assigned to RFC 8781. -- Section 2 -- The extra new lines when defining "Sector" are slighly confusing. Same applies to "Target" and "Context". This is cosmetic only.

When answering a multicast request directed at a link-local group, the RD may want to respond from a routable address; this makes it easier for registrants to use one of their own routable addresses for  <ins> registration.  When RFC6724 is used for source address selection, this can be achieved by applying the changes of its Section 10.4, picking public addresses in its Section 5 Rule 7, and superseding rule 8 with preferring the source address's precedence. </ins> As some of the RD addresses obtained by the methods listed here are just (more or less educated) guesses, endpoints MUST make use of any The First-Come-First-Remembered policy is added as an example and a potential default behavior.  <ins> RD discovery: Drop the previously stated assumption that RDAO and any DHCP options would only be used together with SLAAC and DHCP for address configuration, respectivly. Give concrete guidance for address selection based on RFC6724 </ins> Terminology:


Add note about information in Registration Resource path. <del> RDAO: Clarify that it is an option for RAs and not other ND messages. </del>  Examples:

to align with RDNSS and other similar options See-Also: URL That's a large enough change that I'd like to ask for explicit comments from the authors that worked on that section before. Éric's comment on aligning with other options makes a lot of sense to me, it has the same overhead on the wire, doesn't practically increase memory usage in implementations given they'll convert it into whatever units their timers use anyway, and can make code more compact by reusing code. If I missed any prior considerations that led to this being 16-bit minutes, please let me know before the cutoff Monday night, otherwise I'll merge it. Thank you for the work put into this document. As you can noticed, I have cleared my 2 DISCUSS points (kept below for archive) thank you also for replying to my comments over email. BTW, I appreciated the use of ASCII art to represent an entity-relationship diagram ! I hope that this helps to improve the document, -- Section 4.1 -- It will be trivial to fix, in IPv6 address configuration (SLAAC vs. DHCP) is orthogonal to DHCP 'other-information'. E.g., even if address is configured via SLAAC, DHCPv6 other-information can be used to configure the Recursive DNS Server (or possibly the RD). -- Section 4.1.1 -- Another trivial DISCUSS to fix: in which message is this RDAO sent ? I guess unicast Router Advertisement but this MUST be specified. In general, I wonder how much interactions and exchanges of ideas have happened in the long history of this document with the DNSSD (DNS Service Discovery) Working Group that has very similar constraints (sleeping nodes) and same objectives. -- Section 2 -- To be honest: I am not too much an APP person; therefore, I was surprised to see "source address (URI)" used to identify the "anchor="... I do not mind too much the use of "destination address (URI)" as it is really a destination but the anchor does not appear to me as a "source address". Is it common terminology ? If so, then ignore my COMMENT, else I suggest to change to "destination URI" and simply "anchor" ? -- Section 3.3 -- Should the lifetime be specified in seconds at first use in the text? -- Section 3.6 -- Is the use of "M2M" still current? I would suggest to use the word "IoT" esp when 6LBR (assuming it is 6LO Border Router) is cited later. Please expand and add reference for 6LBR. Using 'modern' technologies (cfr LP-WAN WG) could also add justification to section 3.5. -- Section 4.1 -- About "coap://[MCD1]/.well-known/core?rt=core.rd*", what is the value of MCD1 ? The IANA section discuss about it but it may help the reader to give a hint before (or simply use TBDx that is common in I-D). Any reason to use "address" rather than "group" in "When answering a multicast request directed at a link-local address" ? Later "to use one of their own routable addresses for registration." but there can be multiple configured prefixes... Which one should the RD select ? Should this be specified ? As a co-author of RFC 8801, I would have appreciated to read PvD option mentionned to discover the RD. Any reason why PvD Option cannot be used ? -- Section 4.1.1 -- I suggest to swap the reserved and lifetime fields in order to be able to use a lifetime in units of seconds (to be consistent with other NDP options). -- Section 5 -- May be I missed it, but, can an end-point register multiple base URI ? E.g., multiple IPv6 addresses. -- Section 9.2 -- For information, value 38 is already assigned to RFC 8781. -- Section 2 -- The extra new lines when defining "Sector" are slighly confusing. Same applies to "Target" and "Context". This is cosmetic only.

Add note about information in Registration Resource path.  <ins> RDAO: Clarify that it is an option for RAs and not other ND messages. Change Lifetime from 16-bit minutes to 32-bit seconds and swap it with Reserved (aligning it with RDNSS which it shares other properties as well). </ins> Examples:


9.2. This document registers one new ND option type under the sub-registry <del> "IPv6 Neighbor Discovery Option Formats": </del>  Resource Directory Address Option (TBD38)

rather than only referring to the subregistry's name See-Also: URL I concur with my colleagues who commended the authors for making the document very readable. I support Roman's first two DISCUSS points. In Section 9.2, you might want to mention that you're talking about a sub-registry under "Internet Control Message Protocol version 6 (ICMPv6) Parameters". In Section 9.3, you enumerate six fields in each registration, but the initial table of entries has only five columns. It's obvious (I think) that the sixth column would be "this document" for all entries, but I suggest that you should either include the column or some prose making this explicit (since everything else is).

9.2. This document registers one new ND option type under the sub-registry  <ins> "IPv6 Neighbor Discovery Option Formats" of the "Internet Control Message Protocol version 6 (ICMPv6) Parameters" registry: </ins> Resource Directory Address Option (TBD38)


querying the described device's /.well-known/core resource directly. Data in the RD can only be provided by the device which hosts those <del> data or a dedicated Commissioning Tool (CT).  These CTs are thought to act on behalf of endpoints too constrained, or generally unable, to present that information themselves.  No other client can modify data in the RD.  Changes to the information in the RD do not propagate automatically back to the web servers from where the information originated. </del>  3.2. 4.1. <del> A (re-)starting device may want to find one or more RDs for discovery purposes.  Dependent on the operational conditions, one or more of the techniques below apply. </del>  The device may be pre-configured to exercise specific mechanisms for finding the RD:

See-Also: URL Thank you -- I found this document to be a very friendly read. The Terminology section in particular was one of the best in recent memory. Comments: 1: "These CTs arethought to act on behalf of endpoints too constrained, or generally unable, to present that information themselves. " This reads very oddly - "thought to act on" sounds like we've seen some of these in the wild, and only have a vague idea about how they work. Does "These CTs act on behalf of endpoints too constrained, or generally unable, to present that information themselves. " work? 2: "From the system design point of view, the ambition is to design horizontal solutions that  can enable utilization of machines in different applications depending on their current availability and capabilities as well as application requirements, thus avoiding silo like solutions" - this is very buzzwordy, and I have no idea what it is actually trying to say... 3: "  A (re-)starting device may want to find one or more RDs for discovery purposes." Either I don't understand what this sentence is  trying to say, or "for discovery purposes" should be dropped....  4: "As some of the RD addresses obtained by the methods listed here are just (more or less educated) guesses, endpoints MUST make use of any error messages to very strictly rate-limit requests to candidate IP addresses that don't work out. " What happens if device A discovers RD X, and device B discovers RD Y? Surely there has to be some sort of deterministic method so that one doesn't end up in a "split brain" type outcome? Nits: 1: " The input to an RD is composed of links and the output is composed of links constructed from the information stored in the RD." While  true, this sentence doesn't actually communicate anything useful to the reader -- I'd suggest removing it from the Abstract (note that this is just a nit). 2: "The RD is primarily a tool to make discovery operations more efficient than querying /.well-known/core on all connected devices, or across boundaries that would be limiting those operations." s/would be limiting those/that would limit those/

querying the described device's /.well-known/core resource directly. Data in the RD can only be provided by the device which hosts those  <ins> data or a dedicated Commissioning Tool (CT).  These CTs act on behalf of endpoints too constrained, or generally unable, to present that information themselves.  No other client can modify data in the RD. Changes to the information in the RD do not propagate automatically back to the web servers from where the information originated. </ins> 3.2. 4.1.  <ins> A (re-)starting device may want to find one or more RDs before it can discover their URIs.  Dependent on the operational conditions, one or more of the techniques below apply. </ins> The device may be pre-configured to exercise specific mechanisms for finding the RD:


business to the new type of users: machines.  The machines are connected directly to a mobile network using an appropriate embedded wireless interface (GSM/GPRS, WCDMA, LTE) or via a gateway providing <del> short and wide range wireless interfaces.  From the system design point of view, the ambition is to design horizontal solutions that can enable utilization of machines in different applications depending on their current availability and capabilities as well as application requirements, thus avoiding silo like solutions.  One of the crucial enablers of such design is the ability to discover resources (and thus the endpoints they are hosted on) capable of providing required information at a given time or acting on instructions from the end users. </del>  Imagine a scenario where endpoints installed on vehicles enable tracking of the position of these vehicles for fleet management Home and building automation use case: Tie in with RD  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.

See-Also: URL (as per 2020-10-08 interim) Thank you -- I found this document to be a very friendly read. The Terminology section in particular was one of the best in recent memory. Comments: 1: "These CTs arethought to act on behalf of endpoints too constrained, or generally unable, to present that information themselves. " This reads very oddly - "thought to act on" sounds like we've seen some of these in the wild, and only have a vague idea about how they work. Does "These CTs act on behalf of endpoints too constrained, or generally unable, to present that information themselves. " work? 2: "From the system design point of view, the ambition is to design horizontal solutions that  can enable utilization of machines in different applications depending on their current availability and capabilities as well as application requirements, thus avoiding silo like solutions" - this is very buzzwordy, and I have no idea what it is actually trying to say... 3: "  A (re-)starting device may want to find one or more RDs for discovery purposes." Either I don't understand what this sentence is  trying to say, or "for discovery purposes" should be dropped....  4: "As some of the RD addresses obtained by the methods listed here are just (more or less educated) guesses, endpoints MUST make use of any error messages to very strictly rate-limit requests to candidate IP addresses that don't work out. " What happens if device A discovers RD X, and device B discovers RD Y? Surely there has to be some sort of deterministic method so that one doesn't end up in a "split brain" type outcome? Nits: 1: " The input to an RD is composed of links and the output is composed of links constructed from the information stored in the RD." While  true, this sentence doesn't actually communicate anything useful to the reader -- I'd suggest removing it from the Abstract (note that this is just a nit). 2: "The RD is primarily a tool to make discovery operations more efficient than querying /.well-known/core on all connected devices, or across boundaries that would be limiting those operations." s/would be limiting those/that would limit those/

business to the new type of users: machines.  The machines are connected directly to a mobile network using an appropriate embedded wireless interface (GSM/GPRS, WCDMA, LTE) or via a gateway providing  <ins> short and wide range wireless interfaces.  The ambition in such systems is to build them from reusable components.  These speed up development and deployment, and enable shared use of machines across different applications.  One crucial component of such systems is the discovery of resources (and thus the endpoints they are hosted on) capable of providing required information at a given time or acting on instructions from the end users. </ins> Imagine a scenario where endpoints installed on vehicles enable tracking of the position of these vehicles for fleet management Home and building automation use case: Tie in with RD <ins> M2M use case: Move system design paragraph towards the topic of reusability. </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.


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 <del> policies apply to different sectors. </del>  8.

See-Also: URL Apart from pointing out the scope, this also comprehensively lists the few configuration options that are there for such an RD. Hi, Thank you for this document. I'm glad that the shepherd's writeup indicates that there are implementations since that indicates that there does appear to be value in standardizing this work, despite its long journey. My main comment (which I was considering raising as a discuss) is: Since this document is defining a new service, I think that this document would benefit on having a short later section on "Operations, Administration and Management". This document does seem to cover some management/administration considerations in various sections in a somewhat ad hoc way, but having a section highlighting those would potentially make it easier deploy.  Defining a common management model (or API) would potentially also make administration of the service easier, I don't know if that had been considered, and if useful could be done as a separate document. A few other comments: What happens if an endpoint is managing the registration and is upgraded to new hardware with a different certificate?  Would the updated endpoint expect to be able to update the registration?  Or would it have to wait for the existing registration to timeout (which could be a long time)? Nit: Perhaps reword the second sentence.  Otherwise it seems to conflict with the last sentence of the prior paragraph. The "SHOULD NOT" feels a bit strong to me, and I would prefer to see this as "MAY NOT".  In many cases, if the configuration is not too big then providing the full configuration makes it easy to guarantee that the receiver has exactly the correct configuration.  I appreciate that there are many cases where from an endpoint perspective it may want to keep the update small, but if I was doing this from a CT, I think that I would rather just resend the entire configuration, if it is not large. Just to check, is it correct that the anchor in the http link is also to coap://?  If this is wrong then there is a second example in the same section that also needs to be fixed.

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  <ins> policies apply to different sectors.  The configuration of such a behavior, as well as any other configuration applicable to such an RD (i.e. the set of recognized authorities) is out of scope for this document. </ins> 8.


authorization credentials authorizing only operations on that particular endpoint name, or a wider range of endpoint names. <del> When certificates are used as authorization credentials, the sector(s) and endpoint name(s) can be transported in the subject.  In an ACE context, those are typically transported in a scope claim. </del>  7.1.1. The First-Come-First-Remembered policy is added as an example and a potential default behavior.  RD discovery: Drop the previously stated assumption that RDAO and any DHCP

The "subject" is only an example, but made more precise. Closes: URL
As in , and notes, the current wording is not clear. Jim provided help , just needs checking whether that really addresses all comments. Thanks for addressing my DISCUSS and COMMENT feedback
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.)

authorization credentials authorizing only operations on that particular endpoint name, or a wider range of endpoint names.  <ins> It is up to the concrete security policy to describe how endpoint name and sector are transported when certificates are used.  For example, it may describe how SubjectAltName dNSName entries are mapped to endpoint and domain names. </ins> 7.1.1. The First-Come-First-Remembered policy is added as an example and a potential default behavior. <ins> Clarify that the mapping between endpoint names and subject fields is up to a policy that defines reliance on names, and give an example. </ins> RD discovery: Drop the previously stated assumption that RDAO and any DHCP


exactly the Well-Known Interface of RFC6690 Section 4, with the additional requirement that the server MUST support query filtering): <del> EP and Client -> RD </del>  GET The registration request interface is specified as follows: <del> EP -> RD </del>  POST The update registration request interface is specified as follows: <del> EP -> RD </del>  POST The removal request interface is specified as follows: <del> EP -> RD </del>  DELETE Moved Christian Amsuess to first author  changes from -24 to -25 Large rework of section 7 (Security policies)

As the CT is kept distinct in the diagrams and definitions, we can't "just mean EP or CT" in the interactions. This affects only regular registration; simple is not for CTs. See-Also: URL 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.)

exactly the Well-Known Interface of RFC6690 Section 4, with the additional requirement that the server MUST support query filtering):  <ins> EP, CT or Client -> RD </ins> GET The registration request interface is specified as follows:  <ins> EP or CT -> RD </ins> POST The update registration request interface is specified as follows:  <ins> EP or CT -> RD </ins> POST The removal request interface is specified as follows:  <ins> EP or CT -> RD </ins> DELETE Moved Christian Amsuess to first author <ins> Interaction tables: list CTs as possible initiators where applicable </ins> changes from -24 to -25 Large rework of section 7 (Security policies)


a set of links belonging to the hosting web server The web server is free to choose links it deems appropriate to be <del> exposed in its ".well-known/core".  Typically, the links describe </del>  resources that are served by the host, but the set can also contain links to resources on other servers (see examples in RFC6690 page 14).  The set does not necessarily contain links to all resources 7.3. When registrants publish information in the RD that is not available <del> to any client that would query the registrant's .well-known/core </del>  interface, or when lookups to that interface are subject so stricter firewalling than lookups to the RD, the RD may need to limit which lookup clients may access the information. Simple registration could be used to circumvent address-based access control: An attacker would send a simple registration request with the victim's address as source address, and later look up the <del> victim's .well-known/core content in the RD.  Mitigation for this is </del>  recommended in simple. The Registration Resource path is visible to any client that is

Even disregarding the examples that necessarily have the slash, this (vs. plain .well-known/core) version was the more common in the text so far. Closes: URL
This actually
Current master branch text is really unclear: What does it mean : "used to find the identification" ? Can we say intead "used to identify the components" ? How can the URI discovery process identify client-server incompatibilities? CoAP doesn't let you discover supported protocol versions, options, etc. as far as I know, by default. For those implementations not supporting I-D.bormann-t2trg-rel-impl , it is really unclear what to do with this paragraph.
Oups, wrong link in the commit -- sorry for the noise
The intention behind this paragraph is merely to point those who want versioning and more RD metadata that is immaterial to the regular operation to a place where they can safely do so. I see, however, how the "it is necessary to" makes this sound like more than there really is to it. Accordingly, the incompatibilities part is not about finding that something can't work in the first place (that works on a positive-list base using rt and that like), but more for understanding later why things don't work (say, client X produces a document that upsets RD implementation Y in versions earlier than 0.4.1). The address is in section 4 of 6690 (ie. just .well-known/core); now referred to by the name it has there.
A couple of places has ".well-known/core" as resource name, while in most places it says "/.well-known/core". Proposal is to update all occurrences to the latter form. (Maybe this is already addressed in the pull requests with nits, but there are so many - hard to check...)

a set of links belonging to the hosting web server The web server is free to choose links it deems appropriate to be  <ins> exposed in its "/.well-known/core".  Typically, the links describe </ins> resources that are served by the host, but the set can also contain links to resources on other servers (see examples in RFC6690 page 14).  The set does not necessarily contain links to all resources 7.3. When registrants publish information in the RD that is not available  <ins> to any client that would query the registrant's /.well-known/core </ins> interface, or when lookups to that interface are subject so stricter firewalling than lookups to the RD, the RD may need to limit which lookup clients may access the information. Simple registration could be used to circumvent address-based access control: An attacker would send a simple registration request with the victim's address as source address, and later look up the  <ins> victim's /.well-known/core content in the RD.  Mitigation for this is </ins> recommended in simple. The Registration Resource path is visible to any client that is