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

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

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.

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


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

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

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

Best regards
Christian

-- 
To use raw power is to make yourself infinitely vulnerable to greater powers.
  -- Bene Gesserit axiom