Subject: [core] draft-ietf-core-resource-directory-11

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 1 Sep 2017 15:24:47 +0200

Hi RD draft authors, Hi all,

I read through some parts of the RD document that appear to be relevant
for LwM2M and I have a few comments and questions.

Section 3.3.

This sentence reads broken:

   "In a typical scenario, during a boot-up procedure (and periodically
   afterwards), the machines (endpoints) register with a Resource
   Directory (for example EPs installed on vehicles enabling tracking of
   their position for fleet management purposes and monitoring
   environment parameters) hosted by the mobile operator or somewhere
   else in the network, periodically a description of its own
   capabilities."

Maybe you want to shorted it a bit and split it into two sentences, such as

"Imagine a scenario where endpoints installed on vehicles enabling
tracking of the position for fleet management purposes and allow
monitoring of environment parameters. During the boot-up process
endpoints register with a Resource Directory, which is hosted by the
mobile operator or somewhere in the cloud. Periodically, these endpoints
update their registration and may modify resources they offer."

I would also suggest to change this text from

"Due to the usual network configuration of mobile
networks, the EPs attached to the mobile network may not always be
efficiently reachable.  Therefore, a remote server is usually used to
provide proxy access to the EPs."

To:

"When endpoints are not always connected, for example because they enter
a sleep mode, a remote server is usually used to provide proxy access to
the endpoints."

From:

   "The users, for example mobile applications for
   environment monitoring, contact the RD, look up the endpoints capable
   of providing information about the environment using appropriate set
   of link parameters, obtain information on how to contact them (URLs
   of the proxy server) and then initiate interaction to obtain
   information that is finally processed, displayed on the screen and
   usually stored in a database."

To:

   "Mobile apps or web applications for
   environment monitoring contact the RD, look up the endpoints capable
   of providing information about the environment using appropriate set
   of link parameters, obtain information on how to contact them (URLs
   of the proxy server) and then initiate interaction to obtain
   information that is finally processed, displayed on the screen and
   usually stored in a database."

The beginning of Section 5.2. "URI Discovery" does not seem to be inline
with the text in Section 4. It appears that two different persons have
written the two sections or that the sections got reordered some time ago.

Section 5.3.1. "Simple Registration"

I am not sure I understand the motivation for introducing simple
registration. The text says "Not all endpoints hosting resources are
expected to know how to upload links to a RD". Under what condition is
an endpoint unable to know how to upload links to the RD?

Section 5.3.3.  "Third-party registration"

Are people using the third party registration given that it may be an
operational challenge?

Section 5.4.1.  "Registration Update"

"
   An update MAY update the lifetime or context registration parameters
   "lt", "con" as in Section 5.3 ) if the previous settings are to be
   retained.  Parameters that are not being ***changed changed*** SHOULD NOT
                                            ^^^^^^^^^^^^^^^^^^^^^^
   be included in an update.  Adding parameters that have not changed
   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 Section 5.3.
"

"
  An update MAY optionally add or replace links for the endpoint by
   including those links in the payload of the update as a CoRE Link
   Format document.  A link is replaced only if all of the target URI
   and relation type (if present) and anchor value (if present) match.
"

How are links deleted? It is not unlikely that resources get removed
during the lifetime of a registration.

"
   In addition to the use of POST, as described in this section, there
   is an alternate way to add, replace, and delete links using PATCH as
   described in Section 5.4.4.
"

Do you think it is a good idea to provide two ways to accomplish the
same effect? Why not only use PATCH?

5.4.4.  Update Endpoint Links

"
  In
   particular, a select-merge patch document format could combine the
   function of link selection query and link attribute replacement
   values.
"

Is this referring to an existing format or is this a more theoretical
thought? If it is the latter then I suggest to delete this sentence to
avoid confusion. If it isn't then add a reference.

"
   If no links are selected by the query parameters, the PATCH operation
   SHOULD NOT update the state of any resource, and SHOULD return a
   reply of "Changed".
"

I believe the correct wording should be

"
   If no links are selected by the query parameters, the PATCH operation
   MUST NOT update the state of any resource, and MUST return a
   reply of "Changed".
"

(There does not seem to be a better return code than changed even though
nothing was changed.)

8.  Security Considerations

"
   Endpoints using a
   Certificate MUST include the Endpoint identifier as the Subject of
   the Certificate, and this identifier MUST be checked by a resource
   directory to match the Endpoint identifier included in the
   Registration message.
"

