Subject: [core] WGLC observe comment: notification transmission

From: "Kovatsch Matthias" <[email-masked]>
Date: Sun, 27 Oct 2013 13:34:33 +0000

Dear list

During the discussion on supersedure, I noticed that step 1 is written for CON and NON notifications, the remaining steps only apply for CON (2: rejected NON notifications are not required to remove a client from the list of observers; 3: supersedure makes only sense for CON; 4: retransmissions do not apply for NONs).

Step 4 of 4.5. implicitly requires to send the new notification as CON when the change occurred during an ongoing CON transmission. For eventual consistency this makes sense, but I am not sure whether this was explicitly intended. Should we maybe make it clearer and also state that the MID must be preserved for supersedure (currently only retransmission count and timeout are mentioned)? My proposed text (draft):

   2.  If a Confirmable transmission is rejected or the transmission was
       the last attempt to deliver a notification, the server MUST remove
       the associated entry from the list of observers of the observed
       resource. If a Non-confirmable transmission is rejected, the server
       MAY remove the associated entry.

[BTW: What happened to removing all entries of a client, if a CON transmission times out completely?]

    3.  If the entry is still in the list of observers, the server MAY
       update a Confirmable notification with the new representation
       of the current resource state and corresponding sequence
       number.  Should the resource have changed its state more
       than once in the meantime, the notifications for the
       intermediate states are silently skipped.

   4.  If the completed transmission attempt timed out, increment the
       retransmission counter and double the timeout, but keep the MID
       for the new transmission as described in Section 4.2 of RFC XXXX
       [I-D.ietf-core-coap].

   5. If a Confirmable transmission was acknowledged, send the new
       resource state as new Confirmable notification [with reinitialized
       retransmission counter and timeout.]

Ciao
Matthias

---

From: "Peter A. Bigot" <[email-masked]>
Date: Sun, 27 Oct 2013 11:15:33 -0500

On 10/27/2013 08:34 AM, Kovatsch Matthias wrote:
> Dear list
>
> During the discussion on supersedure, I noticed that step 1 is
> written for CON and NON notifications, the remaining steps only apply
> for CON (2: rejected NON notifications are not required to remove a
> client from the list of observers; 3: supersedure makes only sense
> for CON; 4: retransmissions do not apply for NONs).

I'd like to pause here and note that "supersedure" as I have been using 
the term didn't mean what you mean in this topic.  I've started new 
topic to expose that question.

>
> Step 4 of 4.5. implicitly requires to send the new notification as
> CON when the change occurred during an ongoing CON transmission. For
> eventual consistency this makes sense, but I am not sure whether this
> was explicitly intended. Should we maybe make it clearer and also
> state that the MID must be preserved for supersedure (currently only
> retransmission count and timeout are mentioned)? My proposed text
> (draft):
>
> 2.  If a Confirmable transmission is rejected or the transmission
> was the last attempt to deliver a notification, the server MUST
> remove the associated entry from the list of observers of the
> observed resource. If a Non-confirmable transmission is rejected, the
> server MAY remove the associated entry.
>

A little more precision would fix this.  Technically, the "list of 
observers" contains "observers" (which are defined as clients, which are 
destination endpoints for notifications), not entries (which don't have 
a distinct name but presumably associate a token with the client).  The 
"list of observers" is itself attached to a specific resource.

It is unclear whether failure to deliver a notification for one resource 
to a specific client should affect other resources.  Absent anything 
explicit, I would expect it would not.  (Keep in mind that unless things 
change the requirements imposed by step 2 only apply to notifications 
where the resource changes during transmission, which one would expect 
to be a rare case.)

> update a Confirmable notification with the new representation of the
> current resource state and corresponding sequence number.  Should the
> resource have changed its state more than once in the meantime, the
> notifications for the intermediate states are silently skipped.
>
> retransmission counter and double the timeout, but keep the MID for
> the new transmission as described in Section 4.2 of RFC XXXX
> [I-D.ietf-core-coap].

IMO this, along with the bracketed and incomplete gloss in step 5, is 
repeating details, which risks inconsistency.  Instead it should 
incorporate the required behavior by reference to existing concepts like 
what a message is and what confirmable transmission of it is.  But I'm 
just going to back away from that aspect of the discussion now.

> Ciao Matthias _______________________________________________ core
> mailing list [email-masked]
> https://www.ietf.org/mailman/listinfo/core
>