Original text:
resource returned by the initial registration operation. An update MAY update registration parameters like lifetime, base URI <del> or others.  Parameters that are not being changed SHOULD NOT be </del>  included in an update.  Adding parameters that have not changed increases the size of the message but does not have any other <del> implications.  Parameters MUST be included as query parameters in an </del>  update operation as in registration. A registration update resets the timeout of the registration to the

Reviewer comments:
The SHOULD is not an interoperability requirement but a quality-of-implementation level recommendation; the MUST could have been read as a requirement to have parameters there and is more describing mechanism than compatibility. See-Also: URL 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: 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)? Nit: Perhaps reword the second sentence.  Otherwise it seems to conflict with the last sentence of the prior paragraph. 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. 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.

Revised text:
resource returned by the initial registration operation. An update MAY update registration parameters like lifetime, base URI  <ins> or others.  Parameters that are not being changed should not be </ins> included in an update.  Adding parameters that have not changed increases the size of the message but does not have any other  <ins> implications.  Parameters are included as query parameters in an </ins> update operation as in registration. A registration update resets the timeout of the registration to the