Why is this only applicable to certificate-based authentication? I
believe it is an equally valid concern for use with PSK and raw public
key-based authentication.

The threat, which could be detailed a bit, can be described as follows:

---

Imagine you have a device from company A and another device from company
B. Both are managed by a single server. Both devices have unique,
per-device credentials for use with DTLS.

Now, imagine that company A wants to sabotage the device used by company
B. It uses its credentials during the TLS exchange. Then, it puts the
endpoint name of the company B device. If the server does not check
whether the identifier provided in the DTLS handshake matches the
identifier used at the CoAP layer then it may be inclined to use the
endpoint name for looking up what information to provision to that device.

---

Section 10.2.2. "LWM2M Register Endpoint"

FROM:
"
   Endpoint Name is mandatory, all other registration parameters are
   optional.
"

TO:
	
"
   Endpoint Name, Lifetime, and LWM2M Version are mandatory parameters
   for the register operation, all other registration parameters are
   optional.
"

In Table 5 you show some of the parameters used during the register
operation. Why did you omit Lifetime and Endpoint Name?

Use the term "Binding Mode" instead of "Protocol Binding".

   +------------+-------+-------------------------------+--------------+
   | Name       | Query | Validity                      | Description  |
   +------------+-------+-------------------------------+--------------+
   | Protocol   | b     | {"U",UQ","S","SQ","US","UQS"} | Available    |
   | Binding    |       |                               | Protocols    |
   |            |       |                               |              |
   | LWM2M      | ver   | 1.0                           | Spec Version |
   | Version    |       |                               |              |
   |            |       |                               |              |
   | SMS Number | sms   |                               | MSISDN       |
   +------------+-------+-------------------------------+--------------+

             Table 5: LWM2M Additional Registration Parameters
			
Why does the RD not have any version indication? Would it make sense to
introduce the 'ver' parameter as well since it is quite likely that
there may be new versions of the protocol. Also the use of the protocol
binding may not be too far fetched since devices may run coap over
multiple different transports.

Btw, I couldn't find a description of the "Endpoint Type" in the
document. This is a parameter that is not used in LwM2M but it is also
not clear what benefit it gives.

10.2.3.  LWM2M Update Endpoint Registration

The LwM2M update is really very similar to the registration update with
the only difference that there are more parameters defined and
available. All the parameters listed in that section are also available
with the initial registration but are all optional.

ciao
Hannes

---

From: peter van der Stok <[email-masked]>
Date: Mon, 04 Sep 2017 11:22:43 +0200

Hi Hannes,

thanks for sharing your thoughts with us.
See below for detailed comments.

> for LwM2M and I have a few comments and questions.
section 3.1 in my version
> update their registration and may modify resources they offer."

With slight changes to your text, this helps the readability.
> a sleep mode, a remote server is usually used to provide proxy access 

Yep, definitely clearer.
>    usually stored in a database."

OK
> written the two sections or that the sections got reordered some time 

Section 4 is rewritten, based on the discussion during the Prague Core 
meeting
Overlap with section 5.2 is removed form 5.2

> an endpoint unable to know how to upload links to the RD?

There has been a request to add this functionality.

> Are people using the third party registration given that it may be an

Yes, I only know people who want to use third party registration.
>    retained.  Parameters that are not being ***changed changed*** 
well spotted, thanks.

section 5.4.4 states:
A PATCH update adds, removes,...

> same effect? Why not only use PATCH?

One is about registrations and the other about links.

> avoid confusion. If it isn't then add a reference.

We have a discussion on the format of the file, also pointed out by Jim.

>    MUST NOT update the state of any resource, and MUST return a

probably better; someone may protest though.

> endpoint name for looking up what information to provision to that 

Thanks, but I will remove the suggestion that it is a "no rules 
respected" world out there.

>    for the register operation, all other registration parameters are

Thanks, will do

> operation. Why did you omit Lifetime and Endpoint Name?

They are "additional" registration parameters.

> Use the term "Binding Mode" instead of "Protocol Binding".

OK.
>    |            |       |                               |              
> |
>    | Version    |       |                               |              
> |
>    |            |       |                               |              
> |

Looks like a very sensible suggestion.
> not clear what benefit it gives.

et is discussed shortly in section 5.3 template.
Its use is rather application dependent, but there is an interest to 
provide additional information to the rt value.

> with the initial registration but are all optional.

Will use this text, thanks.
> Hannes

Thanks for your suggestions and interest.

Cheerio,

Peter
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core