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

["Rob Wilton (rwilton)" <[e-mail]>]

Hi Barry,

> -----Original Message-----
> From: Barry Leiba <[e-mail]>
> Sent: 13 August 2020 14:03
> To: Rob Wilton (rwilton) <[e-mail]>
> Cc: The IESG <[e-mail]>; [e-mail];
> Jaime Jiménez <[e-mail]>; [e-mail]; core-
> [e-mail]; core WG <[e-mail]>
> Subject: Re: Robert Wilton's No Objection on draft-ietf-core-resource-
> directory-25: (with COMMENT)
> 
> >     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.
> 
> "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".
[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)?


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

> 
> Barry