Re: [core] AD review of draft-ietf-core-resource-directory-23

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

Hello Alexey,
hello CoRE,

thank you for your review. I'll only answer to points here that actually
need responses or further comments from the group. Everything else is
directly taken up as to be trivially fixed.

On Mon, Nov 04, 2019 at 05:06:45PM +0000, Alexey Melnikov wrote:
> In 4.3:
>   The well-known entry points SHOULD be provided to enable unicast
> discovery.
> 
> I don't see a new .well-known value being registered in the IANA
> Considerations section. Have I misintepreted what this mean?

This is referring to the existing .well-known/core discovery URI that is
heavily used in RD.

(The grouping of this requirement in the context of the section can be
improved still).


> In 4.3, 6th para:
> 
>    Clients of the RD
>    SHOULD therefore accept URIs of all schemes they support, both as
>    URIs and relative references,
> 
> Did you mean to say "absolute URIs"? Relative URIs are still URIs

(and later points on "absolute URI" / "relative URI")

Klaus answered that point very well.

We've had the "absolute URI" term in there for quite some time until
exactly what he said was pointed out; the wording should now be
consistent of "relative references" and "URIs", which are occasionally
annotate as "full URIs" to emphasise that relative references are not
meant. The term "path-absolute form" is taken from relative references'
ABNF, and I did not find any more commmon-language experssion for
"relative reference and not a URI", especially as more exotic forms like
"//host/path" are undesirable in those places as well.


> In 5.3, 1st para:
> 
>    This section describes how the registering endpoint can maintain the
>    registrations that it created.  The registering endpoint can be the
>    registrant-ep or the CT.  An endpoint SHOULD NOT use this interface
> 
> Why SHOULD NOT (instead of MUST NOT) and how is this enforced?

This is more expressing the intention than anything enforcable. Frankly,
it is a bit imprecise: The goal is to discourage any agents enumerating
registrations from the endpoint lookup and trying to enhance them.
Endpoints switching addresses (thus technically becoming different
endpoints) and updating their registration is encouraged.

There are some cases in the middle we probably don't want to rule out
but caution against, invoking "SHOULD"'s "know what you're doing" which
we may not want to rule out (but have not discussed).

In the end, enforcement is up to the security policy -- if an agent
knows a registration URI and has the authorization to act on it, that
will succeed.


> In 6.2:
> 
>       search :=  Search criteria for limiting the number of results
>          (optional).
> 
> I think this is undespecified.
> 
> Can you give me an example?

The description for this is above that interface description in the "A
link matches a search criterion if" paragraph.

Is your point about this being underspecified about the description as a
whole, or just about the discoverability of the text (which should be
easy to fix with something just a bit more elaborate than "(see above)"
note)?

Note that in the URI-Template, it says "search*", with the explode
modifier ("*") indicating that any otherwise unmatched query parameters
go into an associative array named "search".

The first two examples right after that section are "search" examples.
In the "/rd-lookup/res?rt=temperature" example, search is matched as a
[("rt", "temperature")] associative array.

> In 9.3:
> 
>    o  validity requirements if any, and
> 
> Does this include syntax?

If structured fields are registered, yes -- but I expect most entries to
be simple like "integer" (implying "ASCII encoded decimal integer").


> At the end of section 9.3:
>    It is expected that the registry will receive between 5 and 50
> registrations in total over the next years.
> 
> This will not age well! Maybe remove this text from the document and add it
> to the spherding write-up?

Doesn't this need to be in the requesting document, per BCP26's "It is
also a good idea to include, when possible, a sense of whether many
registrations are expected over time, or if the registry is expected to
be updated infrequently or in exceptional circumstances only."?

But if not, I'll remove the paragraph and alert Jaime as the shepherd.


> I think the following reference is Normative the way it is used in the
> document:
> 
>    [I-D.ietf-core-rd-dns-sd] Stok, P., Koster, M., and C. Amsuess, "CoRE
> Resource Directory: DNS-SD mapping", draft-ietf-core-rd-dns-sd-05 (work in
> progress), July 2019.

<personal>Oh please not</personal>.

I suppose this is due to "The use of DNS facilities is described in
[rd-dns-sd]" being listed as a recommended way, or are there more
aspects to it?

The DNS-SD component has been holding RD back quite a bit, so if it's that
recommendation, I assume the group might want to reconsider recommending
that mechanism for discovering the RD.


Kind regards
Christian

-- 
Yesterday is history, tomorrow is a mystery, and today is a gift. That
is why it is called the present.
  -- ancient saying