Original text:
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

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

Revised text:
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