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

[Christian Amsüss <[e-mail]>]

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.

* Ad 4.1.1: Where would the rd template value come from?

* 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).

  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).

* 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?)

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