Constrained RESTful Environments (CoRE) Resource Directory
draft-ietf-core-resource-directory-28

[[ comments ]]

Clearing my discuss from -25.  Thanks for the thoughtful feedback.

[ section 4.1.1 ]

* I just thought of one thing that might help save some RA space:

In the case (perhaps not the common case) there the RDAO IPv6 address is the same as the source address of the RA itself, the length field could be just 1 and the IPv6 address field omitted.

I don't think this complicates parsing too much -- the length is either 3 => address included or 1 => address is the RA source address (a link-local address).

I'll leave it up to the group to consider whether this is a useful optimisation or not.  Perhaps this idea has already been considered and rejected, though.

I concur with my colleagues who commended the authors for making the document very readable.

I support Roman's first two DISCUSS points.

In Section 9.2, you might want to mention that you're talking about a sub-registry under "Internet Control Message Protocol version 6 (ICMPv6) Parameters".

In Section 9.3, you enumerate six fields in each registration, but the initial table of entries has only five columns.  It's obvious (I think) that the sixth column would be "this document" for all entries, but I suggest that you should either include the column or some prose making this explicit (since everything else is).

Thanks for addressing my DISCUSS and COMMENT feedback.

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/

Thank you for the work put into this document. As you can noticed, I have cleared my 2 DISCUSS points (kept below for archive) thank you also for replying to my comments over email.

BTW, I appreciated the use of ASCII art to represent an entity-relationship diagram !

I hope that this helps to improve the document,

Regards,

-éric

== cleared DISCUSS (no more blocking, kept for history) ==

-- Section 4.1 --
It will be trivial to fix, in IPv6 address configuration (SLAAC vs. DHCP) is orthogonal to DHCP 'other-information'. E.g., even if address is configured via SLAAC, DHCPv6 other-information can be used to configure the Recursive DNS Server (or possibly the RD).

-- Section 4.1.1 --
Another trivial DISCUSS to fix: in which message is this RDAO sent ? I guess unicast Router Advertisement but this MUST be specified.== COMMENTS ==

In general, I wonder how much interactions and exchanges of ideas have happened in the long history of this document with the DNSSD (DNS Service Discovery) Working Group that has very similar constraints (sleeping nodes) and same objectives.

-- Section 2 --
To be honest: I am not too much an APP person; therefore, I was surprised to see "source address (URI)" used to identify the "anchor="... I do not mind too much the use of "destination address (URI)" as it is really a destination but the anchor does not appear to me as a "source address". Is it common terminology ? If so, then ignore my COMMENT, else I suggest to change to "destination URI" and simply "anchor" ?

-- Section 3.3 --
Should the lifetime be specified in seconds at first use in the text?

-- Section 3.6 --
Is the use of "M2M" still current? I would suggest to use the word "IoT" esp when 6LBR (assuming it is 6LO Border Router) is cited later.

Please expand and add reference for 6LBR.

Using 'modern' technologies (cfr LP-WAN WG) could also add justification to section 3.5.

-- Section 4.1 --
About "coap://[MCD1]/.well-known/core?rt=core.rd*", what is the value of MCD1 ? The IANA section discuss about it but it may help the reader to give a hint before (or simply use TBDx that is common in I-D).

Any reason to use "address" rather than "group" in "When answering a multicast request directed at a link-local address" ?

Later "to use one of their own routable addresses for registration." but there can be multiple configured prefixes... Which one should the RD select ? Should this be specified ?

As a co-author of RFC 8801, I would have appreciated to read PvD option mentionned to discover the RD. Any reason why PvD Option cannot be used ?

-- Section 4.1.1 --
I suggest to swap the reserved and lifetime fields in order to be able to use a lifetime in units of seconds (to be consistent with other NDP options).

-- Section 5 --
May be I missed it, but, can an end-point register multiple base URI ? E.g., multiple IPv6 addresses.

-- Section 9.2 --
For information, value 38 is already assigned to RFC 8781.



== NITS ==

