Draft: draft-ietf-core-resource-directory

Commentary: The mechanism is useful in updates , but at the registration interface they do not make sense . Closes : 
 According and below Therefore I 'm not sure , if the explanation for the about the reuse of the most recently supplied value , just does n'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 do n'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 !  
 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 can not 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 ? 
 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 .
Paragraph (version A):
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)
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.
Paragraph (version B):
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)
SHOULD be assumed.