Re: [core] Fwd: New Version Notification for draft-djamaa-core-proactive-rd-discovery-00.txt

[Badis Djamaa <[e-mail]>]

Thank you Christian for your quick and thorough review, please find replies
inline

On Tue, 2 Apr 2019 at 07:40, Christian Amsüss <[e-mail]> wrote:

> Hello Badis,
>
> On Mon, Apr 01, 2019 at 07:29:21PM +0200, Badis Djamaa wrote:
> > A new Internet-draft has been uploaded to IETF repository. The draft
> > proposes an announce-based mechanism that builds upon CoAP Group
> > Communication (GroupComm) to discover CoRE Resource Directories (RDs).
>
> thanks for sending this document; it describes a strategy I have not
> considered before.
>
> On first reading, some questions and remarks came up:
>
> * Ad Approach 6: This approach does not necessarily mean that the RD is
>   deployed on the 6LBR, just that it can be discovered from it (eg. the
>   6LBR may announce `<coap://some.example.com/rd>;rt=core.rd`. Same goes
>   for approach 7.
>

 The text in the RD draft seems to indicate that the "(6LBR) can act as a
resource
  directory". Thus, the 6LBR address can be announced in the ABRO and
  confirmation of RD function can be done by unicasting
  "coap://[6LBR]/.well-known/core?rt=core.rd*".
  Otherwise, how would the RD be announced to the 6LBR (not mentioned in
the RD draft )?

>
> * Ad 4.1.1: Where would the rd template value come from?
>
>   In the current version, the rd template value may be assumed a default
location,
  for instance, "core-rd". The Location-URI Template would be then
/core-rd/ep where
  ep comes from the RD's "ep" attribute contained in the registration
request,
  which is unique per RD. Another possibility is to locate the posted RD
resource
  under well-known/core/ep at each device.
  What is your take on this?

* The DA generation process looks like every device is supposed to be a
>   simple RD (that may be only capable of accepting a single
>   registration, which is that of the actual ID), that is then
>   replicated.
>
>   Maintaining such replication seems to me to be quite a task for small
>   nodes, especially if they're supposed to use the registration update
>   interface and thus remember locations for each sub-PRD they registered
>   to (though I'm not sure what is intended here, "SHOULD only contain
>   the content and parameters that have been changed" seems to imply
>   registration update, while 4.1.1 describes the registration interface
>   which can't rely on previous registrations).
>
>  True, but DA is only generated by the RD and forwarded using CoAP Group
  Communication. Devices do no replication tasks. Also, very constrained
devices
  (section 5.2 of RD), may simply ignore the received DA (see section 3)

  Also, the current version of PRD does not use a separate resource update
  interface. Both the first registration (which doesn't rely on previous
registrations)
  and periodic updates sent by RDs (relying on previous registrations)
  use the registration interface. The difference is that in the latter,
  the optional unchanged parameters and payload are not POSTed. Processing
of
  the received DA, for both cases, is specified in section 4.1.2.

  The document may benefit from exploring alternatives here (even if
>   only to confirm the conclusion that the approach taken is the right
>   one), like using the Simple Registration interface (would answer the
>   question ad 4.1.1) or setting the announcements up as nontraditional
>   responses[1] (eg. notifications about an unspoken request to GET
>   /.well-known/core?rt=core.rd. I can't tell whether that'd even be a
>   good idea, that's yet to be seen).
>
>  The Simple Registration (SR) interface and Nontraditional
  Responses (NR) need the devices to be aware of the RD
  location. Announcing RD's location and functionalities, in the first
place,
  is a part of the draft objectives. For the following announcements,
  I can see a use of SR and NR, however, I do not see how they can be used
  for the first announcement ?

* I like to keep the resource directory as little a special-case as
>   possible (see RD Section 3.1). In later stages of this document, it
>   may be worth looking into whether there is anything in particular
>   about RD announcements in it as compared to general link announcments.
>   (Sure, there comes a point when not all resources can be announced
>   proactively, and it makes sense to announce an RD as that provides all
>   the other lookups, but maybe a single service is queried so often by
>   each and every joining node that it makes sense to announce an RD
>   *and* another link or two?)
>

 Thank you for this suggestion, we will consider it in future versions. Can
you
  please indicate some key services that need to be announced.


> Best regards
> Christian
>
> [1]: https://tools.ietf.org/html/draft-bormann-core-responses-00
>
> --
> To use raw power is to make yourself infinitely vulnerable to greater
> powers.
>   -- Bene Gesserit axiom
>

All the best,
Badis