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

From: Badis Djamaa <[email-masked]>
Date: Mon, 1 Apr 2019 19:29:21 +0200

Dear core chairs, members,

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

Looking forward to your comments and suggestions

Best, Badis

---------- Forwarded message ---------
From: <[email-masked]>
Date: Mon, 1 Apr 2019 at 19:06
Subject: New Version Notification for
draft-djamaa-core-proactive-rd-discovery-00.txt
To: Badis Djamaa <[email-masked]>, Ali Yachir <[email-masked]>

A new version of I-D, draft-djamaa-core-proactive-rd-discovery-00.txt
has been successfully submitted by Badis Djamaa and posted to the
IETF repository.

Name:           draft-djamaa-core-proactive-rd-discovery
Revision:       00
Title:          Proactive Discovery of CoRE Resource Directories
Document date:  2019-03-31
Group:          Individual Submission
Pages:          17
URL:
https://www.ietf.org/internet-drafts/draft-djamaa-core-proactive-rd-discovery-00.txt
Status:
https://datatracker.ietf.org/doc/draft-djamaa-core-proactive-rd-discovery/
Htmlized:
https://tools.ietf.org/html/draft-djamaa-core-proactive-rd-discovery-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-djamaa-core-proactive-rd-discovery

Abstract:
   The CoRE working group has proposed a Resource Directory (RD)
   solution to facilitate the discovery of the resources provided by
   constrained sensor and actuator networks. For such a mechanism to be
   effectively deployable, endpoints must first discover the existence
   of an RD in the network before being able to exploit its
   functionalities. This document presents Proactive RD Discovery
   (PRD); a scalable and effective mechanism to discover RDs. To
   achieve such qualities, PRD follows an announce-based model that
   builds upon CoAP Group Communication. PRD aims to provide important
   performance in terms of energy consumption, generated traffic,
   expressivity, and RD discovery time.

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 2 Apr 2019 07:40:17 +0200

Hello Badis,

> 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

---

From: Badis Djamaa <[email-masked]>
Date: Tue, 2 Apr 2019 20:42:19 +0200

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

>   6LBR may announce `<coap://some.example.com/rd>;rt=core.rd`. Same goes

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

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

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

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

> [1]: https://tools.ietf.org/html/draft-bormann-core-responses-00

All the best,
Badis

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 9 Apr 2019 11:41:13 +0200

Hello Badis,

some replies inline:

On Tue, Apr 02, 2019 at 08:42:19PM +0200, Badis Djamaa wrote:
>  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

