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

From: Alexey Melnikov <[email-masked]>
Date: Mon, 4 Nov 2019 17:06:45 +0000

Hi,

My apologies for the delay in reviewing this document:

Everywhere: header ==> header field (at least one instance in Section 5, 
there might be more)

In Section 3.7: the first mention of URN needs a reference.

In 4.1.1: RDAO type of 38 - IANA typically should be allowed to pick the 
next available value unless there was an early allocation. You should be 
prepared for this value to change.

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?

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 not limit the set of discovered
    URIs to those hosted at the address used for URI discovery.

In Section 5:

       ep :=  Endpoint name (mostly mandatory).  The endpoint name is an
          identifier that MUST be unique within a sector.  As the
          endpoint name is a Unicode string, it is encoded in UTF-8 (and
          possibly pct-encoding)

pct-encoding ==> pct-encoded

          during variable expansion (see [RFC6570]
          Section 3.2.1).

At the end of section 5:

    Req: POST /rd?ep=node1&base=http://[2001:db8:1::1] HTTP/1.1
    Host: example.com
    Content-Type: application/link-format
    Payload:
    </sensors/temp>;ct=41;rt="temperature-c";if="sensor",
    <http://www.example.com/sensors/temp>;
      anchor="/sensors/temp";rel="describedby"

This is not valid HTTP, I would rather you used a proper HTTP example. 
If you do, the line "Payload:" should be replaced with an empty line to 
separate payload from the header section.

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?

    for registrations that it did not create.  The registrations are
    resources of the RD.

In 5.3.1 on page 31:

typo: Service Unabailable ==> Service Unavailable

In 6.2, 5th para:

    Note that "href" is a valid search criterion and matches target
    references.  Like all search criteria, on a resource lookup it can
    match the target reference of the resource link itself, but also the
    registration resource of the endpoint that registered it. Queries
    for resource link targets MUST be in URI form (i.e. not relative

I think you means "absolute URI form" (relative reference is still a URI 
form)

    references) and are matched against a resolved link target. Queries
    for endpoints SHOULD be expressed in path-absolute form if possible
    and MUST be expressed in URI form otherwise;

"relative URI form" here?

    the RD SHOULD recognize
    either.

In 6.2:

       search :=  Search criteria for limiting the number of results
          (optional).

I think this is undespecified.

Can you give me an example?

In 6.4, 3rd para:

     in path-absolute form or, if required, as absolute references.

What is the difference between these two?

In 7.3:

    Assuming that the client is provided by a certificate
    at manufacturing time, the certificate is uniquely identified by the
    CN field and the serial number.

This probably needs a reference for CN/serial number.

In 9.3:

    o  validity requirements if any, and

Does this include syntax?

Also, should the list of fields include "reference to the document with 
more information"? (can be optional)

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?

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.

Best Regards,

Alexey

---

From: Klaus Hartke <[email-masked]>
Date: Mon, 4 Nov 2019 18:24:29 +0100

> Did you mean to say "absolute URIs"? Relative URIs are still URIs

After studying RFC 3986 for over a decade, my moment has come! I can
point out that someone is wrong on the Internet [1] ;-)

A relative URI reference is not a URI. Both URIs and relative
references are URI references [2]. And an absolute URI is a URI
without a fragment identifier [3].

Klaus

[1] https://xkcd.com/386/
[2] https://tools.ietf.org/html/rfc3986#section-4.1
[3] https://tools.ietf.org/html/rfc3986#section-4.3

---

From: Christian Amsüss <[email-masked]>
Date: Tue, 19 Nov 2019 13:57:33 +0100

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.

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

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

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

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

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

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

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 20 Nov 2019 06:12:35 +0800

> that mechanism for discovering the RD.

(With chair hat:)

I do not have the impression that we will have completion on rd-dns-sd soon; actually progress is pretty much stalled right now due to high load on everyone in the author team (which shrank recently), who tend to see rd-dns-sd as second priority.

(As a co-author of RD, so without a chair hat:)

I don’t see any alternative to removing anything that would create a normative reference.

Grüße, Carsten

---

From: Jaime Jiménez <[email-masked]>
Date: Wed, 20 Nov 2019 09:37:10 +0800

Hi,

of those comments that are to be discussed by the group, or that have to do 
with the shepherding, here are my quick thoughts before the core session. 

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

Sounds good to me.

> that mechanism for discovering the RD.

RD-DNS-SD would benefit a lot from a review by Kerry Lynn. At this point
of time I am not sure about who has deployed this component as I am not
familiar with all SDOs. If we place a normative reference we
might delay RD much further. So I agree with Christian on bringing this
to the group, explaining the implications. 

> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: "Alexey Melnikov" <[email-masked]>
Date: Wed, 20 Nov 2019 02:03:09 +0000

Hi Christian,

> This is referring to the existing .well-known/core discovery URI that is

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

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

> endpoints) and updating their registration is encouraged.

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

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

> be simple like "integer" (implying "ASCII encoded decimal integer").

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

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

I suggest this be moved to the shepherding wrtite up.

> 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