Reviewer: Joerg Ott Review result: Ready with Nits This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@xxxxxxxx if you reply to or forward this review. This document defines the interactions and message format for TRL endpoints to inquire token revocation lists (TRLs) or be notified about such from/by an authorisation server (AS). The specification defines the message exchanges on top of established application protocols such as CoAP. It supports retrieving full TRLs or (recent) changes to such TRLs. Being based upon existing protocols and carefully addressing resource constraints that endpoints might have, the protocol does not appear to introduce new transport layer issues to be considered. Looks good to me from this perspective. Found a few minor nits: sect 1, 4th para: "if they are defined to use in the ACE framework" doesn't quite seem to parse. sect 5, 2nd para: "the AS sends as response use Content-Format" sect 5, 8th para: "ii) they were added to or removed from that update." The previous part of this para talks about multiple updates, the previous para about the most recent one. What does "that update" refer to? The discussion of the diff update procedure in sect 5.1.1 may not be that easy to follow, but maybe it is better understandable if one writes code. sect 5.2: 11th para: "The 4.00 Bad Request ..." -- move this para after the indented bullet list? Seems to break the reading flow here. sect 7, last para before sect 8 refers to I-D.bormann-t2trg-stp. This draft seems to be expired, it is from a research group; does this reference help here and add value? sect 9: is there a need to discuss any constraints of permutations of MAX_N and MAX_DIFF_BATCH? sect. 10, 1st para: "Once completed the registration procedure at the AS, the administrator..." doesn't quite parse. sect 10.1, 2ns para: "if the corresponding token hash is among the currently stored ones" [add: 'in the TRL"?] Appendix C: I believe to have understood that one could have a retrieve operation without Observe. Should this include such a simple example, too? -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call