Re: [core] Robert Wilton's No Objection on draft-ietf-core-resource-directory-25: (with COMMENT)

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

(This is one of the point-to-point follow-up mails on the RD -25
reviews; for the preface, please see the preceding mail on "The various
positions on draft-ietf-core-resource-directory-25" at
<https://mailarchive.ietf.org/arch/msg/core/xWLomwwhovkU-CPGNxnvs40BhaM/>).


As COMMENT:

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

response:

The wide variety of possible deployments and associated security policies make
it hard to say anything generic on operations. We did, however, add an
exemplary and potentially default security model (based on Ben's suggestion, in
https://github.com/core-wg/resource-directory/issues/258).

The configuration options for such an RD are listed at its end (since
https://github.com/core-wg/resource-directory/pull/303), but how to
set them is out of scope here. (CORECONF would be a good candidate, but too
little exploration has gone into RD configuration using that yet to warrant a
reference).

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

response:

Certificates are not compared by literal comparison of the certificate, but by
whether their claims are sufficient for the resource (which in the end
establish an identity).

With unmanaged setups like the newly introduced First-Come-First-Remembered
policy, a device with a new certificate might become uneligible for accessing
its previous registration resource (and likewise for reregistering with the
same endpoint name and sector), but in such a setup the endpoint is prepared to
switch names anyway when it comes up with the new certificate. (Although it
should rarely come to that -- when the certificate is updated with the same
subject claims by an authority the RD recognizes, the new one is good for
continuation).

In managed setups, it is up to the managers to configure EPs with certificates
matching their endpoint names, and when the name does not change, the new
certificate is good for continuation as well.

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

response:

This has been resolved (in https://github.com/core-wg/resource-directory/pull/253).

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

response:

This is indeed not a compatibility but a quality-of-implementation
recommendation, and was changed to a lower-case 'should not' (in
https://github.com/core-wg/resource-directory/pull/304).

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

response:

This is correct. The link's context was originally </sensors/temp> relative to
the endpoint's base, and while this is being changed from
<coap://local-proxy-old.e.c> to <coaps://new.e.c>, the link always points from
the resource on the EP to the description hosted on HTTP.