< draft-ietf-core-resource-directory-22.txt   draft-ietf-core-resource-directory-23.txt >
CoRE Z. Shelby CoRE Z. Shelby
Internet-Draft ARM Internet-Draft ARM
Intended status: Standards Track M. Koster Intended status: Standards Track M. Koster
Expires: January 3, 2020 SmartThings Expires: January 9, 2020 SmartThings
C. Bormann C. Bormann
Universitaet Bremen TZI Universitaet Bremen TZI
P. van der Stok P. van der Stok
consultant consultant
C. Amsuess, Ed. C. Amsuess, Ed.
July 02, 2019 July 08, 2019
CoRE Resource Directory CoRE Resource Directory
draft-ietf-core-resource-directory-22 draft-ietf-core-resource-directory-23
Abstract Abstract
In many IoT applications, direct discovery of resources is not In many IoT applications, direct discovery of resources is not
practical due to sleeping nodes, disperse networks, or networks where practical due to sleeping nodes, disperse networks, or networks where
multicast traffic is inefficient. These problems can be solved by multicast traffic is inefficient. These problems can be solved by
employing an entity called a Resource Directory (RD), which contains employing an entity called a Resource Directory (RD), which contains
information about resources held on other servers, allowing lookups information about resources held on other servers, allowing lookups
to be performed for those resources. The input to an RD is composed 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 of links and the output is composed of links constructed from the
skipping to change at page 1, line 47 skipping to change at page 1, line 47
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 28 skipping to change at page 3, line 28
10.1. Lighting Installation . . . . . . . . . . . . . . . . . 48 10.1. Lighting Installation . . . . . . . . . . . . . . . . . 48
10.1.1. Installation Characteristics . . . . . . . . . . . . 48 10.1.1. Installation Characteristics . . . . . . . . . . . . 48
10.1.2. RD entries . . . . . . . . . . . . . . . . . . . . . 49 10.1.2. RD entries . . . . . . . . . . . . . . . . . . . . . 49
10.2. OMA Lightweight M2M (LWM2M) Example . . . . . . . . . . 52 10.2. OMA Lightweight M2M (LWM2M) Example . . . . . . . . . . 52
10.2.1. The LWM2M Object Model . . . . . . . . . . . . . . . 52 10.2.1. The LWM2M Object Model . . . . . . . . . . . . . . . 52
10.2.2. LWM2M Register Endpoint . . . . . . . . . . . . . . 54 10.2.2. LWM2M Register Endpoint . . . . . . . . . . . . . . 54
10.2.3. LWM2M Update Endpoint Registration . . . . . . . . . 55 10.2.3. LWM2M Update Endpoint Registration . . . . . . . . . 55
10.2.4. LWM2M De-Register Endpoint . . . . . . . . . . . . . 56 10.2.4. LWM2M De-Register Endpoint . . . . . . . . . . . . . 56
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 56 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 56
12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 56 12. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 56
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 65 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 66
13.1. Normative References . . . . . . . . . . . . . . . . . . 65 13.1. Normative References . . . . . . . . . . . . . . . . . . 66
13.2. Informative References . . . . . . . . . . . . . . . . . 66 13.2. Informative References . . . . . . . . . . . . . . . . . 66
Appendix A. Groups Registration and Lookup . . . . . . . . . . . 68 Appendix A. Groups Registration and Lookup . . . . . . . . . . . 68
Appendix B. Web links and the Resource Directory . . . . . . . . 70 Appendix B. Web links and the Resource Directory . . . . . . . . 70
B.1. A simple example . . . . . . . . . . . . . . . . . . . . 70 B.1. A simple example . . . . . . . . . . . . . . . . . . . . 70
B.1.1. Resolving the URIs . . . . . . . . . . . . . . . . . 71 B.1.1. Resolving the URIs . . . . . . . . . . . . . . . . . 71
B.1.2. Interpreting attributes and relations . . . . . . . . 71 B.1.2. Interpreting attributes and relations . . . . . . . . 71
B.2. A slightly more complex example . . . . . . . . . . . . . 71 B.2. A slightly more complex example . . . . . . . . . . . . . 71
B.3. Enter the Resource Directory . . . . . . . . . . . . . . 72 B.3. Enter the Resource Directory . . . . . . . . . . . . . . 72
B.4. A note on differences between link-format and Link B.4. A note on differences between link-format and Link
headers . . . . . . . . . . . . . . . . . . . . . . . . . 74 headers . . . . . . . . . . . . . . . . . . . . . . . . . 74
skipping to change at page 21, line 19 skipping to change at page 21, line 19
lookup are example values. The server in this example also indicates lookup are example values. The server in this example also indicates
that it is capable of providing observation on resource lookups. that it is capable of providing observation on resource lookups.
Req: GET coap://[MCD1]/.well-known/core?rt=core.rd* Req: GET coap://[MCD1]/.well-known/core?rt=core.rd*
Res: 2.05 Content Res: 2.05 Content
</rd>;rt="core.rd";ct="40 65225", </rd>;rt="core.rd";ct="40 65225",
</rd-lookup/res>;rt="core.rd-lookup-res";ct="40 TBD64 TBD504";obs, </rd-lookup/res>;rt="core.rd-lookup-res";ct="40 TBD64 TBD504";obs,
</rd-lookup/ep>;rt="core.rd-lookup-ep";ct="40 TBD64 TBD504", </rd-lookup/ep>;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 formats
From a management and maintenance perspective, it is necessary to From a management and maintenance perspective, it is necessary to
identify the components that constitute the RD server. The identify the components that constitute the RD server. The
identification refers to information about for example client-server identification refers to information about for example client-server
incompatibilities, supported features, required updates and other incompatibilities, supported features, required updates and other
aspects. The URI discovery address, a described in section 4 of aspects. The URI discovery address, a described in section 4 of
[RFC6690] can be used to find the identification. [RFC6690] can be used to find the identification.
It would typically be stored in an implementation information link It would typically be stored in an implementation information link
(as described in [I-D.bormann-t2trg-rel-impl]): (as described in [I-D.bormann-t2trg-rel-impl]):
Req: GET /.well-known/core?rel=impl-info Req: GET /.well-known/core?rel=impl-info
Res: 2.05 Content Res: 2.05 Content
<http://software.example.com/shiny-resource-directory/1.0beta1>; <http://software.example.com/shiny-resource-directory/1.0beta1>;
rel="impl-info" 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 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 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 (as in this example) or at individual RD components. The latter is
to be expected when different applications are run on the same to be expected when different applications are run on the same
server. server.
5. Registration 5. Registration
After discovering the location of an RD, a registrant-ep or CT MAY After discovering the location of an RD, a registrant-ep or CT MAY
skipping to change at page 30, line 46 skipping to change at page 30, line 46
the request and was not set before either, the source address the request and was not set before either, the source address
and source port of the update request are stored as the Base and source port of the update request are stored as the Base
URI. URI.
extra-attrs := Additional registration attributes (optional). As extra-attrs := Additional registration attributes (optional). As
with the registration, the RD processes them if it knows their with the registration, the RD processes them if it knows their
semantics. Otherwise, unknown attributes are stored as semantics. Otherwise, unknown attributes are stored as
endpoint attributes, overriding any previously stored endpoint endpoint attributes, overriding any previously stored endpoint
attributes of the same key. 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) Content-Format: none (no payload)
The following responses are expected on this interface: The following responses are expected on this interface:
Success: 2.04 "Changed" or 204 "No Content" if the update was Success: 2.04 "Changed" or 204 "No Content" if the update was
successfully processed. successfully processed.
Failure: 4.04 "Not Found" or 404 "Not Found". Registration does not Failure: 4.04 "Not Found" or 404 "Not Found". Registration does not
exist (e.g. may have been removed). exist (e.g. may have been removed).
skipping to change at page 56, line 27 skipping to change at page 56, line 27
Brandt, Matthieu Vial, Jim Schaad, Mohit Sethi, Hauke Petersen, Brandt, Matthieu Vial, Jim Schaad, Mohit Sethi, Hauke Petersen,
Hannes Tschofenig, Sampo Ukkola, Linyi Tian, Jan Newmarch, Matthias Hannes Tschofenig, Sampo Ukkola, Linyi Tian, Jan Newmarch, Matthias
Kovatsch, Jaime Jimenez and Ted Lemon have provided helpful comments, Kovatsch, Jaime Jimenez and Ted Lemon have provided helpful comments,
discussions and ideas to improve and shape this document. Zach would discussions and ideas to improve and shape this document. Zach would
also like to thank his colleagues from the EU FP7 SENSEI project, also like to thank his colleagues from the EU FP7 SENSEI project,
where many of the resource directory concepts were originally where many of the resource directory concepts were originally
developed. developed.
12. Changelog 12. Changelog
changes from -22 to -23
o Explain that updates can not remove attributes
o Typo fixes
changes from -21 to -22 changes from -21 to -22
o Request a dedicated IPv4 address from IANA (rather than sharing o Request a dedicated IPv4 address from IANA (rather than sharing
with All CoAP nodes) with All CoAP nodes)
o Fix erroneous examples o Fix erroneous examples
o Editorial changes o Editorial changes
* Add figure numbers to examples * Add figure numbers to examples
skipping to change at page 67, line 12 skipping to change at page 67, line 19
Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-24 Framework (ACE-OAuth)", draft-ietf-ace-oauth-authz-24
(work in progress), March 2019. (work in progress), March 2019.
[I-D.ietf-core-links-json] [I-D.ietf-core-links-json]
Li, K., Rahman, A., and C. Bormann, "Representing Li, K., Rahman, A., and C. Bormann, "Representing
Constrained RESTful Environments (CoRE) Link Format in Constrained RESTful Environments (CoRE) Link Format in
JSON and CBOR", draft-ietf-core-links-json-10 (work in JSON and CBOR", draft-ietf-core-links-json-10 (work in
progress), February 2018. progress), February 2018.
[I-D.ietf-core-rd-dns-sd] [I-D.ietf-core-rd-dns-sd]
Lynn, K., Stok, P., Koster, M., and C. Amsuess, "CoRE Stok, P., Koster, M., and C. Amsuess, "CoRE Resource
Resource Directory: DNS-SD mapping", draft-ietf-core-rd- Directory: DNS-SD mapping", draft-ietf-core-rd-dns-sd-05
dns-sd-04 (work in progress), March 2019. (work in progress), July 2019.
[I-D.silverajan-core-coap-protocol-negotiation] [I-D.silverajan-core-coap-protocol-negotiation]
Silverajan, B. and M. Ocak, "CoAP Protocol Negotiation", Silverajan, B. and M. Ocak, "CoAP Protocol Negotiation",
draft-silverajan-core-coap-protocol-negotiation-09 (work draft-silverajan-core-coap-protocol-negotiation-09 (work
in progress), July 2018. in progress), July 2018.
[RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler,
"Transmission of IPv6 Packets over IEEE 802.15.4 "Transmission of IPv6 Packets over IEEE 802.15.4
Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007, Networks", RFC 4944, DOI 10.17487/RFC4944, September 2007,
<https://www.rfc-editor.org/info/rfc4944>. <https://www.rfc-editor.org/info/rfc4944>.
 End of changes. 10 change blocks. 
11 lines changed or deleted 27 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/