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

[Badis Djamaa <[e-mail]>]

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

On Tue, 9 Apr 2019 at 11:41, Christian Amsüss <[e-mail]> wrote:

> 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
> >  "coap://[6LBR]/.well-known/core?rt=core.rd*".
>
> 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
> >   the RD draft )?
>
> 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.
>

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.


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

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

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?

>
> > >   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).
> >
> >   [...] 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
>
> Agree

> > * [...] 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
> >  please indicate some key services that need to be announced.
>
> 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
>
>  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
> Christian
>
> --
> To use raw power is to make yourself infinitely vulnerable to greater
> powers.
>   -- Bene Gesserit axiom
>

All the best,
Badis