Unified handling of multiple responses #107
Conversation
marco-tiloca-sics
changed the title
draft-ietf-core-oscore-groupcomm.md
Outdated
|
|
||
| * Long exchange: an exchange of messages associated with a request that is a group request and/or an Observe request {{RFC7641}}. | ||
|
|
||
| More formally, the request associated with a long exchange is: a group request, irrespective of it being an Observe request; or an Observe request, irrespective of it being a group request. | ||
|
|
There was a problem hiding this comment.
Do we need the paragraph "More formally, ..."?
There was a problem hiding this comment.
Not necessarily, it can be removed.
draft-ietf-core-oscore-groupcomm.md
Outdated
| This ensures that: i) an Observe notification {{RFC7641}} can never successfully match against the Observe requests of two different observations; and ii) a non-notification response can never successfully match against the group requests of two different Non-Notification Group Exchanges. In fact, the excluded elder members would eventually re-join the group, thus terminating any of their ongoing (long-lasting) observations (see {{sec-long-term-observations}}) and Non-Notification Group Exchanges (see {{sec-replay-protection-non-notifications}}). | ||
| This ensures that any response from the same server to the request of a long exchange can never successfully match against the request of two different long exchanges. | ||
|
|
||
| In fact, the excluded elder members would eventually re-join the group, thus terminating any of their ongoing long exchanges (see {{sec-long-exchanges}}). |
There was a problem hiding this comment.
Why "would" the elder member eventually re-join? Is it necessarily so, or should it be "could"?
There was a problem hiding this comment.
"could" is fine
draft-ietf-core-oscore-groupcomm.md
Outdated
|
|
||
| A client receiving a non-notification response to a group request containing a Partial IV SHALL compare the Partial IV with the Response Number associated with the replying server within the ongoing Non-Notification Group Exchange. The client MUST stop processing non-observation responses to a group request from a server, if those have a Partial IV that has been previously received before from that server within the Non-Notification Group Exchange. Applications MAY decide that a client only processes non-notification responses to a group request if those have a greater Partial IV than the Response Number associated with the replying server within the ongoing Non-Notification Group Exchange. | ||
| During a long exchange, a client receiving a response containing a Partial IV SHALL compare the Partial IV with the Response Number associated with the replying server within that long exchange. The client MUST stop processing responses from a server, if those have a Partial IV that has been previously received from that server during that long exchange, while using the same Security Context. Applications MAY decide that a client only processes responses within a long exchange if those have a greater Partial IV than the Response Number associated with the replying server within that long exchange. |
There was a problem hiding this comment.
OLD
The client MUST stop processing responses from a server, if those have
NEW
The client MUST stop processing responses from a server, if a response has
There was a problem hiding this comment.
Even better:
NEW:
The client MUST stop processing a response from a server, if that response has
|
|
||
| Upon leaving the group or before re-joining the group, a group member MUST terminate all the ongoing long exchanges that it has started in the group as a client, and hence frees up the CoAP Token associated with the corresponding request. |
There was a problem hiding this comment.
Why leave a choice to do it upon leaving, or before re-joining? It may be simpler to limit it to one case: "upon leaving the group"
There was a problem hiding this comment.
It is not a choice.
"re-join" has been used in previous sections to denote a current group member that does not leave the group but sends a new Join Request to the Group Manager for obtaining a new Sender ID etc. In that case, there is no leaving to refer to.
If, instead, there is a leaving (irrespective of joining the group again or not after that), that's when the endpoint does what is described in the quoted text.
draft-ietf-core-oscore-groupcomm.md
Outdated
| * For requests and notifications, the received Partial IV allows a recipient to determine the relative order of requests or responses. | ||
|
|
||
| This applies also to non-notification responses: | ||
| If the request was neither a group request nor an Observe request, there is at most a single response and only from one, individually targeted server in the group. Thus, freshness can be assessed depending on when the request was sent. |
There was a problem hiding this comment.
Considering the discovery method described in the end of "Message Processing in Pairwise Mode", and in "Pre-Conditions", can it make more sense to say one of the following?
there is at most a single valid response and only from one
or
there is at most a single protected response and only from one
There was a problem hiding this comment.
Yes, it's definitely only about a valid response. The first option looks good to use.
there is at most a single valid response and only from one ...
|
|
||
| * The server MUST store the value of the 'kid' parameter from the group request, and retain it until the last non-notification response has been sent. The server MUST NOT update the stored value of a 'kid' parameter associated with a particular group request, even in case the client is individually rekeyed and starts using a new Sender ID received from the Group Manager (see {{new-sender-id}}). | ||
| In addition, the following applies if the request establishes a long exchange and the server intends to reply with multiple responses. |
There was a problem hiding this comment.
Seems to be repeating very similar text from line 1254
There was a problem hiding this comment.
Correct, the previous paragraph (quoted below) should have been deleted, keeping only the paragraph in the comment.
In addition, the following applies if the server intends to reply with multiple responses, within the long exchange established by the corresponding request.
draft-ietf-core-oscore-groupcomm.md
Outdated
| @@ -1372,59 +1325,36 @@ Note that a client may receive a response protected with a Security Context diff | |||
|
|
|||
| The client verifies the original countersignature SIGNATURE. | |||
|
|
|||
| - If the verification of the countersignature fails, the client: i) SHALL stop processing the response; ii) SHALL NOT update the Response Number associated with the server, if the response is a non-notification response to a group request; and iii) SHALL NOT update the Notification Number associated with the server, if the response is an Observe notification {{RFC7641}}. | |||
| - If the verification of the countersignature fails, the client: i) SHALL stop processing the response; and ii) SHALL NOT update the Response Number associated with the server, if the response is received within a long exchange. | |||
There was a problem hiding this comment.
The last sentence is perhaps correct, but gives the impression that response number can be updated if the response is not received within a long exchange. How about
NEW
- If the verification of the countersignature fails, the client: i) SHALL stop processing the response; and ii) SHALL NOT update the Response Number associated with the server.
There was a problem hiding this comment.
I got the impression when reading through that there are other instances of redundant "in case of long exchange", I'll try to find them.
There was a problem hiding this comment.
Addressed in f36e4ce
No description provided.