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

[Warren Kumari <[e-mail]>]

[ Top post...]

Thank you!
W
On Tue, Nov 3, 2020 at 12:34 PM Christian Amsüss <[e-mail]> wrote:
>
> (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.



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf