[Last-Call] Tsvart last call review of draft-ietf-ace-revoked-token-notification-06

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux