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

From: Warren Kumari via Datatracker <[email-masked]>
Date: Tue, 11 Aug 2020 12:27:07 -0700

Warren Kumari has entered the following ballot position for
draft-ietf-core-resource-directory-25: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you -- I found this document to be a very friendly read. The Terminology
section in particular was one of the best in recent memory.

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?

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

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

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?

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

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/