-- Section 2 --
The extra new lines when defining "Sector" are slighly confusing. Same applies to "Target" and "Context". This is cosmetic only.

Please respond to the Gen-ART review.

Thanks for the updates in the -26; they help a lot.

I'm particularly happy to see the (default/example)
"first-come-first-remembered" policy in § 7.5, which does a good job of
documenting its properties (including potential deficiencies) and can be
usable for many environments.  (I do have some suggestions for
improvements to the specific wording in the section-by-section comments,
but on the whole I like it.)

It does lead in to a more general comment, though (which is not exactly
new to the changes in the -26 though it is reflected in several of
them): some aspects of the concept of "authorization" to appear in a
directory, and the verification of authorization for the entire flow
from client locating the RD server to final request at the discovered
resource, are somewhat subtle.  (The new text discusses, e.g., "repeat
the URI discovery step at the /.well-known/core resource of the
indicated host to obtain the resource type information from an
authorized source" and "a straightforward way to verify [discovered
information] is to request it again from an authorized server, typically
the one that hosts the target resource".)  The aspects I'm concerned
about are not matters of a resource server being authorized to publish
to a directory or a client deeming that a server is authorized to act as
an RD (though both of those are also important), but seems to rather
just be relating to the RD faithfully disseminating the information the
RD retrieved from /.well-known/core discovery on the given server(s)
(or otherwise learned via some other mechanism).
In this sense the RD is just acting as a cache or efficiency aid, but
the authoritative source of the information remains (in general) the
server hosting the resource.  To be clear, I think the procedures that
this document specifies are good and correct procedures for a client to
perform, I'm just not sure whether "authorized" is the right term in
these cases; "authoritative" might be more appropriate, in that the
operation in question is to verify the information retrieved from the RD
(which acts in some sense as an intermediary) at the more authoritative
source.

(On a tangent from that note, it seems that there is not necessarily any
indication to a client that a server claiming to provide a given
resource (whether discovered via RD or /.well-known/core) is actually
authorized to provide such a resource and be trusted by the client.  But
that's not really a property of RD, and rather the underlying CoRE
mechanism and any provisioned trust database, so my thoughts about it
seem out of scope for this document.)

Section 5.1

   URI Template Variables are as they are for registration in Section 5.
   The base attribute is not accepted to keep the registration interface
   simple; that rules out registration over CoAP-over-TCP or HTTP that
   would need to specify one.  For some time during this document's
   development, the URI template "/.well-known/core{?ep,...}" has been
   in use instead.

(It's not entirely clear to me what the reader is expected to do with
the information about the previous formulation.)

Section 7.3

   In this case, the endpoint (and not the lookup clients) needs to be
   careful to check the RD's authorization.

(It seems that something also needs to cause the RD to check the
authorization of lookup clients to receive the information in question,
which might be worth reiterating in this section.)

Section 7.5

   *  If the client's credentials indicate any subject name that is
      certified by any authority which the RD recognizes (which may be
      the system's trust anchor store), all those subject names are
      stored.  [...]

I'm pretty sure the intent here is that only the subject names that are
certified by the recognized authority(ies) are stored, in which case I'd
suggest to s/all those/all such/.

      With X.509 certificates, the Common Name (CN) and the complete
      list of SubjectAltName entries are stored.  In both cases, the
      authority that certified the claim is stored along with the
      subject, as the latter may only be locally unique.

(I can understand why the "store the whole list" logic is used, though
there may be some subtleties about name constraints on the (X.509) CAs
used, which is why we typically don't recomment treating the entire list
of names in the certificate as validated from a single operation,
instead preferring "is this certificate authenticated for this specific
name?" when the specific target name is available.)

   *  If neither is present, a reference to the security session itself
      is stored.  With (D)TLS, that is the connection itself, or the
      session resumption information if available.  With OSCORE, that is
      the security context.

Should we talk about whether the lifetime of registration entries is
related to the various lifetimes of these credentials/identifiers?  DTLS
without resumption is perhaps an interesting case, in that keeping the
DTLS association "live" just to be able to update the registration
information seems impractical, so perhaps some fixed cap would be
applied on the lifetime in that case.  If resumption is used, the
resumption information (ticket or session state) has some finite
lifetime that could be used to bound the lifetime of the registration.
IIRC an OSCORE security context can also have an expiration time;
certificates and JWT/CWT have expiration time as well (though the
procedures in the first bullet point would effectively allow a "renewal"
operation), but the validity period (if any) of a raw public key would
have to be provisioned along with that key (or just have RPK be handled
akin to DTLS without resumption, I guess).

   Any operation on a registration resource, including registrations
   that lead to an existing registration resource, MUST be rejected by
   the RD unless all the stored information is found in the new
   request's credentials.

(Similar to my earlier parenthetical comment, the requirement for exact
match of all subject name information is unusual.  In effect this is a
way of pinning the set of names that the CA has chosen to include in a
single certificate, which is arguably a stronger requirement than needed
but should not lead to any unauthorized access.)

This document was particularly easy to follow and presented ideas in a sensible order.

One nit: the sentence that contains “cannot be executed as a base attribute” appears to have been mangled.

Hi,

Thank you for this document.

I'm glad that the shepherd's writeup indicates that there are implementations since that indicates that there does appear to be value in standardizing this work, despite its long journey.

My main comment (which I was considering raising as a discuss) is:

Since this document is defining a new service, I think that this document would benefit on having a short later section on "Operations, Administration and Management".  This document does seem to cover some management/administration considerations in various sections in a somewhat ad hoc way, but having a section highlighting those would potentially make it easier deploy.  Defining a common management model (or API) would potentially also make administration of the service easier, I don't know if that had been considered, and if useful could be done as a separate document.

A few other comments:

    5.3.  Operations on the Registration Resource

       An endpoint should not use this interface for registrations that it
       did not create.  This is usually enforced by security policies, which
       in general require equivalent credentials for creation of and
       operations on a registration.

What happens if an endpoint is managing the registration and is upgraded to new hardware with a different certificate?  Would the updated endpoint expect to be able to update the registration?  Or would it have to wait for the existing registration to timeout (which could be a long time)?

    5.3.  Operations on the Registration Resource

       The Registration Resource may also be used cancel the registration
       using DELETE, and to perform further operations beyond the scope of
       this specification.

       These operations are described below.
   
Nit: Perhaps reword the second sentence.  Otherwise it seems to conflict with the last sentence of the prior paragraph.

    5.3.1.  Registration Update

       The update interface is used by the registering endpoint to refresh
       or update its registration with an RD.  To use the interface, the
       registering endpoint sends a POST request to the registration
       resource returned by the initial registration operation.

       An update MAY update the lifetime or the base URI registration
       parameters "lt", "base" as in Section 5.  Parameters that are not
       being changed SHOULD NOT be included in an update.  Adding parameters
       that have not changed increases the size of the message but does not
       have any other implications.  Parameters MUST be included as query
       parameters in an update operation as in Section 5.

The "SHOULD NOT" feels a bit strong to me, and I would prefer to see this as "MAY NOT".  In many cases, if the configuration is not too big then providing the full configuration makes it easy to guarantee that the receiver has exactly the correct configuration.  I appreciate that there are many cases where from an endpoint perspective it may want to keep the update small, but if I was doing this from a CT, I think that I would rather just resend the entire configuration, if it is not large.

    5.3.1.  Registration Update

       Req: GET /rd-lookup/res?ep=endpoint1

       Res: 2.05 Content
       Payload:
       <coap://local-proxy-old.example.com:5683/sensors/temp>;ct=41;
           rt="temperature-c";if="sensor";
           anchor="coap://local-proxy-old.example.com:5683/",
       <http://www.example.com/sensors/temp>;
           anchor="coap://local-proxy-old.example.com:5683/sensors/temp";
           rel="describedby"

           Figure 14: Example lookup before a change to the base address

Just to check, is it correct that the anchor in the http link is also to coap://?  If this is wrong then there is a second example in the same section that also needs to be fixed.        
       
Regards,
Rob