That is exactly how contacting an RD via the 6LBR works; however, the
6LBR may only host the .well-known part of the RD but not the
registration and lookup resources. (This comment's main purpose was to
highlight alternatives to the "inconvenien[ce] of imposing that the RD
be physically integrated" with the 6LBR.)

>   Otherwise, how would the RD be announced to the 6LBR (not mentioned in

That is out of scope for the RD document, but I'd assume it would happen
about the same way the 6LBR is configured to send ND options, or how a
DHCP server is configured to send a particular option.

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

Anything outside /.well-known/ should not be fixed by specifications
according to RFC7320.

I don't have any concrete suggestions yet as to where those updates
should ideally go to.

>   Communication. Devices do no replication tasks. Also, very
>   constrained devices (section 5.2 of RD), may simply ignore the
>   received DA (see section 3)

OK, that was not fully clear to me before, especially with the open
question about the registration location.

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

As this is all intended for multicast and nodes joining the network, how
can there be a difference between a first registration and periodic
updates, which may arrive at devices that haev not seen the first
registration?

>   [...] Nontraditional Responses (NR) need the devices to be aware of the RD
>   location.

Not necessarily; the NR could contain all the necessary request details
as in [1].

[1]: https://tools.ietf.org/html/draft-bormann-core-responses-00#section-2

> > * [...] whether there is anything in particular about RD announcements
> > in it as compared to general link announcments.
> 
> Thank you for this suggestion, we will consider it in future versions. Can you

That very much depends on the particular use case, but if there is
anything that most devices joining the network would query right after
having discovered the RD, that would be it.

For example, in a setup that uses tiloca-core-oscore-discovery[2], it
might make sense to not only send the RD's data but also the links to
the most frequently joined join resources. (Not that the frequency of
group members joining would be likely to warrant this, but if it were
frequent enough that proactive-rd made sense, sending those links to
join resources proactively would just make as much sense.)

[2]: https://tools.ietf.org/html/draft-tiloca-core-oscore-discovery-02

Best regards
Christian

---

From: Badis Djamaa <[email-masked]>
Date: Tue, 30 Apr 2019 15:19:29 +0200

Hello Christian,
Thank you for your feedback,please see my comments inline

> DHCP server is configured to send a particular option.

I can think of a way here. Let an RD announces its address(es) in the RDAO
ND option.
When RDAO arrives to the 6LBR, it knows that it contains an RD address. The
6LBR can then construct a resource with rt=core.rd and base=RD address.
Doing so
the endpoint can GET the RD address from the 6LBR, which allows it to
contact the RD directly
for URI discovery as in section 4.3 of the CoRE-RD draft.

>  OK, thank you for outlining RFC7320, below are some thoughts concerning
this issue:

     1- To stay compatible with RFC7320 recommendations, one basic option
is to simply POST the registration
     to well-known/core. However, and since the replies are suppressed, the
RD won't know the registration location.
     This does not affect the periodic updates, but it can affect the
explicit registration removal interface.
     One intuition to deal with this, is not to provide an explicit removal
interface. Indeed, RD registrations will be removed
     at the expiry of their lifetime. The inconvenient arising from this
(i.e. an RD no longer available, but endpoints
     still have active registrations) can be mitigated. For instance, an
endpoint not getting a response from an RD after some
     tentative may delete the RD registration.

     2- I thought also not to suppress the responses, but such a solution
increases traffic, adds
     burden on an RD to manage all locations, and makes explicit
registration removal more complex.
     For instance, the RD should unicast each endpoint to delete its
registration.

     3- Also, the nontraditional response way you mentioned will have
difficulty to manage explicit registration removal.
     Indeed, while announcements can be realized as a response with
embedded request, I cannot see how a delete will
     be carried out?

     I prefer proposition 1 to propositions 2 and 3. All, however, find
difficulties to manage explicit registration removal.
     The main issue for that is the use of DELETE within multicast. It
might be useful to discuss such use?
     (in other words, is it possible to relax RFC 2370 recommendations for
the case of multicast).

     Alternatively, and inspired by the simple registration interface of
CoRE-RD, an RD might send a POST request with an
     empty body in order to emulate a DELETE. Such a request triggers the
removal of the RD registration from endpoints.
     With this alternative, the issue with RD template can be mitigated ?

> updates, which may arrive at devices that haev not seen the first

Thank you for raising this important issue. As a remedy, I can think of
three solutions:

1- Send all the information either in the first and the update.
   Cons: waste of resource although this might be acceptable, knowing the
infrequency of RD updates
   and the limited size of the registration resource.
   Pros: it solves all issues.

2- The new joining nodes SHOULD use DS to ask for the information from
neighbors upon joining
   The network. If this is not already done before getting the RD update
for the first time, the node SHOULD
   issue a DS to make sure that it has all the information. In this case,
only already-aware
   updated neighbors reply.
   Cons: It might not be available any already-aware neighbor in the
vicinity. In addition,
   this imposes for nodes to send DS even for the first received
registration. To avoid this latter, the RD
   might specify in the POSTed resource in a TBD attribute whether it is a
registration or an update.

3- In the third option, the node receiving an update, might directly
unicast the RD, to get the information.
   This has the same drawbacks as in 2. In addition, it might creates
   a burden on the RD if the number of simultaneous joiners is important.

I would prefer the first option. What do you think?

> Agree

>  Thank you for mentioning this draft, we are working to consider such
services and similar (e.g., Announce
    Available Groups for nodes to join)  for he next version of the draft

Best regards

All the best,
Badis