Change:
Lifetime (optional).  Lifetime of the registration in seconds. Range of 60-4294967295.  If no lifetime is included in the initial registration, a default value of 86400 (24 hours) <del> SHOULD be assumed.  If the lt parameter is not included in a registration refresh or update operation, the most recently supplied value SHALL be re-used. </del> <ins> SHOULD be assumed. </ins> Context (optional).  This parameter sets the scheme, address, port and path at which this server is available in the form

Discussion:
The mechanism is useful in updates, but at the registration interface they do not make sense. Closes: URL
According URL and below Therefore I'm not sure, if the explanation for the about the reuse of the most recently supplied value, just doesn't apply here (and may be moved to a more proper place), because this section is only about new or replacing registrations, or, if refresh or update registrations also apply to this section, somehow "extends" the behaviour of "replacing the registration parameters and links" (and may be therefore explicitly mentioned as exception in the "replacing the registration parameters and links, except the lifetime, where the below extra rule SHOULD be applied"). FMPOV, I don't see the use case, where a device sends a registration and the rd should use a previous lifetime without notice the device about that. The device would consider the default value, but, if the actual value would be smaller, the device will get unaware unregistered. An example for "supersede" case would therefore be also a good idea, to clarify, what is intended.
Hi Achim, I agree, we should remove the text about refresh from the description of new registrations, and it wil remove the confusion. Thanks! Michael
I agree: if a device re-registers by POSTing to the RD (rather than to its registration resource), it can often be the case that it has lost knowledge of its previous registration, so carrying defaults over from that would lead to misunderstandings. No other variables in the same section are affected by this issue. Pull-request with updated wording is pending; will merge it if no objections are brought up.
Thanks!
There is text in section 3.1 “Principles” of the RD draft that says… …snip…”it follows that no information should be stored in the resource directory that cannot be discovered from querying the described device's /.well-known/core resource directly.” This seems counter to the text in section 1 “Introduction”, which says… …snip…”These problems can be solved by employing an entity called a Resource Directory (RD), which hosts descriptions of resources held on other servers, allowing lookups to be performed for those resources.” Could the text in 3.1 be re-stated differently?
I'm note sure see the conflict; is it the "hosts", which could be read as being authority on and could be replaced with "mirrors"?

Or is it more about the query interfaces that are not present on the original devices?
NAME could you elaborate on that? I do not understand the conflict.
To be honest I am not sure what the issue was. I think that in a first read it gave the impression that the RD was the host of the resources instead of mirroring them. I'll close it.