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

From: Robert Wilton via Datatracker <[email-masked]>
Date: Thu, 13 Aug 2020 05:44:43 -0700

Robert Wilton has entered the following ballot position for
draft-ietf-core-resource-directory-25: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-core-resource-directory/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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

---

From: Barry Leiba <[email-masked]>
Date: Thu, 13 Aug 2020 09:03:20 -0400

> configuration, if it is not large.

"MAY NOT" is not a BCP 14 key word, and isn't a clear phrasing anyway.
The way to downgrade the strength here is to change "SHOULD NOT" to
"should not".

But keep in mind that this stuff is intended for constrained
environments, and it might be more important than you think to keep
message sizes down to a minimum.  That's the reason for the BCP 14
"SHOULD NOT".

Barry

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 13 Aug 2020 13:43:36 +0000

Hi Barry,

> -----Original Message-----
> From: Barry Leiba <[email-masked]>
> Sent: 13 August 2020 14:03
> To: Rob Wilton (rwilton) <[email-masked]>
> Cc: The IESG <[email-masked]>; [email-masked];
> Jaime Jiménez <[email-masked]>; [email-masked]; core-
> [email-masked]; core WG <[email-masked]>
> Subject: Re: Robert Wilton's No Objection on draft-ietf-core-resource-
> directory-25: (with COMMENT)
> 
[RW] 

Yes, sorry, I was trying to get the comments in before the telechat.

I still think that "should not" is probably a bit strong in the case that say the client is a commissioning tool.  Perhaps make the constraint conditional on whether an endpoint is doing the update?

Whilst looking at this a second time, it was a bit unclear to me whether using a "commissioning tool" is a one off thing (as could be implied by its name), or whether it would also periodically update the resource directory (to stop the registration entries from eventually timing out)?

> message sizes down to a minimum.  That's the reason for the BCP 14
[RW] 

Yes, but is a commissioning tool also similarly constrained?  I was assuming that it was the endpoint devices and the network access to those endpoint devices that was most likely to be constrained.

Regards,
Rob

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 13 Aug 2020 11:12:42 -0700

> registration to timeout (which could be a long time)?

Generally the authorization information in the certificate is just stored
in the subject (i.e., subjectAltName) of the certificate, so a new
certificate for the same name would pass the same authorization checks
(i.e., be "equivalent credentials").

-Ben

---

From: "Rob Wilton (rwilton)" <[email-masked]>
Date: Thu, 13 Aug 2020 18:18:42 +0000

Ben, 

Thank you for the clarification/explanation.

Regards,
Rob

> From: Benjamin Kaduk <[email-masked]>
> Sent: 13 August 2020 19:13
> [email-masked]; [email-masked]; [email-masked];
> [email-masked]