{"action":"created","issue":{"url":"https://api.github.com/repos/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues/115","repository_url":"https://api.github.com/repos/OpenMobileAlliance/OMA_LwM2M_for_Developers","labels_url":"https://api.github.com/repos/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues/115/labels{/name}","comments_url":"https://api.github.com/repos/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues/115/comments","events_url":"https://api.github.com/repos/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues/115/events","html_url":"https://github.com/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues/115","id":159594129,"number":115,"title":"Queue mode and notifications","user":{"login":"jvermillard","id":899073,"avatar_url":"https://avatars.githubusercontent.com/u/899073?v=3","gravatar_id":"","url":"https://api.github.com/users/jvermillard","html_url":"https://github.com/jvermillard","followers_url":"https://api.github.com/users/jvermillard/followers","following_url":"https://api.github.com/users/jvermillard/following{/other_user}","gists_url":"https://api.github.com/users/jvermillard/gists{/gist_id}","starred_url":"https://api.github.com/users/jvermillard/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jvermillard/subscriptions","organizations_url":"https://api.github.com/users/jvermillard/orgs","repos_url":"https://api.github.com/users/jvermillard/repos","events_url":"https://api.github.com/users/jvermillard/events{/privacy}","received_events_url":"https://api.github.com/users/jvermillard/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/OpenMobileAlliance/OMA_LwM2M_for_Developers/labels/P0","name":"P0","color":"f9d0c4"}],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":8,"created_at":"2016-06-10T09:24:27Z","updated_at":"2016-08-15T08:07:08Z","closed_at":null,"body":"In the spec under the \"Queue Mode Operation\" paragraph:\r\n\r\n> When the LWM2M Server receives a message from the Client (e.g. a notification or a registration update), it checks its request queue for the LWM2M Client and performs the needed CoAP operation(s) (e.g. GET, PUT, and POST).\r\n\r\nSo does a notification without a registration update is allowed in queue mode?\r\nIn the example figure there is a registration update before the notification, but the previous paragraph let us think it's allowed to send a notification without a registration update.\r\n\r\nThere is two way to implement it:\r\n - do a registration update when the device wakes up for sending the notification, i.e. the device sends a registration update once before it starts sending one or more notification\r\n - device wakes up and immediately sends the notifications at will, and the server is free to consider the device is online and updates the registration lifetime and ip address.\r\n"},"comment":{"url":"https://api.github.com/repos/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues/comments/239749379","html_url":"https://github.com/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues/115#issuecomment-239749379","issue_url":"https://api.github.com/repos/OpenMobileAlliance/OMA_LwM2M_for_Developers/issues/115","id":239749379,"user":{"login":"boaks","id":10937819,"avatar_url":"https://avatars.githubusercontent.com/u/10937819?v=3","gravatar_id":"","url":"https://api.github.com/users/boaks","html_url":"https://github.com/boaks","followers_url":"https://api.github.com/users/boaks/followers","following_url":"https://api.github.com/users/boaks/following{/other_user}","gists_url":"https://api.github.com/users/boaks/gists{/gist_id}","starred_url":"https://api.github.com/users/boaks/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/boaks/subscriptions","organizations_url":"https://api.github.com/users/boaks/orgs","repos_url":"https://api.github.com/users/boaks/repos","events_url":"https://api.github.com/users/boaks/events{/privacy}","received_events_url":"https://api.github.com/users/boaks/received_events","type":"User","site_admin":false},"created_at":"2016-08-15T08:07:08Z","updated_at":"2016-08-15T08:07:08Z","body":"> If the LWM2M server receives a DTLS / TLS record layer packet with a changed IP address and port then such a packet will be rejected since there is no other information in the header to find the appropriate security context.\r\n\r\nSure. therefore, if your usage is faced a potential endpoint change, any endpoint may set up a \"last communication timeout\" (say 30s) and, if that expires, a \"DTLS resume\" is required to ensure, that the CoAP reponse / Notify reaches the destination.\r\n\r\nBy the way, this then violates CoAP RFC 7252, 9.1.2 Request / Reponse layer\r\n\r\n> The following rules are added for matching a response to a request:\r\n> The DTLS session MUST be the same, and the epoch MUST be the same.\r\n \r\nMy personal conclusion at that point is:\r\n- RFC 7641 is more \"extending the lifetime of a request\" to a few minutes, \r\n   if changes are reported very frequently (e.g. progress indicator).\r\n- It's NOT usable for a general reporting, especially with long silent periods (sleeping devices)\r\n- Therefore it may be required to add a new \"LWM2M interface\" (similar to \"registration\") for less frequently events.\r\n "}}
{"actor":{"display_login":"boaks"}}