Re: [core] Warren Kumari's No Objection on draft-ietf-core-resource-directory-25: (with COMMENT)

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

(This is one of the point-to-point follow-up mails on the RD -25
reviews; for the preface, please see the preceding mail on "The various
positions on draft-ietf-core-resource-directory-25" at
<https://mailarchive.ietf.org/arch/msg/core/xWLomwwhovkU-CPGNxnvs40BhaM/>).


As COMMENT:

> Comments:
>
> 1: "These CTs are thought to act on behalf of endpoints too constrained, or
> generally unable, to present that information themselves. "
>
> This reads very oddly - "thought to act on" sounds like we've seen some of
> these in the wild, and only have a vague idea about how they work. Does
> "These CTs act on behalf of endpoints too constrained, or generally unable,
> to present that information themselves. " work?

response:

Yes that works. (Fixed in
https://github.com/core-wg/resource-directory/pull/301).

> 2: "From the system design point of view, the ambition is to design
> horizontal solutions that  can enable utilization of machines in different
> applications depending on their current availability and capabilities as well
> as application requirements, thus avoiding silo like solutions" - this is
> very buzzwordy, and I have no idea what it is actually trying to say...

response:

What it was trying to say was that parts of the complete system should not be
specific to an application. The sentence has been replaced with something that
is less keyword oriented and more descriptive.

(See https://github.com/core-wg/resource-directory/pull/302 for precise text).

> 3: "  A (re-)starting device may want to find one or more RDs for discovery
> purposes."
>
> Either I don't understand what this sentence is  trying to say, or "for
> discovery purposes" should be dropped.... 

response:

The intention here was to express that some host must be found before the
further URI discovery steps can take place. Enhanced in
https://github.com/core-wg/resource-directory/pull/301.

> 4: "As some of the RD addresses obtained by the methods listed here are just
> (more or less educated) guesses, endpoints MUST make use of any error
> messages to very strictly rate-limit requests to candidate IP addresses that
> don't work out. " What happens if device A discovers RD X, and device B
> discovers RD Y? Surely there has to be some sort of deterministic method so
> that one doesn't end up in a "split brain" type outcome? 

response:

There are various approaches that can apply depending on the actual application:

* In managed networks, care can be taken to not make multiple RDs discoverable.
* In larger setups, multiple RDs may be available but set up for federation as
  it is being explored in draft-amsuess-core-rd-replication
* RDs that are deployed without overarching coordination can opt for the
  Opportunistic Resource Directory approach that is being explored in
  draft-amsuess-core-resource-directory-extensions, where one RD yields to the
  other. The error handling steps in RD make that transition smooth.

But long story short, this draft does not attempt to solve them.

> Nits:
>
> 1: " The input to an RD is composed of links and the output is composed of
> links constructed from the information stored in the RD." While  true, this
> sentence doesn't actually communicate anything useful to the reader -- I'd
> suggest removing it from the Abstract (note that this is just a nit).

response:

There has been repeated confusion about what an RD stores, with people
understanding it to store resources. This sentence serves to visibly emphasise
that only links go in and out.

> 2: "The RD is primarily a tool to make discovery operations more efficient
> than querying /.well-known/core on all connected devices, or across
> boundaries that would be limiting those operations."
>
> s/would be limiting those/that would limit those/

response:

Fixed in https://github.com/core-wg/resource-directory/pull/253.