Hi Marco,

Thanks a lot for these additional comments!

I have addressed them in a new PR at [1], which also provides a few minor editorial fixes.

Please have a look at the PR. If all is fine, I can merge it and submit the result as version -08.

Best,
/Marco

[1] https://github.com/ace-wg/ace-revoked-token-notification/pull/11


On 2024-06-14 12:16, Marco Rasori wrote:

        
You don't often get email from marco.rasori=40iit.cnr...@dmarc.ietf.org. Learn why this is important <https://aka.ms/LearnAboutSenderIdentification>
        

Hi all,

I have read the latest version (-07) of the document and, in my opinion, all the changes made have enhanced the quality of the document compared to version -06. Additionally, I haven't found any technical problems, especially in the new content.

However, I have a few suggestions to improve the document's presentation. Please see them in my review below.

Best,
Marco



1. Consistency in the Use of "TRL Update"

To distinguish the event "TRL update" from the content of a series item (of a diff entry) within an update collection (within a diff query response), I recommend a more consistent application of the term "TRL update" throughout the document. This is particularly important in Sections 5.0, 5.2, and 5.2.1. Other occurrences to review are in Sections 7, 8.1, 8.2.2, 8.2.3, and Appendix B.

Please, note that there is a subtle issue in Sections 5.2 and 7 in the expression "the number of TRL updates pertaining to the requester and currently stored at the AS". I believe this should be revised to "the number of diff entries..." since a "TRL update" is not intended to be stored as-is.


2. Definitions of Key Terms
It might be helpful to add definitions for "TRL update pertaining to a requester" and "pertaining token hash". This would simplify the wording in some phrases, making them less verbose and redundant.


3. Rephrasing in Section 3.1.2
In Section 3.1.2, the current phrasing of the first bullet point of the second list is: "The access token can be uploaded to the RS by means of a POST request to the /authz-info endpoint (see Section 5.10.1 of [RFC9200]), using a media-type different from 'application/ace+cbor' (e.g., like in [RFC9202]). In such a case, TOKEN_INFO is the payload of the POST request."

To make this future-proof, I suggest rephrasing it to avoid the implication that "TOKEN_INFO is the payload of the POST request" in all cases that do not use "application/ace+cbor" as the media type, as this may not always be true in the future.

Il giorno mar 28 mag 2024 alle ore 11:15 Tim Hollebeek <tim.hollebeek=40digicert....@dmarc.ietf.org> ha scritto:

    Hello,

    Marco recently submitted a rather large set of changes in response
    to AD review and IETF last calls.  Due to the size and number of
    the changes, Paul has asked that we have another WGLC to make sure
    the group has sufficiently analyzed the new text.

    So this is a 2^nd WGLC for
    draft-ietf-ace-revoked-token-notification.  Due to the amount of
    information to review, we’ll give people three weeks.

    So please review the latest version and send comments to the list
    by 17 June 2024.

    For the chairs,

    -Tim

    _______________________________________________
    Ace mailing list -- ace@ietf.org
    To unsubscribe send an email to ace-le...@ietf.org


_______________________________________________
Ace mailing list --ace@ietf.org
To unsubscribe send an email toace-le...@ietf.org

--
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

Attachment: OpenPGP_0xEE2664B40E58DA43.asc
Description: OpenPGP public key

Attachment: OpenPGP_signature.asc
Description: OpenPGP digital signature

_______________________________________________
Ace mailing list -- ace@ietf.org
To unsubscribe send an email to ace-le...@ietf.org

Reply via email to