[Ace] Re: 2nd WGLC for draft-ietf-ace-revoked-token-notification

[Marco Tiloca <[e-mail]>]

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=[e-mail]. 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=[e-mail]> 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 -- [e-mail]
>     To unsubscribe send an email to [e-mail]
>
>
> _______________________________________________
> Ace mailing list [e-mail]
> To unsubscribe send an email [e-mail]

-- 
Marco Tiloca
Ph.D., Senior Researcher

Phone: [phone]

RISE Research Institutes of Sweden AB
Box 1263
164 29 Kista (Sweden)

Division: Digital Systems
Department: Computer Science
Unit: Cybersecurity

https://www.ri.se