Hi Marco, Thanks a lot for your review!
We have addressed your comments and adopted most of your suggestions in the latest version -03.
Please see below detailed replies to your comments. Thanks again! Best, /Marco On 2022-08-29 14:28, Marco Rasori wrote:
Hi all, Please, see below my comments to -02. Best, Marco [Section 5]* In Section 5.1, the steps from 1 to 6 show the actions performed by the Authorization Server each time the TRL changes. I suggest to complete the list of actions by adding a last step saying something like this:7. The Authorization Server notifies the observers with a response compliant to their original request. It can be either a diff query or a diff query with 'cursor'.
==>MTWe haven't changed this, in order to not restate what defined elsewhere. If Observe is used, then what is described in the third paragraph of Section 4.5 of RFC 7641 applies here just as well.
The focus of Section 5.1 of this document is about the update of the update collection, following an update to the TRL resource.
As per Section 4.5 of RFC 7641, the Authorization Server should still have a good latitude in determining the exact transmission of Observe notifications.
The same logic applies for observations started with a full query request instead.
<==
[Section 7]* In Figure 7, would it be worth specifying that the Authorization Server producing the response does not support the "Cursor" extension? It has to be so since 'cursor' and 'more' are not included in the response.
==>MT Indeed, thanks.The same applies to Figure 5 (the AS does not support the "Cursor" extension, though it may support the diff queries without it).
The same also applies for the examples in Sections 11.1-11.3. <==
[Section 8]* Consider changing Section 8 title (i.e., "Using the "Cursor" extension").That title, according to my understanding, refers mainly to the Authorization Server and the responses it produces when supporting the "Cursor" extension.An Authorization Server supporting the "Cursor" extension always includes 'cursor' in full query responses and both 'cursor' and 'more' in diff query responses, even if the request does not contain the 'cursor' parameters, according to Section 8.2.1. A requester not supporting the "Cursor" extension will silently ignore 'cursor' and 'more'.Therefore, I would suggest changing the title of Section 8 to clarify that the discussion is about an Authorization Server supporting the "Cursor" extension.
==>MT Right. Now changed to "Response Messages when Using the "Cursor" Extension". <==
* In Section 8.2.3., I would extend the sentence:"... When receiving this diff query response, the requester should send a new full query request to the Authorization Server, in order to fully retrieve the current pertaining portion of the TRL."with: "as well as a valid value of cursor, as specified in Section 8.1.".After all, the main reason why the requester is making a full query request --in this specific case--, is to learn the value of LAST_INDEX. Then, it can use that value, or a value in the range [LAST_INDEX < N_MAX ? 0 : LAST_INDEX - N_MAX, LAST_INDEX] to perform a new diff query request with 'cursor'. In such a case, the Authorization Server will process a request as per Case B of Section 8.2.3.
==>MTYes. I've made some further rephrasing along these lines, and come to the overall following result.
"When receiving this diff query response, the requester should send a new full query request to the Authorization Server. A successful response provides the requester with the full, current pertaining portion of the TRL, as well as with a valid value of the 'cursor' parameter (see Section 8.1) to be possibly used as query parameter in a following diff query request."
<==
[General]* Following the reasoning at the previous bullet point, I noticed a probably unwanted behaviour of the mechanism:A requester can never obtain the first diff entry (the one with 'index' equal to 0) if it specifies 'cursor'.Accepted values for 'cursor' are 0 and positive integers, as per Section 5.2, bullet point 'cursor'. Moreover, when the Authorization Server receives a request including 'cursor' with value P, the first diff entry (if any) it includes in the response is P+1, as explained in Section 8.2.2. <https://eur05.safelinks.protection.outlook.com/?url=http%3A%2F%2F8.2.2.%2F&data=05%7C01%7Cmarco.tiloca%40ri.se%7Cf30a9144eb174dc3f1ba08da89ba05e3%7C5a9809cf0bcb413a838a09ecc40cc9e8%7C0%7C0%7C637973729435222690%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=vqZJE3GpjXysbkGK1vvSnCgAbP0bOs1uopp6BfVlaEs%3D&reserved=0>:"As defined in Section 8.2.3, this would result in the Authorization Server transferring the following subset of series items as diff entries, thus resuming from where interrupted in the previous transfer."Having the first series item ever added to an update collection with 'index' equal to 1 would solve this behaviour, but it will probably require modifications elsewhere.
==>MTThis resulted in broader considerations, also taking into account recent changes that admit the wrap-around of the 'index' value, when it passes its maximum value MAX_INDEX.
Related to this specific point:* When including the query parameter 'cursor' in a diff query request, the requester is supposed to specify an unsigned integer value that was provided by the Authorization Server in a previous response from the TRL endpoint (see Sections 8.1, 8.2.2 and 8.2.3). This is now stated in Section 5.2, when describing the query parameter 'cursor'.
* Note that a requester may still obtain the specific series item with 'index' value 0, in two possible ways. While I go through them below, I believe it is not worth elaborating them in the Internet Draft.
- Specifically pointing to that series item, by using the query parameter 'cursor' with value MAX_INDEX. I think this is "unorthodox" as long as a wrap-around is not occurred (as per the previous point), but it would work.
It is an open question whether this should be defined as an invalid request, following which the Authorization Server has to reply with an error response (again, as long as a wrap-around in the update collection for that requester has not occurred). I lean towards keeping it as a valid request to be tolerated and served by the Authorization Server as usual.
- Performing a diff query without including the query parameter 'cursor'. If the series item associated with 'index' 0 is present and selected to be returned, then the Authorization Server will include such an element in the response.
<==
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
-- Marco Tiloca Ph.D., Senior Researcher Phone: +46 (0)70 60 46 501 RISE Research Institutes of Sweden AB Box 1263 164 29 Kista (Sweden) Division: Digital Systems Department: Computer Science Unit: Cybersecurity https://www.ri.se
OpenPGP_0xEE2664B40E58DA43.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
