--- 1/draft-ietf-core-resource-directory-22.txt 2019-07-08 14:19:45.793685180 -0700 +++ 2/draft-ietf-core-resource-directory-23.txt 2019-07-08 14:19:46.073692236 -0700 @@ -1,24 +1,24 @@ CoRE Z. Shelby Internet-Draft ARM Intended status: Standards Track M. Koster -Expires: January 3, 2020 SmartThings +Expires: January 9, 2020 SmartThings C. Bormann Universitaet Bremen TZI P. van der Stok consultant C. Amsuess, Ed. - July 02, 2019 + July 08, 2019 CoRE Resource Directory - draft-ietf-core-resource-directory-22 + draft-ietf-core-resource-directory-23 Abstract In many IoT applications, direct discovery of resources is not 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 @@ -36,21 +36,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on January 3, 2020. + This Internet-Draft will expire on January 9, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -110,22 +110,22 @@ 10.1. Lighting Installation . . . . . . . . . . . . . . . . . 48 10.1.1. Installation Characteristics . . . . . . . . . . . . 48 10.1.2. RD entries . . . . . . . . . . . . . . . . . . . . . 49 10.2. OMA Lightweight M2M (LWM2M) Example . . . . . . . . . . 52 10.2.1. The LWM2M Object Model . . . . . . . . . . . . . . . 52 10.2.2. LWM2M Register Endpoint . . . . . . . . . . . . . . 54 10.2.3. LWM2M Update Endpoint Registration . . . . . . . . . 55 10.2.4. LWM2M De-Register Endpoint . . . . . . . . . . . . . 56 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 56 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 56 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 65 - 13.1. Normative References . . . . . . . . . . . . . . . . . . 65 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 66 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 66 13.2. Informative References . . . . . . . . . . . . . . . . . 66 Appendix A. Groups Registration and Lookup . . . . . . . . . . . 68 Appendix B. Web links and the Resource Directory . . . . . . . . 70 B.1. A simple example . . . . . . . . . . . . . . . . . . . . 70 B.1.1. Resolving the URIs . . . . . . . . . . . . . . . . . 71 B.1.2. Interpreting attributes and relations . . . . . . . . 71 B.2. A slightly more complex example . . . . . . . . . . . . . 71 B.3. Enter the Resource Directory . . . . . . . . . . . . . . 72 B.4. A note on differences between link-format and Link headers . . . . . . . . . . . . . . . . . . . . . . . . . 74 @@ -899,40 +899,40 @@ lookup are example values. The server in this example also indicates that it is capable of providing observation on resource lookups. Req: GET coap://[MCD1]/.well-known/core?rt=core.rd* Res: 2.05 Content ;rt="core.rd";ct="40 65225", ;rt="core.rd-lookup-res";ct="40 TBD64 TBD504";obs, ;rt="core.rd-lookup-ep";ct="40 TBD64 TBD504", - Figure 6: Exemple discovery exchange indicating additional content- + Figure 6: Example discovery exchange indicating additional content- formats 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 incompatibilities, supported features, required updates and other aspects. The URI discovery address, a described in section 4 of [RFC6690] can be used to find the identification. It would typically be stored in an implementation information link (as described in [I-D.bormann-t2trg-rel-impl]): Req: GET /.well-known/core?rel=impl-info Res: 2.05 Content ; rel="impl-info" - Figure 7: Exemple exchange of obtaining implementation information + Figure 7: Example exchange of obtaining implementation information Note that depending on the particular server's architecture, such a link could be anchored at the RD server's root, at the discovery site (as in this example) or at individual RD components. The latter is to be expected when different applications are run on the same server. 5. Registration After discovering the location of an RD, a registrant-ep or CT MAY @@ -1346,20 +1346,30 @@ the request and was not set before either, the source address and source port of the update request are stored as the Base URI. extra-attrs := Additional registration attributes (optional). As with the registration, the RD processes them if it knows their semantics. Otherwise, unknown attributes are stored as endpoint attributes, overriding any previously stored endpoint attributes of the same key. + Note that this default behavior does not allow removing an + endpoint attribute in an update. For attributes whose + functionality depends on the endpoints' ability to remove them + in an update, it can make sense to define a value whose + presence is equivalent to the absence of a value. As an + alternative, an extension can define different updating rules + for their attributes. That necessitates either discovery of + whether the RD is aware of that extension, or tolerating the + default behavior. + Content-Format: none (no payload) The following responses are expected on this interface: Success: 2.04 "Changed" or 204 "No Content" if the update was successfully processed. Failure: 4.04 "Not Found" or 404 "Not Found". Registration does not exist (e.g. may have been removed). @@ -2519,20 +2528,26 @@ Brandt, Matthieu Vial, Jim Schaad, Mohit Sethi, Hauke Petersen, Hannes Tschofenig, Sampo Ukkola, Linyi Tian, Jan Newmarch, Matthias Kovatsch, Jaime Jimenez and Ted Lemon have provided helpful comments, 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 developed. 12. Changelog + changes from -22 to -23 + + o Explain that updates can not remove attributes + + o Typo fixes + changes from -21 to -22 o Request a dedicated IPv4 address from IANA (rather than sharing with All CoAP nodes) o Fix erroneous examples o Editorial changes * Add figure numbers to examples @@ -3025,23 +3038,23 @@ Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-24 (work in progress), March 2019. [I-D.ietf-core-links-json] Li, K., Rahman, A., and C. Bormann, "Representing Constrained RESTful Environments (CoRE) Link Format in JSON and CBOR", draft-ietf-core-links-json-10 (work in progress), February 2018. [I-D.ietf-core-rd-dns-sd] - Lynn, K., Stok, P., Koster, M., and C. Amsuess, "CoRE - Resource Directory: DNS-SD mapping", draft-ietf-core-rd- - dns-sd-04 (work in progress), March 2019. + Stok, P., Koster, M., and C. Amsuess, "CoRE Resource + Directory: DNS-SD mapping", draft-ietf-core-rd-dns-sd-05 + (work in progress), July 2019. [I-D.silverajan-core-coap-protocol-negotiation] Silverajan, B. and M. Ocak, "CoAP Protocol Negotiation", draft-silverajan-core-coap-protocol-negotiation-09 (work in progress), July 2018. [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, "Transmission of IPv6 Packets over IEEE 802.15.4 Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, .