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

["Alexey Melnikov" <[e-mail]>]

Hi Christian,

On Tue, Nov 19, 2019, at 12:57 PM, Christian Amsüss wrote:
> 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.

I think you should update the above sentence to make this clear.

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

Ok, I will review my own comments and cross check the URI RFC. If I have any questions, I will about them separately.

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

More text along the lines of your answer would improve the document.

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

When I read the above I started to wonder where search criteria syntax is defined. I am still not entirely clear, so I think this needs to be clarified.

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

I suggest changing the above to "syntax and validity requirements if any, and"

> 
> > 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 suggest this be moved to the shepherding wrtite up.

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

The WG started to discuss whether this is truly normative. I am awaiting conclusion of this discussion.

Best Regards,
Alexey